Opened 2 years ago

Closed 2 years ago

#5652 closed change (invalid)

Refactor handling of eventListeners in help.eyeo.com

Reported by: ire Assignee:
Priority: P3 Milestone: help.eyeo.com 1.0.0
Module: Websites Keywords:
Cc: juliandoucette, saroyanm, greiner Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

Background

We are currently adding multiple event listeners to each element needed. This is not the best method for performance.

What to change

Research and implement a better method for handling events

Change History (7)

comment:2 Changed 2 years ago by ire

@Julian I don't think this is necessary anymore because:

  1. We are handling all the events in each prototype
  2. I'm not sure it's actually better to handle all clicks/etc. on the body in the first place

What do you think?

comment:3 follow-up: Changed 2 years ago by juliandoucette

comment:4 in reply to: ↑ 3 Changed 2 years ago by ire

Replying to juliandoucette:

What do you think?

https://stackoverflow.com/a/28202575

Yeah that's the same link I shared above :P

We are already (IMO) doing what that answer advised. We are handling most event listeners on the parent element, e.g. the .custom-select element and not each <li> within, and determining what to do based on which element within was clicked. The only exception is the navbar, which is being handled in the separate issue to move it to website-defaults.

Do you still feel there is more for us to do? (I think we've agreed that handling the events on the body isn't the way to go here?)

comment:5 follow-up: Changed 2 years ago by juliandoucette

Yeah that's the same link I shared above :P

I know. I was lazy :P . I could have said "I agree with the answer provided in the first link above" instead.

Do you still feel there is more for us to do?

Not that I remember. If there are individual components that could be optimized then I think that we should create more specific tickets for them.

I think we've agreed that handling the events on the body isn't the way to go here?

Yep.

comment:6 in reply to: ↑ 5 Changed 2 years ago by ire

Replying to juliandoucette:

Yeah that's the same link I shared above :P

I know. I was lazy :P . I could have said "I agree with the answer provided in the first link above" instead.

Do you still feel there is more for us to do?

Not that I remember. If there are individual components that could be optimized then I think that we should create more specific tickets for them.

I think we've agreed that handling the events on the body isn't the way to go here?

Yep.

Alright. I will close this ticket then, and we can create individual tickets to address individual components if the need arises.

comment:7 Changed 2 years ago by ire

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.