How OpenChronology was built

Issue #53 · Decide how to originate data

2020-07-06T00:47:45Z CE

• 2020 editor
• issue

UISets has been effective at being a "store" for all effective data - we can use it to parse the recursive document into a mapping, and likewise turn the mappings back into a document isomorphically. However, this brings to question the actual propose of the signals used throughout the app. Generally, they serve the following purposes: - to be the current perspective of the app - what we're currently looking at - to allow for modification of some specific data in a signal, and have that change reflected automatically to components - to store un-saved changes in localstorage for later recovery - to represent the "user interface state" - what we're currently selecting, our navigation, etc. I think these goals are conflicting with UISets somewhat - UISets should be the end-all data source for all and any signals in the application. For instance, when we navigate to a specific time space, we have to look it up in the sets, as well as it's timelines, siblings, and children. However, the sets to not designate, for instance, zoom level, or the "currently selected" time space. The following questions need to get addressed immediately: - Should UISets be a signal, instead of a reference? - Should UISets be the only signal that saves itself to local storage, when considering document data? - Should there still be "current view of X" signals, like Timeline.UI.TimeSpace.Timelines? If changes occur to this signal, should it reflect back to UISets? What about changes to UISets, do they reflect to Timelines? #15 \cc - if so, how could we make the network of "observing" signals explicit? For instance, operations like: - additional timeline created in timelines, get current viewed timespace, add timeline to set and update timespace with reference - explore timespaces returned new focused time space, get newly focused timespace from set, traverse get timespace's timelines from set, traverse get timespace's siblings from set Could the "edges" in this dependency graph be iterated as functions in Plumbing.Logic, or something similar? LogicFunctions seem to be more like "one-off" run executions, mostly invoked by the user, rather than "constantly-run" executions; however, I like the idea, because it would make clear observation of "read-only" and "writeable". *Archived by the Wayback Machine on 15 September 2020; the repository has since been deleted from GitHub.*

Open Issue #53 · Decide how to originate data in the timeline