Recoil
Recoil copied to clipboard
facebookexperimental
What's happening in the future of recoil?
Switched over one of my projects to recoil and its so much better than redux its absurd. I will never use redux again if I don't have to. But I was curious about what features are planned for future development?
I don't see a roadmap or anything so I was wondering if someone could post a roadmap if it exists.
I like to know about future features/enhancements so that I can design the code with those new features in mind. I would also love to know what the far future goals are for say version 1.0, or even 2.0?
It would be really good to see something like this so as those of us that want to use this in a production app have confidence we've evaluated it appropriately...
you've been experimental for a year and a half now... when is experimental => professional ?
Too many folks out there can't use this for production apps because its labelled "experimental". It would be nice to know the ETA of recoiljs stable release.
I keep checking back every now and then too. Having a library be experimental for so long has been discouraging me from using it so far even though I’d like to try it out. So far I’ve heard only praise about it.
I know it’s important to iron out the quirks and API especially since the authors might end up having to maintain it if it ever becomes stable, but at least a rough estimate (few months, years, decades, never) might be good so we can orient ourselves better.
And I’m sure like minded developers (although maybe not everyone) on here will agree not to hold the authors accountable if such a long shot prediction turns out inaccurate. Hey, at least it’s something.
This reminds me a bit of Ramdas major release aversion btw. (German word of the day being Hauptversionsnummernerhöhungsangst). I know it’s not exactly the same thing here but it’s a real problem a library can fall into and never recover from.
I'm just rooting for more transparency regarding the roadmap (hopefully there is one), new features, stability improvements and getting to a stable version that i can confidently use in production
@serp777 I'm part of a Meta team in the open source space, although I'm not directly affiliated with Recoil. Your question is perfectly reasonable. During the winter holidays, it's more difficult to get a hold of the right people to provide status updates on projects, but I'm trying to follow up and I'll make sure you get a reply as soon as people return back into the office. Thank you for being patient!
@serp777 I'm part of a Meta team in the open source space, although I'm not directly affiliated with Recoil. Your question is perfectly reasonable. During the winter holidays, it's more difficult to get a hold of the right people to provide status updates on projects, but I'm trying to follow up and I'll make sure you get a reply as soon as people return back into the office. Thank you for being patient!
Thank you, I just wanted to acknowledgement that this would be addressed at some point, happy holidays
Thank you, everyone, for your support of Recoil. We at Meta are as excited about what's next for the project as all of you are! We are always amazed by the vibrant and ever-growing open source community. We want to continue sharing our work on Recoil to help make state management for React as straightforward as possible.
Our immediate plans are to release Recoil 0.6 to keep the library compatible with the latest direction of React 18. We are also working on an add-on Recoil library called Recoil Sync that provides helpers for syncing with external state, including built-in support for syncing with the browser URL history.
Recoil remains an experimental project as it evolves to support React and its state management. Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
We are not alone in addressing these concerns since other state management libraries also work towards staying up-to-date with React. And as always, we want to thank you once again for being a part of this community and helping us make Recoil better together.
Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
Wouldn't those be reasons for a new major version number? Not to keep it 'experimental'?
Experimental to me means it might not survive...not that its searching for the best API given a changing dependency. If the API needs changing I would simply expect a new major version. The 'experimental' status makes people think they can't use this library.
@drarmstr
Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
Wouldn't those be reasons for a new major version number? Not to keep it 'experimental'?
Experimental to me means it might not survive...not that its searching for the best API given a changing dependency. If the API needs changing I would simply expect a new major version. The 'experimental' status makes people think they can't use this library.
@drarmstr
Exactly. This. The library feels / looks mature but the above statement doesn't provide much hope that it will go out of experimental state any time soon
"we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features".
That's quite a broad requirement.
Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
Wouldn't those be reasons for a new major version number? Not to keep it 'experimental'? Experimental to me means it might not survive...not that its searching for the best API given a changing dependency. If the API needs changing I would simply expect a new major version. The 'experimental' status makes people think they can't use this library. @drarmstr
Exactly. This. The library feels / looks mature but the above statement doesn't provide much hope that it will go out of experimental state any time soon
"we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features".
That's quite a broad requirement.
It is a broad statement. Because upcoming react features will always be changing and evolving, it doesn't seem possible that you'll ever catch up.
In hindsight, I suspect the below statement...
"we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features ..."
... refers to just these React 18 scoped features. So as long React 18 has not been released & tested this library won't go out of experimental state which I can understand. I was too fast with my previous comment.
💯 this!! I would love to be able to, external facebook, see the RFCs for Recoil Sync and other related resources to get a better sense of what's on the recoil roadmap. The existing docs and the flexible conventions in place to allow for future functionality are very helpful, but I've noticed when poking around some of the work in progress a lot of it is walled behind fb phabricator (eg: I can't tell from just the source and PRs what is coming up w/ recoil-sync)
Our immediate plans are to release Recoil 0.6 to keep the library compatible with the latest direction of React 18. We are also working on an add-on Recoil library called Recoil Sync that provides helpers for syncing with external state, including built-in support for syncing with the browser URL history.
@drarmstr just seeing this comment! It's very helpful for me to get a rough sense of features on the horizon so thanks for sharing. Is there anywhere I can stay plugged in so I know what efforts are best saved for ~3-8 months down the road since I'm working on a very gradual move to recoil?
Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
Wouldn't those be reasons for a new major version number? Not to keep it 'experimental'?
Experimental to me means it might not survive...not that its searching for the best API given a changing dependency. If the API needs changing I would simply expect a new major version. The 'experimental' status makes people think they can't use this library.
@drarmstr
Agreed. Surely the explanation given would mean Recoil will always have to remain experimental—because React is in active development and something in React may change anytime.
We need to be able to give those making decisions the confidence that it's okay for us to use Recoil, especially when developing for certain companies or industries, and the 'experimental' label prevents us from doing that.
^^ Bumping this. While my team would love to use recoil as it solves a lot of our problems, there's no way we can make a case for using it in the company as long as it stays experimental. So while we would love to be able to contribute, we most likely won't be able to since we can't use it. 🥲
Thank you, everyone, for your support of Recoil. We at Meta are as excited about what's next for the project as all of you are! We are always amazed by the vibrant and ever-growing open source community. We want to continue sharing our work on Recoil to help make state management for React as straightforward as possible.
Our immediate plans are to release Recoil 0.6 to keep the library compatible with the latest direction of React 18. We are also working on an add-on Recoil library called Recoil Sync that provides helpers for syncing with external state, including built-in support for syncing with the browser URL history.
Recoil remains an experimental project as it evolves to support React and its state management. Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
We are not alone in addressing these concerns since other state management libraries also work towards staying up-to-date with React. And as always, we want to thank you once again for being a part of this community and helping us make Recoil better together.
first of all, Thank you for all the good work on recoil. And i think this project is in experimental phase more than it needs to be! can we get any official update on this please.
@mickremedi You could try out jotai. It's very similar to recoil, but I found it both simpler and more flexible.
@mickremedi You could try out jotai. It's very similar to recoil, but I found it both simpler and more flexible.
I think I'll pass. I'm more confident in recoil given its supported by facebook/meta. Its being developed closely in parallel with regular react so it doesn't seem worth it to switch to an obscure alternative maintained by Joe/Jane Blogg.
I wonder if the macroeconomic effects are the cause here. The fact that we get one response in 10 months and that the authors aren’t concerned about community not using it is more than a bit concerning
buenas sinceramente recoil es lo mas, pero identico a los demas colegas no se puede justificar el uso en empresa mientras mantenga el termino de experimental, si se entiende que el problema es el server side, ok, pero saquen el experimental para el estandar y mantengan a wip el resto, no hay problemas mas que la palabra 'experimental'
Thank you, everyone, for your support of Recoil. We at Meta are as excited about what's next for the project as all of you are! We are always amazed by the vibrant and ever-growing open source community. We want to continue sharing our work on Recoil to help make state management for React as straightforward as possible.
Our immediate plans are to release Recoil 0.6 to keep the library compatible with the latest direction of React 18. We are also working on an add-on Recoil library called Recoil Sync that provides helpers for syncing with external state, including built-in support for syncing with the browser URL history.
Recoil remains an experimental project as it evolves to support React and its state management. Although we are using Recoil in production at Meta, we keep the project in an experimental status today until we are confident in a solution compatible with all upcoming React features like Concurrent Rendering, Server Components, and Streaming SSR.
We are not alone in addressing these concerns since other state management libraries also work towards staying up-to-date with React. And as always, we want to thank you once again for being a part of this community and helping us make Recoil better together.
@drarmstr Hi, any updates on a product roadmap or when you'll be able to move it out of experimental?
Wow this is ridiculous. All of these issues are just people asking questions with no reply from anyone at Meta. It's disrespectful after a certain point. (That point is probably after two years of unanswered questions.) And no, the already year-old response from @drarmstr doesn't count, because it was too vague and sweeping to be helpful.
Here is to moving all support and love to jotai since I haven't even looked but can almost guarantee they will take better care of a community.
@rgcl Why would I use Svelte? React is incredibly mature at this point. There are a ton of open source libraries and packages that are very refined and very high quality. There's no way Svelte is competitive in that regard.
React is used in a huge number of enterprise environments, its very popular, and its backed by a large company. It's very feature-rich. Svelte is obscure by comparison, and I'm not sure what I'm supposed to gain by switching. Also, hiring react developers is easy because of how popular react is. Good look finding a large number of skilled Svelte developers.
We have switched to zustand because of the lack of updates and trust of this repo going anywhere...
looks like zustand or jotai is the way to go