I have stumbled upon a tricky use case with React/SpacePen interop. Specifically, I am trying to make a React-based autocomplete component. I have made a lot of progress so far, but now I am having trouble wiring up the keybindings.
The official autocomplete package from Atom uses the built-in SelectListView, which does not use React. It uses an
EditorView as a subview (this happens in its
@content method). It appears to be able to use either the SpacePen-based-view defined in
editor-view.coffee or the React-based-view defined in
react-editor-view.coffee as its
EditorView. Both are subclasses of
View from SpacePen, which is why they can be plugged in as a subview of
SelectListView::initialize(), it adds listeners for higher level events, such as
core:move-up. This is attractive because it avoids requiring the package author to create custom keybindings for the same concept. Note that the author of autocomplete-plus does this in his keybindings/autocomplete-plus.cson file:
".autocomplete-plus input.hidden-input": "tab": "autocomplete-plus:confirm" "down": "autocomplete-plus:select-next" "ctrl-n": "autocomplete-plus:select-next" "up": "autocomplete-plus:select-previous" "ctrl-p": "autocomplete-plus:select-previous" "escape": "autocomplete-plus:cancel"
This is unfortunate because if a user adds her own keybinding for
core:move-up, then it will not work when she tries to move upward in the list for an autocomplete-plus widget, even though it will work everywhere else in Atom.
I was wondering why someone would set things up this way, though I looked at autocomplete-plus’s equivalent to
SelectListView, which is simple-select-list-view.coffee. Instead of using an
EditorView to catch keyboard events, it uses an ordinary hidden
<input> element. Presumably it cannot register a listener for things like
core:move-up on there.
In summary, I would like to be able to listen for keyboard events that are mapped to
core:move-up without using SpacePen. My current thought is to do something like:
@content: -> @div class: 'dummy-parent', => @subview 'filterEditorView', new EditorView(mini: true) @div class: 'parent-for-react-component'
such that my
View can do
@on 'core:move-up', => @myHandler, but I can also render into
.parent-for-react-component. This seems like a bit of a hack, though.
I know that in Moving to React, there is a stated goal of “exploring some ideas for making Atom more view-framework-agnostic for packages,” but I’m not sure if it’s practical to expect to get multiple view systems to coexist. There is already some friction between React and SpacePen when it comes to how events are handled. I’m curious what the current thinking is, and if there’s an existing solution to using a SpacePen -> React -> SpacePen component hierarchy.