David Khourshid

> So what would be the plan here then? Event-sourcing? https://stately.ai/docs/persistence#event-sourcing Yes, the solution would be replaying the events to get to the state if it is necessary to re-execute...

Ah okay @florian-lefebvre - this would be related to persisting and restoring timer, which we are still working on solving.

Will add JSDocs in follow-up PR

> There is a substantial problem with this PR that is somewhat mentioned in this comment here: > > https://github.com/statelyai/xstate/blob/91549ce8a6a5105b3d354ca442ea5c058e58e206/packages/core/src/createActor.ts#L588-L592 > > When the parent actor gets stopped its children...

Closing as stale 🧹

@devanfarrell You will soon be able to use maybe-undefined actors in `useSelector(actor?)`: https://github.com/statelyai/xstate/pull/4231 That should make things a lot easier.

> I find it slightly weird that this would introduce a lack of symmetry between [the proposed `spawn` action](https://github.com/statelyai/xstate/pull/4329) - that action currently _doesn't_ support spawning of multiple actors at...

🧹 Closing as this can be done using `enqueueActions(…)`: ```ts actions: enqueueActions(x => { x.context.actors.forEach(actor => x.enqueue.stop(actor)); }) ```

@christophe-g Glad you're interested in it! Emitting events should be explicit, though, and it may be better to `.subscribe(…)` to the state changes and map those to URL states. More...

> Dear @davidkpiano - just interested to know if this PR has any chance to be merged, or if there are any blocking issues ? > > I have build...