Migrating to XState5...

[mighty snow]

I'm getting this error after migrating to XState5:

useActor is not a function or its return value is not iterable.

How do I fix that?

[jolly epoch]

Strange, can you share a CodeSandbox reproduction?

[visual iris]

spawnBehavior is removed from xstate5?

[jolly epoch]

This is now just interpret(fromPromise(...)) (or other interpret(someBehavior))

[mighty snow]

https://stackblitz.com/edit/github-dmggxz?file=package.json

[proven merlin]

Hello, I've taken a quick look at the project. There is no more useActor() on the MixerMachineContext object (was removed in beta 4), but instead you have useActorRef() now, which returns the actor reference directly.

const mixerActor = MixerMachineContext.useActorRef();
mixerActor.subscribe(...);
mixerActor.send({ type: '...' });
mixerActor.getSnapshot();
// ...

And if you wish, the context object also gives you direct access to useSelector().

const volume = MixerMachineContext.useSelector(state => state.context.volume);

[mighty snow]

Thank you, but I'm back to v4 for now. I'm having performance problems. Any clue how to get the track fx panels to work on this? Right now they snap back into place because I'm using useSelector but if I don't there's performance issues. https://stackblitz.com/edit/github-h2gbyx?file=package.json

[proven merlin]

There's a lot going on here, but just focusing on the issue at hand, you were assigning mutated data when updating the new position inside saveTrackPanelPosition, so the selector is not seeing the change due to the shallow compare. I've quickly modified the assign here for assign({ trackPanelData: {...tempTrackPanelData} }) and I can see the drag position updating afterwards.

[mighty snow]

Thanks. I'll give that a shot!

[mighty snow]

Where did you do that? Can you share the sandbox?

[proven merlin]

I haven't forked anything, just tried directly on your shared project, mostly at the bottom of the mixerMachine file.

But like I said, there's a lot going on here. As soon as I start dragging the dialog around, the song that plays comes to a crawl and eventually stops playing, but this is a first step in getting things right. Just need to find what are causing the performance drops. One example is the ChannelStrip component, which listens to the whole trackPanelData, so any update to it will rerender everything below. I'd like to take a deeper look if I can find time, but this project definitely looks promising.

[mighty snow]

Does this address what you're talking about "One example is the ChannelStrip component, which listens to the whole trackPanelData,"
https://stackblitz.com/edit/github-ulwekt?file=package.json

[mighty snow]

I refactored it to address what you were talking about but it didn't make a difference. https://stackblitz.com/edit/github-s5p2do?file=src%2Fmachines%2FmixerMachine.ts

[jolly epoch]

What are the steps to reproduce the performance issues?

[mighty snow]

The performance issues are related to the track fx panels.

[jolly epoch]

Gotcha (just saw the other comment), looking

[mighty snow]

This is a different version than the sandbox in the other post btw.

I refactored it to address what @proven merlin was talking about. I think...

not sure which is better. probably this one.

[jolly epoch]

Okay, I'll look at this one

Without looking, chances are if you're managing drag position in that same state machine, that's the likely culprit

This goes for any state management - there's too many updates happening too frequently to one store

When in reality, it's local to that component (until you're done dragging)

[mighty snow]

So I should use useState or useReducer?

[mighty snow]

Oh. I just realized only the Reverb works on that sandbox.

[jolly epoch]

You can use a local useMachine too

That won't affect the context, the dragging will only be isolated to that component

Which should improve performance

[mighty snow]

🤔

Okay. I'll try that.

[jolly epoch]

Let me know how it goes. You're working on a really ambitious example; no doubt you'll be an XState expert by the end of this haha

[mighty snow]

how am I able to drag the bus fx panels without performance issues?

[jolly epoch]

Can you point me to the code that is doing the dragging logic?

[mighty snow]

Oh. Maybe it does have performance issues. Hold on, let me double check. I have a few different versions now.

[mighty snow]

If you look at this version, the bus fx panels are able to drag and resize without performance issues. https://stackblitz.com/edit/github-pfc4lv?file=src%2Fcomponents%2FChannelStrip.tsx

...but the track fx panels aren't.

able to.

...that one crashes when the settings are changed. I just realized.

Nevermind. It's not important. I'm doing the local state thing now.

[jolly epoch]

Okay, let me know if that improves things

[mighty snow]

I started by just using useState to localize that data and there's still performance issues. I think they're related to the fx settings using context.
https://stackblitz.com/edit/github-ffbgbb?file=src%2Fcomponents%2FChannelStrip.tsx
Wouldn't it just be better if I hadn't used createActorContext from the start and just used props like @tulip cradle mentioned #1104805753686069391 message.

[jolly epoch]

Can you pinpoint which properties are updating frequently and causing the perf issues?

[mighty snow]

Good question... I think so.

lol... I'm assuming you want me to tell you what they are.

...ummm. I guess any of the track panel settings (ie: position, size, active) and track fx settings (ie: reverbDecay, delayMix, etc...).

[jolly epoch]

So I'd make sure that when you're dragging, those track panel settings aren't being set

You can "temporarily" set them in the component (useState or whatever) and then when you're done, send an event saying "here is the final position it should be at"

[mighty snow]

Okay

[mighty snow]

Can I please just not use createActorContext? Is that possible? I'm a big fan of props drilling.

[jolly epoch]

Yes of course

[mighty snow]

Okay. I have to learn how to do that. I have to start all over though...