It might worth considering a "Record" object that stores the value that a state object had at a time. Although it is behavior has to be discussed to eliminate the possibility of a useless feature.
Should Records use a state object to determine whether they should sync or not? Or expose two methods that are desync and sync- which they handle the syncing of the state objects?
Additionally, should records use the same mechanism as Reflect (see #5), which is just to return that state object's value when synced, or to completely treat the record object as a standalone dependent object?
The mechanism for Reflect made since as it was intended to be used as just a reflection (that is, Reflects don't actually exist, they are just tables that return their owner's _value). It is important to keep in mind that reflection manages the dependents by allowing dependents to directly subscribe to the reflection's owner- which might not be ideal for an object like Record, without modification.
You see, Pure Reflection is implemented without giving the reflector any sort of dependency identity, which means they have no awareness of who is actually using them, but rather forwarding the dependent to the reflected object. This might be ideal for an object like Reflect, but is absolutely useless for Records.
Records are kind of Reflects, they can return the reflected object's value using direct access, but they can have a dependency identity, that is, they subscribe dependents to themselves, rather than forwarding the flow to the reflected object.
This allows for the Record to dismiss updates coming from the Reflected, or the new name, the Recorded object when the said record object is desynced, while allow for update flow to pass while being synced.
sinlerdev
commented
1 year ago
It might worth considering a "Record" object that stores the value that a state object had at a time. Although it is behavior has to be discussed to eliminate the possibility of a useless feature.
Should Records use a state object to determine whether they should sync or not? Or expose two methods that are
desyncandsync- which they handle the syncing of the state objects?Additionally, should records use the same mechanism as
Reflect(see #5), which is just to return that state object's value when synced, or to completely treat the record object as a standalone dependent object?The mechanism for
Reflectmade since as it was intended to be used as just a reflection (that is, Reflects don't actually exist, they are just tables that return their owner's_value). It is important to keep in mind that reflection manages the dependents by allowing dependents to directly subscribe to the reflection's owner- which might not be ideal for an object like Record, without modification.You see, Pure Reflection is implemented without giving the reflector any sort of dependency identity, which means they have no awareness of who is actually using them, but rather forwarding the dependent to the reflected object. This might be ideal for an object like Reflect, but is absolutely useless for Records.
Records are kind of Reflects, they can return the reflected object's value using direct access, but they can have a dependency identity, that is, they subscribe dependents to themselves, rather than forwarding the flow to the reflected object.
This allows for the Record to dismiss updates coming from the Reflected, or the new name, the Recorded object when the said record object is desynced, while allow for update flow to pass while being synced.