Closed SargisPlusPlus closed 4 months ago
Is it possible to make a minimal reproduction of this so I can debug it?
I suspect the issue is here. Every single event is stored memory.
All of the events are queued up so that a web inspector can attach at a later time. If the user refreshes the tab, then they would again receive all of the events.
I have tried to address this in my react native inspector... Instead of queueing up deferred
events while we wait for a new connection, the inspector/adapter can retain references to all of the actors, then when a inspector connects, we can send over all of the active
actor definitions and snapshots to the inspector. This way, we don't have to retain any events in memory.
This approach means that you won't see any previous events
after you connect the inspector, but I think this is a tradeoff that most people would take.
Would it make sense if createBrowserInspector()
would behave like a singleton? The inspector can handle multiple machines.
I have a single page application. There is a button on my page that starts a flow for a user. This flow implements an xstate.
Within each flow, I create createBrowserInspector.
After which I create an state machine actor.
Users can start this flow as many times as they wish within a single page. Thus,
createBrowserInspector
andcreateActorContext
are called as many times as users engage with the flow. What we have noticed is that after multiple flows, the memory of the Chrome tab keeps growing, reaching to couple of gigabytes.To fix this memory problem, I had to put
createBrowserInspector
behind a flag altogether: