speed up time to switch edit or select modes on large designs, by changing css classes on strands and strand parts outside of React/Redux for efficiency, and pulling edit/select mode information out of view components to decrease re-rendering time when edit/select modes change

[dave-doty]

Currently, changing the edit or select mode re-renders every Strand React component and every subcomponent, because all of them take the AppUIState's Edit modes and Select modes as props. They do this so that they know whether to add the classes "selectable" and "selected", which indicates to the CSS file how to style them on mouseover (e.g., making them "glow" or turn pink).

This is immensely slow on large designs to switch between edit modes or select modes.

This is an instance where it is probably best for efficiency to side-step React and have the state change trigger a middleware that reaches directly into the DOM to change these classes.

It is also necessary to add middleware (mode_sensitive_actions_filter_middleware) to help discard/transform certain actions, because the view components now do not have enough information to know whether an action is permissible to dispatch, or what type of action to create (e.g., when clicking on a domain, are we in select mode to select the strand? in nick mode to nick the domain?)

[dave-doty]

This might come in handy for this: https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet/insertRule

[dave-doty]

This will also require extensive re-engineering of the way edit modes are handled. Currently, the onClick handlers for different parts of Strands access the full edit mode to decide what to do (e.g., if in Nick edit mode, then clicking on a Domain nicks it).

This can be handled by making the click handlers dumb. They should just package up information about the click (e.g., what offset on the domain was clicked), and let middleware handle the logic of looking up the edit mode and deciding what to do.

[dave-doty]

Closed in #377.