Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade XState to v5 #189882

Open
tonyghiani opened this issue Aug 5, 2024 · 4 comments
Open

Upgrade XState to v5 #189882

tonyghiani opened this issue Aug 5, 2024 · 4 comments
Labels
Team:obs-ux-logs Observability Logs User Experience Team

Comments

@tonyghiani
Copy link
Contributor

📓 Summary

After the upgrade to typescript v5, we can now consider the major upgrade of the XState state management library, which was blocked as it depended on the latest typescript major version.

The upgrade is from v4 to v5.x.x, which includes many improvements and comes with some breaking changes.

There is a migration guide provided by the XState team in the official documentation that can be followed to update the implementation if required.

Here can be found all the current usages of the library to check for required changes and correct functioning after the upgrade.

@tonyghiani tonyghiani added the Team:obs-ux-logs Observability Logs User Experience Team label Aug 5, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

@davidkpiano
Copy link

Let me know if you need any help with this.

@tonyghiani
Copy link
Contributor Author

Thanks @davidkpiano, we'll reach out for any doubts once we tackle this upgrade!

@weltenwort
Copy link
Member

Hey @davidkpiano, thanks for stopping by. I really like the new way to provide dynamic, strongly-typed parameters to actions. But I see some challenges in migrating:

Typestates: We're pretty heavy users of the typestate feature, which allows us to have nicely typed contexts in our react components. In many places we're .matching the state in a container component which then selects from a set of child components to render, which are specialized for a different state each and rely on specific parts of the context being populated. Without typestates we would have to have lots of optional properties in our context schema and repeatedly have to check for their presence in addition to matching the state. Can you recommend any pattern in v5, which would offer similar convenience and type safety?

Editor integration: The VSCode extension works quite well in our workflow. I cannot imagine how the studio would integrate with that. Are there any plans to bring the studio experience to a local development environment?

Thank you for creating such a great project and community!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:obs-ux-logs Observability Logs User Experience Team
Projects
None yet
Development

No branches or pull requests

4 participants