Open radiodario opened 2 years ago
It's a limitation, however - I would expect this situation to not load a machine at all. It's better to fail fast than to pretend that things are OK when we clearly failed to process the whole thing.
Is it possible that this limitation will be addressed in the future, or are there workarounds besides putting everything in one file?
We'll be thinking if we should support those patterns or not. It definitely won't happen anytime soon. What kind of problems do you run into when you "put everything in one file"?
Mainly readability, usability and maintainability issues. I'm working with a fairly large and complex machine which has many actions, hierarchical and parallel nested states, function helpers, etc. Splitting it is definitely necessary for my team to be able to modify a specific section without getting too lost.
Have you tried editing the machine visually with our VS Code extension? If yes - how did you find the experience in comparison to editing the files manually?
I haven't yet tried that functionality, so I will have to let you know how well it works for us. I'm in the process of upgrading the state machine on a project and integrating Typegen has been part of that process, though I have seen that it's limited when it comes to nested states extracted into separate files.
Hi there, Thanks a lot for XState.
I have quite a complex machine that contains parallel states in one of the compound state nodes.
The typegen works fine if all my parallel state definitions are in the same file, but if I extract the parallel states to separate files and I Import them, it fails to recognise them:
Here's a link to a gist with a sample machine and its typegen output
Is this expected behaviour, or just a limitation of the typegen?