Proposed investigation: JavaScript Signals standard proposal

[KaliedaRik]

Proposal
There's an ongoing effort to standardise the concept of Signals, and expose the functionality as a Javascript API.

This is very interesting for SC, as the library uses a (somewhat ramshackle) form of signalling internally, to keep track of artefacts that have changed their state which then signal their change of state to other artefacts which rely on the changed artefact to calculate their own state. For example, any artefact which locks its state to another via pivot, mimic, path etc.

The current situation is not ideal, as it relies on setting dirty flags in artefacts to inform them that state in their dependency chain has changed. Keeping track of dirty flag management is, from an SC developer perspective, difficult. Anything that can simplify the code base in this area should (in theory) be beneficial.

Building a more robust signalling system to SC should have no impact on the library's users as all the work would be on internal code, with no changes to the SC API.

Risks

• The standardisation effort is at a very early stage (Stage 0!), and their is no guarantee that the eventual result (if any) could benefit SC.
• Even if the new standard proves useful to the library, implementing it in SC may lead to slower running code.

Way forward
The proposers have developed a JS polyfill which we can use to start experimenting in this area. There's no harm in experimenting (he says) ...