feat(vue): experimental scope dispose

[Hebilicious]

This is a draft PR that attempts to move away from component life-cycle hooks in composables to effect scopes .

All tests are passing, with one caveat :

Now nextTick needs to be used when passing a callback to useActorRef that access state that is not initialized.

  const actor = useActorRef(machine, {}, (nextState) => {
    nextTick(() => {
      state.value = nextState.value;
    });
  });
  const state = ref(actor.getSnapshot().value);

I feel like this is fine because this is kind of an odd pattern anyways.
Using onMounted is more idiomatic to vue imo, and maybe we should change the test to :

const state = ref() //shallowRef would work too
const actor = useActorRef(machine, {}, (nextState) => {
    state.value = nextState.value;
});
onMounted(() => { state.value = actor.getSnapshot().value });

(Users should not be using useActorRef directly in most cases anyways, so its fine if the test doesn't use shallowRef)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6d6c6ba

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Hebilicious]

@Andarist I've been testing this in production, it appears to be an improvement. Would you mind taking a look please?

[Andarist]

I'm not familiar with Vue at all so bear with me. I don't understand why this is using nextTick. Shouldn't the update be batched with whatever changes are in flight instead of waiting for the current DOM updates to flush and then scheduling a new update by updating state.value here?

[Andarist]

ah, I guess u have touched on it in the PR's description. So a different question - wouldnt it be better to skip the write to a =n uninitialized state instead of wrapping this update with nextTick?

[Hebilicious]

I would never write vue code like that in the first place with nextTick either, but it kinda works, even though it is hacky... I don't think we should encourage this pattern tbh, imo lifecycle hooks are the right pattern to initalize a value, as documented in the PR description.
But I wanted to hear your opinion instead of straight-up replacing the text.

[Andarist]

how this is meant to work with SSR? when the sub would get disposed (and when the actor would get stopped!) in that environment?

[Hebilicious]

You're right, onMounted and onUnmounted do not get called in SSR. This should work and respect current behaviour.

if (getCurrentScope()) {
  if (observerOrListener) {
    sub = actorRef.subscribe(toObserver(observerOrListener));
  }
  actorRef.start();
}

What do you think ?

[Andarist]

shouldnt we require a scope to be there? if it's going to be missing then cleanup code wouldnt ever run but setup would and its obtained resources would live indefinitely

[Hebilicious]

Might as well wrap everything in if(getCurrentScope()) since this should not run on SSR.

[Andarist]

What would be the advantage of moving to this API? how that would affect supported range of Vue versions?

[Hebilicious]

Hi @Andarist, One of the reasons I've started doing this in all my vue + xstate projects is because very often, you want to useSelector in an array of actors.

Consider the following real world example, where I'm constructing data to pass it to tanstack table :

const data = computed(() =>
	operations
		.map(({ id, operation }) => {
			const state = useSelector(operation, (state) => state)
			const { text, kind } = statusFromState(
				state.value.value,
				state.value.context.direction
			)
			return {
				id,
				operation,
				status: state.value.value,
				statusText: text,
				statusKind: kind,
				source: state.value.context.source,
				destination: state.value.context.destination,
				amount: state.value.context.amount,
				hash: state.value.context.transaction?.hash ?? "",
				date:
					state.value.context.transaction?.date.toISOString() ??
					new Date().toISOString()
			}
		})
)

Current useSelector implementation causes a bunch of "issues" with vue because component lifecycles don't exist outside a component setup function.
See RFC for effectScope.

Regarding version support, I believe it got introduced in 3.2 https://blog.vuejs.org/posts/vue-3-2, so this is reasonable (4y old +), but would require a bump to 3.2 min (https://github.com/statelyai/xstate/blob/main/packages/xstate-vue/package.json)

I believe this would also resolve #4754; and #5311 partially