application context architecture #270
Comments
|
Context also affects mouse responses and touch gestures (when on touch-interface devices). |
|
There may also be logical groups of keys that can be defined and those groups have the same meaning in different contexts, while no meaning in other contexts. |
|
Definition of Key Groups and Contexts: Key Groups:
Contexts:
|
|
@PropGit After much thought and discussion on this issue a concept has emerged that we are proving internally. Here is a summary of the thought processes thus far. The current state of the application does not include the concept of context. This means that event handlers are registered at the root level of the application and are triggered universally during a user's session. For this reason, pressing the 'tab' key while viewing a modal would still affect the text editor that is opened behind the modal while it may or may not toggle through the modal button options. Additionally, issue #276 highlights the need for us to maintain a history of context state. For example, while canceling on an "overwrite" prompt, we are taken back to a save prompt but not necessarily the save prompt that led up to the "overwrite" prompt; this happens because we are not using history to return to the previous dialog but instead have dom elements wired to handlers and therefore cannot determine which context we came from. So as we got to thinking about this, our first approach was to create a context stack with context objects including both type and metadata (used for populating views and handlers). The idea here is that context state could be added to and popped from the stack, resolving the history issue of the "overwrite" dialog. This seemed to solve part of our problem, but it did not provide us with an answer on the need to change the meaning of a specific event (i.e tabbing) in different contexts. All in all we considered a couple different ideas, all of which required us to architect a system to manage context state, track view hierarchy, and manage history. While the initial ideas came close in terms of resolving the current problem, it would be at the expense of complicating the code-base and reducing maintainability long-term. So, after much deliberation we came to realize that this problem relates very closely to that of webpages and could be solved through giving each "context" a separate route. However, being in a chrome application removes the APIs we would use to do routing. While investigating our options we considered a well established open-source library called 'React-Router'. We are very optimistic about this direction. By default React Router uses the html history api, but it has the ability to manage its own state history object in memory. Furthermore, it simplifies our idea of contexts by using 'routes', which in our case are simply various states of the application. We can use the routes to determine what set of functionality is available to the current view. After taking a look throughout the weekenend and testing the library within the confines of a packaged Chrome application, we have confirmed that this is promising avenue to pursue. This is a major undertaking and will not be implemented by the end of this sprint. It is clear there are many things that could change regarding the way we construct our views and handle events. We will be in a better position to discuss this by the demo, but will likely need another sprint cycle to complete the implementation. |
|
@urbantumbleweed - Awesome work guys! Sounds like you really dove into this as a team and explored things deeply. I like the sound of the solution you are headed towards. Thank you for all the details.
This makes me nervous. Maybe you can fill me in on what you mean here in our meeting. Regarding using React-Router routes to keep context history, something occurred to me to be careful about. (I'm not sure it will be a problem, but thought I should pose the question). Will this have any effect on inter-session behavior?
|
|
@PropGit: We are going to discuss this further on our call Wednesday when we can the discuss technical implications in regards to changing views. One thing to keep in mind about React-Router state is that the history object is only in memory and will behave similarly to how undo-redo history works on documents. We will discuss further and if needed on our call. |
|
update: I've been working on changes including replacing holovisor dependency with a new layout view. This work also partially replaces the skrim dependency, however we are still going to be using that plugin for toasts for time being. Major pieces left are updates to the overlay actions to use pushState as well as a remapping of some global key handlers to their specific contexts for the dialogs. |
|
@monteslu - I updated the Key Groups and Context definition post. |
There are a number of keyboard shortcuts that should work differently depending on the current view state of the application. The concept of context has not yet been built into the application and will need to be prior to being able to resolve issues that depend on the the feature.
Examples of issues that depend on context are: #104 and #105.
The text was updated successfully, but these errors were encountered: