-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Customizing the layout of autocomplete popup #5700
Comments
Instead of using mutationObserver it would be much easier to reimplement AcePopup class https://github.com/ajaxorg/ace/blob/master/src/autocomplete/popup.js#L251. But maybe it would be worth to support more rendering options in the popup itself. Is category titles the only feature you need? |
Category titles is my current example but I identified a common situation when using UI components: the difficult to completely rework their layouts as stakeholders use and evaluate the software. That's the root of the frustration reported. In this particular case, to have an Excel-like expression editor with autocomplete and syntax highlighting is obviously much better than reimplement from scratch but, you know, customers are never satisfied and when it comes to UI, they want to opine and change everything. That's part of this business, so I think UI components should always follow an MVC-like architecture that decouples presentation from data logic. |
Currently it is possible to completely change the rendering of the popup by doing something like require("ace/autocomplete").Autocomplete.for(editor).getPopup(editor)
editor.completer.popup.setData = (list, filterText) {
popup.filterText = filterText || "";
popup.data = list || [];
popup.setRow(0);
// render popup
....
};
editor.completer.popup.tryShow = ...
editor.completer.popup.hide = ...
editor.completer.popup.setRow = ... // select item i in date
// overwrite editor.completer.popup.goTo if you need to change the way arrow keys are handled we can try to make this more convenient if there is more concrete data, but i'd say completely reimplementing is a too drastic measure and usually it is easier to reimplement rendering for individual rows only like in https://github.com/c9/core/blob/master/plugins/c9.ide.language.core/completedp.js#L44
sounds interesting, is it possible to see this product? |
It is just our use case of Ace: put a bunch of Excel-like functions in autocomplete options and highlight function syntax elements. For custom rendering, I mean mainly the HTML content and its style, along with the displayed information. That's the point, allow any arbitrary HTML whenever it is possible. |
Describe the feature
In the current project I am working on, I need to create a completely different layout for the autocomplete suggestions popup (see screenshot below).
It is being a very hard requirement to achieve because of the high coupling between the default layout positions and the event handling logic. Mainly, click events over the popup seems to be detected by a big overlay and the clicked item is determined by the clicked point position. It completely prevents me to customize the element positions and introduce elements, category titles in my case.
Use Case
To use the example, I really get frustrated whenever customers want to customize the layout (the UI is what they see and emit opinions) and the ready-to-use components does not support custom rendering of its state.
Proposed Solution
It would be nice if the popup could be created by the programmer based on the current state of the autocomplete. The component would listen to keystrokes, change the filtered and selected items and pass the data to the custom render, in a model-view-controller manner. The custom render could capture events like click and scroll and pass tem back to Ace's autocompleter to generate a new view based on the filtered items, the selected one and the currently ones in the scroll viewport.
Other Information
I am beging somehow succeeded using a workaround:
visibility
)The last point required to hook up some
document.body
events, e.g., when user clicks the custom popup Ace interprets it as leaving the component focus so I need to intercept and redispatch the event if the target was the custom popup. It seems to work but introduced big complexity. Also, hacks never are things I like to do because they can break when the library is updated.Acknowledgements
ACE version used
v1.36.5
The text was updated successfully, but these errors were encountered: