This repository has been archived by the owner on Apr 1, 2020. It is now read-only.
Fix #269 - Enable asynchronous loading of menu items #764
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Oct 10, 2017
bryphe
changed the title
[WIP] Fix #269 - Enable asynchronous loading of menu items
Fix #269 - Enable asynchronous loading of menu items
Oct 12, 2017
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue: The current 'QuickOpen' (
<Control-P>
) experience is not asynchronous. For large directories, it's helpful to have the results streamed and filtered real-time, instead of having to wait for the whole structure to be crawled. There are also some architectural issues (we have two different ways of callingquickOpen.exeCommand
, and arguments aren't handled correctly on all platforms).Fix: This creates an API to host the
Menu
functionality. The advantage of this is that plugins can easily take advantage of creating a pop-up menu that exhibits the same filtering (or it can even be added to theconfig.js
by callingconst menu = oni.menu.create()
). In addition, I'm in the process of refactoring and consolidating the code that spawns the finder process to be in a single location, and not called in the reducer.Long-term, I'd also like to have separate NPM modules for some of this functionality (like
oni-menu
andoni-quick-open
), which is why I started silo'ing out these files intoServices/Menu
- ideally all the code under there could be factored out to a separate module.