Tweak what options are accepted by createActorContext and where

[Andarist]

fixes #3811

[changeset-bot]

🦋 Changeset detected

Latest commit: b87be16

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@xstate/react	Minor

Not sure what this means? Click here to learn what changesets are.

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

[ghost]

👇 Click on the image for a new way to code review

• Make big changes easier — review code in small groups of related files

• Know where to start — see the whole change at a glance

• Take a code tour — explore the change with an interactive tour

• Make comments and review — all fully sync’ed with github

  Try it now!

Legend

[Andarist]

this is a little bit of a breaking change for this test case:

xstate/packages/xstate-react/test/createActorContext.test.tsx

Lines 307 to 338 in 6f15b2c

	it('should be able to pass interpreter options to the actor', () => {
	const someMachine = createMachine({
	initial: 'a',
	states: {
	a: {
	entry: ['testAction']
	}
	}
	});
	const stubFn = jest.fn();
	const SomeContext = createActorContext(someMachine, {
	actions: {
	testAction: stubFn
	}
	});
	const Component = () => {
	return null;
	};
	const App = () => {
	return (
	<SomeContext.Provider machine={someMachine}>
	<Component />
	</SomeContext.Provider>
	);
	};
	render(<App />);
	expect(stubFn).toHaveBeenCalledTimes(1);
	});

[Andarist]

just rechecking - are we OK with this breaking change?

[davidkpiano]

Yes; options was in the wrong place

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b87be16:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[Andarist]

I used any for simplicity here since the return type of createActorContext is explicitly typed and I didn't want to include the typegen-related monster in both places here. I think that we could drop the explicit return type from there, annotate things in the body and let TS to infer things here. This way each signature would only have to live in one place

[Andarist]

I just removed export here

[davidkpiano]

Why can't we have the simpler type here? At least without AreAllImplementationsAssumedToBeProvided

[Andarist]

The added type-oriented tests wouldn't pass. It's quite nice that we validate if the user has configured all implementations or not (the cost for that is the readability of those types though 😬)

[davidkpiano]

Spooky types:

[davidkpiano]

The types are a little questionable, but LGTM 😅

[Andarist]

Spooky types:

I agree that those types don't have the best display in the IDE. It's not a new problem with our types though. I will keep thinking about how this can be fixed - it is quite hard with those kinds of types.