[Refactor]: Explorer Paradigm 🧭

[ks0m1c]

And, more subtly, we also find that different patterns in different languages, have underlying similarities, which suggest that they can be reformulated to make them more general, and usable in a greater variety of cases.
-- Christopher Alexander -- The Timeless Way of Building

As we have dug our heels in and set up our foxholes through the explorer paradigm that moves away from independent liveview processes that were loosely coupled through live sessions towards one key central process the display_manager that currently shepherds live components through their respective lifecycle.

The expedience for this change arose out of the need for

1. variety of components crossing boundaries of the written context such as the control panel and action bars that coordinate actions that cross modes in context of the written view -> such as moving to drafting from reading or to discussions.
2. These modes also preserving state during the navigation across the written context as we jump through chapters and sources

We have subjected our codebase to forces that can lead to a ball of mud scenario if they are left unchecked.

But what guarantee is there that this flux, with all its individual acts, will not create chaos? It hinges on the close relationship between the process of creation and the process of repair.
-- Christopher Alexander -- The Timeless Way of Building

Where are the centers in code where this process of repair can begin?

• Separation of responsibilities of various subsystems that are currently intertwined

  • the stateful skeletal system that handles view specific behaviour with regards to device sizes
  • message relaying system that reacts to events across components (abstract to allow components to handle at point of responsibility)
  • the event driven system that reacts to client side events from users that affects across components

• Reduce surface area of statefulness

Live components need only arises when there is a need for encapsulating both event handling and additional state, break into either data or functional components where same behavior can be expressed.

1. Lower surface to depth of responsibility ratio, that is, live components should be served with small surface areas, that encapsulate deeper responsibilities.
2. Simplify expressiveness livecomponents as modules also serve to express behavior that they can be understood in and of themselves.

Allow a user to control a large volume of complex machinery with a small, simple interface

With care and foresight we should craft beautiful interfaces going forward where multiple interdependent flows can be orchestrated seamlessly tying together the various centers of behaviour and actions within our system into an unity.