What's happening in the future of recoil? #1495
Comments
|
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.
|
|
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! |
Thank you, I just wanted to acknowledgement that this would be addressed at some point, happy holidays |
|
following |
|
Would love to hear more on it. |
|
Same here. Would love to know more about the roadmap for RecoilJS. |
|
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. |
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. |
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
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...
... 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/ |
@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? |
|
@jessrosenfield - Preview documentation for Recoil Sync and Refine has now been published. |
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. |
|
Any update on this? |
|
^^ 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. 🥲 |
first of all, Thank you for all the good work on recoil. |
|
@mickremedi You could try out jotai. It's very similar to recoil, but I found it both simpler and more flexible. |
|
I wonder if the macroeconomic effects are the cause here. |
|
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' |
@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. |
|
Still using React? Why if Svelte exists? |
|
@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 |
|
Its certainly disappointing to have a lack of responses, I wonder if the developers for this repo were let go with the recent meta layoffs. Besides the updates, are there any features or benefits of zustand or jotai over redux? I've found redux to meet all of the functionality needs, so switching just because of the lack of updates isn't a good enough justification fo rme to spend time switching and re testing everything. |
If you're using redux then zustand will be more familiar than jotai. It's mainly just simpler. Since Redux was made, we've learned a lot about how reducer-based state stores get used in practice, so a lot of features that redux requires helper libraries for are baked directly into zustand. Actions require less boilerplate, async actions and selectors are built-in features, etc. It's also a lot smaller. |
|
Hey peeps, Maintaining projects can be unthankful work, however the license is MIT so anyone is free to fork and continue development and maintenance. And anyone is free to use alternatives or even use svelte if that's what you want. I do get that you want to challenge the status quo. But perhaps you could just use the alternatives without notifying everyone who's watching this thread. |
|
@webbertakken Well thank you for the work that's been done so far. Despite the other comments on here I do think recoil is excellent, and I don't believe its warranted to switch to Jotai or something else. However, by saying that anyone is free to fork and continue development/maintenance, are you implying this repo is dead? The suggestion I'm interpreting from your comment is: "We're not going to be doing any more contributions or community outreach, so you can take over that job for us". Please correct me if i'm mistaken. The reality is that nobody is going to fork, develop, and maintain this repo because it was started by meta developers. If those developers are gone, its way too much of a commitment to take over. One of the big appeals of this repo is that it's backed by meta. If you're saying this is no longer backed by meta then that's going to change the calculus for many people. |
I think letting maintainers know they are losing people and why is important. I (and all projects I lead that were or were going to use recoil) have also left and now use jotai - as that projects maintainers seem active and respond to comments as basic as 'what is happening with this thing' and they don't simply ignore people for years on end asking the most basic of questions. Yes its 'unthankful' on some level...but straight up ignoring very legitimate and very basic questions about a projects status is untenable. And yes, letting others know about it is important. I really cannot recommend recoil and recommend everyone find an alternative |
|
@jonbnewman you make excellent points. I also don't think it's the answer to tell the people suggesting alternatives/complaining to go "fork" themselves, no pun intended, and to take on ownership of an entire repo. |
|
@victorelu made me aware that the core contributor @drarmstr has been laid off in January, as he self shared on LinkedIn: https://www.linkedin.com/posts/douglas-armstrong-384a342_opentowork-meta-layoffs-activity-6996668167511052288-UoE4 I think that explains the radio silence, although the code frequency never has been high and mostly limited to type fixes since October: https://github.com/facebookexperimental/Recoil/graphs/code-frequency I'm afraid we'll have to look into https://jotai.org/ as well. |
|
@FokkeZB Or we can fork it and continue with Recoil ;) But agree. It seems the recoil is quiet now. I contacted @drarmstr before but no answer so far. We used recoil a lot and we like it. I assume that you guys have it the same. Don't you want to jump on a call maybe? Chat about the experience with it, possible alternatives and what to do next. What do you think? DM me on Twitter if you are interested. Twitter: https://twitter.com/xotahal |
|
Word of warning: Would advise against Recoil As much as I love the package, we've noticed some memory leaks related to Recoil in prod, and are in the process of switching to Jotai instead |
|
Recoil has been excellent and I love that it introduced me to this new state management architecture, but unfortunately, it appears this repository is dead. Farewell, all, like many here I'm heading to Jotai unless this repo is restored and maintained. Thank you to all the work the existing devs have done here and best to you all. |
|
2 years ago my work went forth with a "production" app using recoil. I was very happy to be able to mix async & sync dependencies and write it all as sync code. Today our team is pretty much in agreement that we need to switch away. The lack of developer tooling to make state visible is the most egregious issue (Recoilize is abdandonware as well). We went to make the switch to jotai, only to discover that in jotai v2 they will no longer unwrap promises for you, dramatically changing how we would write our code vs jotai v1 (which would have been a near drop-in replacement for recoil). |
|
@zbyte64 I'm evaluating Jotai as well, but at least for dev tools, this project does work, and it's just a connector to the regular redux tools, so it actually does work: |
Rule of thumb. Don't design your code based on a specific tech. |
|
@afroguy16 That's not always practical or sensible. It depends on the context and the situation. The type of tech you select can have a profound effect on design patterns and architecture, and therefore code. You can extract something like business logic into generic code that isn't dependent on particular tech or external packages, but the code for react + recoil is going to look very different compared to an angular or blazor implementation. Its also often totally unavoidable, it just depends on the situation. Writing unnecessarily generalized code can also be a complete waste of time and a hindrance depending on the end objectives of the development project. Overall I would say this is not a good rule of thumb at all. How often is your project switching tech stacks? Its probably a very rare occurrence that's only done because of a critical limitation, bug, or problem. If you have to switch tech stacks frequently such that you need generic non dependent code, that would suggest to me something went very wrong in the planning, design, and selection phase of the project. You want to design your code based on the particular requirements of the project and what you're trying to achieve. |
|
Any updates? |
Jump to jotai ;) |
|
@dkfox jotai recommendation seconded. It's the closest thing to a production-ready recoil with proper support. |
|
Hi everyone 👋, TLDR; Check out clockelliptic/jotai-recoil-adapter. It's rough around the edges and could use community support, but has proven to be very useful so far. Please feel invited to contribute, fork, and copy as needed. see it on NPM: https://www.npmjs.com/package/jotai-recoil-adapter see also: #2288 🔍 What is jotai-recoil-adapter? 🌟 Features Include:
🤝 We Need Your Input! Current top priorities include:
🔗 Get Involved:
|
and others
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?
The text was updated successfully, but these errors were encountered: