Comments (10)
Ideally, you wouldn't need isDatePickerActor
at all there. Its type should already be derived from whatever you have defined in the setup
, see an example here
The union of actor types does actually cause problems too. It causes issues with matches and can specifically. typescriptlang demo
This is fixable, we just need to remove this
type from those methods. Could you open an issue about this?
from xstate.
@devanfarrell You will soon be able to use maybe-undefined actors in useSelector(actor?)
: #4231
That should make things a lot easier.
from xstate.
I realized there are more issues with the things I wrote. You can't actually pass a param to enqueue actions so I don't even think you can stop an actor and remove it from context without doing so imperatively. I did figure out you can enqueue an assign in place to assign and kill the child machine if I do so within the createMachine
definition but I have to reuse this function 17 times in the code I'm trying to refactor so copying and pasting it that many times is kind of gross.
from xstate.
To be fair, this isn't a v5 problem. This was always quirky/incoherent. Even if you were able to call child.stop()
in assign
... that wasn't the right thing to do. assign
is really meant to be pure and .stop()
is not.
I wonder - do you even need to keep those actors in context? We were wondering about soft-deprecating the spawn
in assign
. To do that we need to figure out some pieces around spawnChild
/stopChild
to make it fit more use cases. Do you imagine that could fix your problems? In my opinion, it's kinda quirky that you need to remove an actor from the context and stop it manually in the first place. So I don't exactly see stopChild
being exposed to assign
as a solution. It would be better if those things would just work automatically out of the box and if they could be treated as a single operation - to achieve that we'd have to recommend using spawnChild
/stopChild
alone since that would shift the responsibility of storing actors completely on us.
from xstate.
I think that would cause a bunch of different problems. The nice part about having them in context is that we don't have to discriminate unions in typescript if we need to interact with an actor directly. On top of that I can easily communicate with context how the various actor instances are maintained, I might have a single instance of one type of actor upon initialization, another conditionally, and n of this other type of actor. If you have to discriminate those unions any time you interact with them in the client or the machine itself it's going to be really painful.
Imagine this scenario, I create a machine that schedules appointments. It spawns an actor that connects to my date picker component. In order to wire up those machines right now looks something like this.
const Scheduler = () => {
const [state, send] = useMachine(myMachine);
return <><DatePicker actor={state.context.datePicker}/><>
}
If I had to do that imperatively I imagine my code would end up looking something like this. I would actually put isDatePickerActor in the machine file but this is for brevity.
import { DatePickerActor, DATE_PICKER_ID } from '@components/datePicker/DatePicker.machine.ts';
const isDatePickerActor = (actor: DatePickerActor | AnyActor | undefined): actor is DatePickerActor => 'id' in actor && actor.id === DATE_PICKER_ID;
const Scheduler = () => {
const [state, send] = useMachine(myMachine);
const datePickerActor = state.children.get(DATE_PICKER_ID)
if(!isDatePickerActor(datePickerActor)) throw new Error("DatePicker actor improperly connected");
return <><DatePicker actor={datePickerActor}/><>
}
This is how we use actors all the time which is also why the previous behavior of useActor
actually made a lot of sense for use. The scenario where you have actors that live for the duration of their parent actor, others that are conditionally spawned, and we actually have n number of a union of actor types on certain machines.
from xstate.
The union of actor types does actually cause problems too. It causes issues with matches
and can
specifically. typescriptlang demo
from xstate.
Been playing around with the children property directly instead of using context. It doesn't seem to be too bad if you rely on typescript template strings. I think it does raise the barrier of entry slightly as far as typing goes but I can't really think of anything that couldn't be achieved with this pattern and template strings. Here is what I would consider a pretty heavy edge case where you needed to split all the book and news actors from our previous discussions. typescriptlang demo
from xstate.
Are these typings intentional on children
? It does make using useSelector
kind of a pain types wise. You have to use layers of components in React since hooks can't be called conditionally. There is a benefit of using refs in this scenario because you can ensure an actor is spawned in context and explicitly communicate that the actor is always defined.
children: {
news: 'news',
book?: 'book
}
^ {news: NewsMachine | undefined, book: BookMachine | undefined}
from xstate.
In the context of programming, the directive to "include stopChild in the first argument of the assign function" suggests that you need to modify a function call to include a parameter named stopChild within its first argument.
The assign function is likely part of a specific programming language or framework, and it seems that you need to pass the stopChild parameter to this function. This parameter could be used to control or stop certain child processes or operations within the function.
from xstate.
Here's an example of how you might modify the function call to include stopChild:
// Original function call
assign(target, source);
// Modified function call with stopChild
parameter included
assign({ stopChild: true }, target, source);
from xstate.
Related Issues (20)
- Bug: @xstate/inspect has 4x peer dependency HOT 2
- Bug: type error when referencing guard with `check` inside `setup` HOT 1
- Bug: UnifiedArg drops the type of emitter from its "self" property HOT 1
- Bug: Spawned child machines should inherit the parent's clock HOT 1
- Bug: Type Error with Actions outside of Setup()
- Bug: Spawn and TS error HOT 1
- Bug: typegen.ts ist incomplete when moving state node configs to separate files HOT 3
- Bug: Promise actor error handling doesn't work as documented HOT 3
- Bug: types broken with assign HOT 2
- Bug: supplying generic input argument to setup actors for stubbing breaks invoke type inference
- Bug: When child state transitioned to final state, did not trigger onDone event and transition to next state
- Bug: [@xstate/store] typings broken HOT 2
- Bug: Bug with After event on restoring snapshot
- Bug: [Typescript] event target doesn't get restricted to declared state HOT 3
- Bug: HOT 3
- Methods like `provide` are lost when implementing Higher Level Actor Logic HOT 1
- Bug: system.get(id) not working after restoring a snapshot HOT 2
- Bug: Importing Xstate in a React-Native android project errors HOT 1
- Bug: History state in parallel machines is changing states unexpectedly HOT 2
- Bug: State entry action's actor value mismatch HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xstate.