Guidance on synchronising to external state

[tall phoenix]

Hi, I’m new to Xstate and state machines, but am really keen to learn and would appreciate any help the community might be able to give me towards pointing me in the right direction!

What has drawn me to state machines is my background in Map Web development where I have begun to feel like I keep solving the same ui and logic problems for the different map libraries (Esri / leaflet / mapbox etc) out there, but have to reimplement them each time. Preferably I could create generic state machines and minimise the amount of bespoke logic needed.

Map Layer List:
The first thing I would like to implement is the logic for a map layer list component. The layer list should handle the following behaviour:

1. Storing a list of layers that are displayed in the map
2. Adding a layer
3. Removing a layer
4. Toggling a individual layer’s visibility in the map
5. Group layers - if a layers parent is toggled off then it should not be visible.

Questions:

1. What pattern should I follow for synchronising the layer list to an external state? For example when a layer is added there will always need to be some logic, different for each mapping library, to add the layer to the map. My initial thought was to create two actions that would run in response to the addLayer event, one that handles the internal logic and the other that would be overridden when the state machine is initialised, both would be called sequentially.

ADD_LAYER: {
actions: ['addLayer', 'syncAddLayer'],
}

2. Does it make sense to model the layers as their own state machines and have the layer list spawn actors? Is this useful, or just over complicating things?

[vital reef]

That is what I would do, as well

You can use the emit(…) action creator for some sort of 'onAddLayer' action for maximum flexibility: https://stately.ai/docs/event-emitter

Now if you don't want to add synchronization in a granular manner, and would rather have some generic sync logic for every transition, you can do that in actor.subscribe(…)

I recommend being explicit though, like what you are doing

Does it make sense to model the layers as their own state machines and have the layer list spawn actors? Is this useful, or just over complicating things?

It sounds like there are a variable number of layers. I'd just recommend storing this in context like:

context: {
  currentLayer: 'someLayerId',
  layers: [/* ... */]
}

The main purpose of finite states in a state machine is to delineate capabilities; e.g., when the state machine is in (some state), which transitions are possible?