Comments (1)
I've been thinking about this further this weekend and had some ideas. Building on the initial benefit of having separate "mailboxes" outlined in the OP, there are two other benefits of splitting this up.
- minor performance boost, currently a broadcast requires iterating through all machines in all active roots, which isn't expensive per say, but is rather ineffecient
- Inability to easily see all the locations a given event is broadcast
Both of those can be solved with a combination of more granular mailboxes that specific machines opt into listening to and generating functions to broadcast events so you can use "Find References" to locate all the broadcast sites.
Looking at the xstate receptionist RFC I don't think it's quite the fit for the broadcast system xstate-tree uses. It's based around registering actors and sending more scoped messages to specific actors, whereas the broadcast system is effectively "this thing happened, inform anyone who cares about it". It also does not deal with any concept of queued messages, which is something we have a few uses for at Koordinates so I would like to explore.
In light of that I am proposing the following
- Creating a mailbox
Creates a mailbox, defining the events as objects in Javascript instead of at the type level as we need the event types in Javascript to be able to generate the send*
functions. Optional data property used to type the argument to the send functions
const mailbox = createMailbox(
{ type: "anEvent", data: {} as { aProperty: number},
{ type: "noDataEvent" }
);
- Sending an event to a mailbox
mailbox.sendAnEvent({ aProperty: 10 });
mailbox.sendNoDataEvent();
- Listening to events from a mailbox
Something to think about here is the ability to prefix the events with something to allow bringing in an event of the same name from two mailboxes, but that requires something in JS so can't be done here
type Events = MailboxEvents<typeof mailbox, "anEvent">;
other xstate-tree boilerplate snipped
Pass the list of mailboxes the machine is interested in here so that the React view that manages the interpreter for the machine can subscribe to the mailboxes and send the relevant events to the interpreter
Since there is no enforcement of this if you are adding events from a mailbox to the machines events, some sort of checking here that any mailbox events have an attached mailbox that provides them would be useful. That would require having some way of differentiating mailbox events from machine events at the machine config level (ie event name)
buildXstateTreeMachine(machine, {selectors: ..., actions: ... etc, mailboxes: [mailbox]}
- "queued" events
Some scenarios you need to pass data to a machine that is not yet listening for events, which is impossible with the current system because events are only delivered to actors listening at the time the event is delivered. Most events should not be queued as it they aren't needed in this scenario and it's perfectly fine for no consumers to be active for some events, don't want them queued up and then have something consume a stale event in the future randomly.
So I propose that this be opt in per mailpox, you can mark the mailbox as queued and then it will queue messages that have no active consumers until an actor is ready to consume a message of that type. Behaviour around queuing and multiple messages TBD.
from xstate-tree.
Related Issues (20)
- Refactor build* xstate typings HOT 1
- xstate-tree machine building 2.0 HOT 3
- User provided shared meta additions
- Add example app and use it to improve test suite
- ESM support HOT 2
- Release issues
- API docs
- Improve debug logging
- Sync external data into machines HOT 1
- Support tags
- Readme example leaves out most important part: slots HOT 4
- Deprecate `inState` prop of view components HOT 1
- Replace canHandleEvent implementation with `state.can` HOT 1
- Add hook to enable determining if a route is active HOT 1
- Routing machine HOT 5
- View to machine utility
- Upgrade History to v5
- xstate v5 support HOT 5
- Allow passing callbacks to slot views/root components to allow communication with React from xstate machines
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xstate-tree.