As of today, Amp tracks its current/active mode using a single enum field on the Application type. When the active mode is changed, the old mode is discarded and a new one is constructed. A side effect of this is that the active mode's state is lost during the transition. There are situations where persisting and recalling state across modes is beneficial:
when searching/replacing text, preserving the search query so you can quickly find the next match after making edits
when selecting a range of text in Select/SelectLine modes, temporarily switching to jump mode to select the end of the range
pinning search tokens in open mode to narrow down results to your area of focus when working in larger projects
The first two behaviors above exist today, but as you'll see in the diff below, they're implemented by explicitly storing required state in their relevant modes or the Application type itself. This has helped minimize and isolate the complexity involved with persistent state, but as we look to implement more features that require it, the pattern justifies building a generalized system that handles this for all use cases.
That generalized system is the focus of this PR. As you'll see below, we now build all application modes up front, store them in a hash map, and recall them when switching modes. To do so, I needed to introduce the following notable changes:
build all modes when initializing the Application type to hydrate the map
add a new ModeKey type as a stateless enum key into the map
add a reset method to modes where a clean slate is expected (e.g. rebuilding open mode's project directory index)
Once this lands, we'll be able to leverage these persistent modes to build some neat features that should really help improve the ergonomics of Amp. 😎
As of today, Amp tracks its current/active mode using a single
enumfield on theApplicationtype. When the active mode is changed, the old mode is discarded and a new one is constructed. A side effect of this is that the active mode's state is lost during the transition. There are situations where persisting and recalling state across modes is beneficial:Select/SelectLinemodes, temporarily switching to jump mode to select the end of the rangeThe first two behaviors above exist today, but as you'll see in the diff below, they're implemented by explicitly storing required state in their relevant modes or the
Applicationtype itself. This has helped minimize and isolate the complexity involved with persistent state, but as we look to implement more features that require it, the pattern justifies building a generalized system that handles this for all use cases.That generalized system is the focus of this PR. As you'll see below, we now build all application modes up front, store them in a hash map, and recall them when switching modes. To do so, I needed to introduce the following notable changes:
Applicationtype to hydrate the mapModeKeytype as a statelessenumkey into the mapresetmethod to modes where a clean slate is expected (e.g. rebuilding open mode's project directory index)Once this lands, we'll be able to leverage these persistent modes to build some neat features that should really help improve the ergonomics of Amp. 😎