tc39
Event is just a temporal state
Hi there! I am very excited about this proposal and would like to share some thoughts on potential uses.
Idea
I have been developing a state library (reatom.dev) for half a decade now, and at the beginning of my journey, I believed that events/actions and state containers (atoms/stores/signals) were completely different concepts. However, I have since realized that these two primitives share a lot of implementation and behavior logic. I attempted to unify them into an Event class and an Atom (signal) class on top of it, but this approach proved to be too complex. But later on, I discovered that my conclusion about generalization was correct, but my implementation was flawed. State is not a persisted event payload; rather, an event is a temporary state!
Example
Building a temporary state is much simpler than building a persistent layer on top of one-time events. Many people use "actions" from Reatom in various small and large projects to describe incremental effects, and I have found it to be very useful as well. If you are interested, you can check out the code around .isAction here: https://github.com/artalar/reatom/blob/v3/packages/core/src/atom.ts
Benefits
The core idea is interface Action<Params extends any[] = any[], Payload = any> extends Signal<Array<{ params: Params; payload: Payload }>> {}. So, an array? Yes, because we do not want payload behavior to be as a snapshot of the last update, meaning we do not want to miss any updates, even if there are multiple updates during one transaction. We want to store a list of all action calls, which allows us to analyze and react precisely to any kind of updates. We can easily take the last payload, if we want to skip glitches, from the current transaction or process every call. To be clear, the list is cleared after each transaction, so there is no risk of memory leaks.
Conclusion
I just want to share that the scope of the signals could solve even more tasks, and it is awesome. We should continue to work on it. Thank you all very much!
The possible discussion for this issue is: if we apply the ability to build an event system on top of the signals, we should define the cleanup stage. Reatom clears an action's payloads after all pure computations and its hooks, after the logging queue, but before an effect queue (more about Reatom queues). Should it be customizable? From my perspective and experience, it shouldn't be customizable, but maybe you will have some additional thoughts.
It would be good to discuss this more. We've heard a few variations about being able to capture individual events and in some ways this reminds me of https://signia.tldraw.dev/docs/incremental - either way would be great to talk about at a Community Call soon.
