Implement Positional Unique IDs for Elements to make explicit ID providing optional

[atdiar]

Rationale

Providing unique IDs for every element might be probably too cumbersome for a large scale app. Some elements are not important enough and the developper should not have to think too hard about picking a specific, unique ID. However, the internals of the framework still require that each element is referred by an ID.

Proposal

It is proposed that providing an ID becomes optional. If no ID is provided, the framework will compute one based on the element's current position within the Element tree. These positions will be versioned. Meaning that if an element replaced another, they will still have different IDs reflecting that they are indeed different elements. This is necessary to preserve sound referencing of persisted IDs.

Implementation

Basically, an Element will see its first assigned ID being its primary reference and then a list of secondary IDs if it has moved. The persisted ID should be the primary one. Requires to have a map of the relation between IDs: the primary IDs should link to the latest position which is basically the most recent secondary ID. And the secondary IDs should link to the primary ID which allows to link to the most recent position as well, although indirectly (via the primary ID).

ID scheme

• the id scheme should be composed of two parts joined as such: position<version> Where position is a string type describing the position of the elements in the document datastructure and version is a string that

Further thoughts

• Only elements with a fixed explicit ID (i.e. developper supplied unique ID) should be persistable. (i.e. the data properties may have a lifetime beyond runtime)?
• ViewElements should always have a fixed ID
• since implicit IDs are now mutable, mutation dispatching should be changed to use a node fetching function.
• if an Element is passed as a value somewhere, perhaps it should be marked as non-deletable or it might require some refcounting. (the latter being probably a bit too complex)

[atdiar]

After some further thoughts, positional IDs do not bring much benefits. Moreover, the position is trivially encoded in the structure of any tree serialization. What we need is, at least, reproducible tree construction. It will require the use of a PRNG (ID generation needs to be deterministic) and some kind of event sourcing/ command pattern applied to data mutations so that tree construction becomes replayable.

The advantage is that it should also provide the base mechanism to implement hot reload for free.

The rationale is that tree construction is triggered by data mutations. So recording the history of data mutations should be the most general way.

[atdiar]

See above comment