Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Editor: it is often tricky to click on a dropdown item #111

Closed
EricWittmann opened this issue May 23, 2017 · 3 comments
Closed

API Editor: it is often tricky to click on a dropdown item #111

EricWittmann opened this issue May 23, 2017 · 3 comments

Comments

@EricWittmann
Copy link
Member

Sometimes when trying to click on a dropdown item, particularly one of the dropdowns from within a type editor, it's difficult to get the click to register. The item will turn blue to indicate that it was clicked, but then turn back to normal without making the selection. This is hard to reproduce consistently but is not uncommon.

@EricWittmann
Copy link
Member Author

I just retested this with the latest release and it is NOT fixed. This is a tricky one. :( The next thing to try, I think, is leveraging ngx-bootstrap's dropdown directive.

@EricWittmann EricWittmann reopened this Sep 8, 2017
@EricWittmann
Copy link
Member Author

@EricWittmann
Copy link
Member Author

I think I finally knocked this one out. It turns out to be a combination of things. The core problem with the drop-down is with the options input. If the options change, then change detection will cause the DOM elements (the <li> elements) to be recreated. And the default change detection was seeing changes even when they weren't there. This is because the drop down items (in many cases) were dynamically created each time angular asked for them. So even if the options were the same, the object was different and angular assumed there was a change (and so rerendered the component).

So the solution to that part of the problem is to do a deep-compare of the drop-down options whenever they change. If no real change is made then we keep the old value. This centrally fixes all users of the <drop-down> component. Perhaps a better solution is to explore whether a component can provide custom change detection for its state, but that's something to look into later (Future Eric's problem).

The second part of the problem (not yet solved) is that the Ace editor fires an absurd number of events, all/many of which trigger angular change detection. This includes mouse-over events, cursor blinking events, typing, etc. But it also includes at least one "font detection worker" that polls every 500ms. I presume Ace is using setTimeout() or setInterval() for this, which will trigger angular change detection. So that, combined with the drop-down always thinking its options have changed, resulted in the drop-down options being re-rendered (old <li> elements destroyed, identical new <li> elements created) every 500ms.

Last, the Ace editor component doesn't clean up after itself, leaving the Ace editor (and its font detection worker) around even after the component is destroyed. So every time an ace editor is added to the page, another font polling worker is created, and the drop-down problem gets even worse. Of course, everything will slow down over time as more and more 500ms workers are created and not destroyed.

At this time, the drop-down flickering problem is solved, but the Ace editor problem is not. A new issue is here for that:

#257

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant