Main 'state' object `initialStateObj', which sets initial conditions and contains all subsequent data and UI config info. Currently everything is considered 'state' but it may become sensible to follow the React approach and separate out local data as 'props' - things that don't really change or that can be locally derived from state. This might simplify the state object.
This object is sent to the Pug script as data to drive creation of the html. All variables referenced in the Pug script come from this object
Interaction control for the UI happens in 3 ways, all regulated by the Hyperapp framework. The 3 options are registered with Hyperapp, which controls execution of UI events and the link to application "State"
Functions that deal with instant things, like responding to button clicks or receiving http data § If the result of a button click requires time, avoid blocking everything up by waiting and use an Effect (as below)
These are functions which deal with slow things, like requesting data from elsewhere on the web or typically in case of Resource Planner sending or requesting data to the server API § An effect function will have an associated Action function (1 or more), which it can call when the effect completes - e.g. receive server data. The Action triggered can use the received data or display an error
These manage event listeners, such as a PWA push and online status changes § Each subscription is also associated with its own Action function that is called when the specified event happens
State is a flexible concept which contains data used to define the UI and potentially store user inputs. The data can be numbers, text, functions (e.g. Actions) etc. The content of State is available to the UI, and changes to the UI affect State and vice versa.