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
Why doesn’t Recoil manage the unique key in atom and selector #378
Comments
See #32 (comment) Having a string key is necessary to provide a fixture for state which survives past the lifetime of the app -- it enables scenarios such as debugging for dev tools, and stable persistence. A question some of our team members are curious about: how burdensome is it to add keys? |
Thanks @mondaychen for clarifying. Yeah, but it’s really burdensome to manage the uniqueness of keys. Since it’s good only for a few use cases, I suggest making it optional. I’m not sure if it’s a good idea but just a thought. |
...although I haven't found creating key names a burden at all :) |
My team is looking into adopting Recoil for a project, but since we expect the project to grow and stay around for a long time, we're very concerned about key collisions happening. It seems like a landmine whose surface area gets bigger and bigger the more you work on an app. Maybe generate a key internally as a fallback, but have tutorials and documentation strongly encourage adding an optional |
See this issue, when #56 (which should probably still be open) is implemented this may be a possibility. I don't know if they'll go for it, but that's a blocker atm. |
hi, im using recoil lib custom compiled for react native with some helper:
two weeks, working fine dont understand from where 'memory-leak' can be... if not create them inside dynamic functions... but then we cannot import them... |
naming is really hard. |
I think the issue here is that many of us don't care about persisting our recoil state. For that use case there's really no need for us as users to think about these unique IDs, they're just boilerplate + a footgun. |
This way may cause some problems such as cache, when you refresh page, will uuid change? |
Still, this is an issue only if the state persists through page reloads. I'd argue that most people are not interested in this scenario (based on the situation in other state libs, i.e.
Those seem like opt-in features – if Recoil doesn't use those keys for anything internally then I don't see a reason to generate them at all (even automatically by Recoil itself) if the user doesn't explicitly ask for it 🤔 (i.e. by passing in a For persistence it seems like there is no other option than to force the user to define the keys (to avoid the aforementioned problem of uuids changing between reloads). |
As a new user, I don't find it cumbersome at all to use, simply a bit odd (I agree with OP, anything that can be automated should be) and confusing. I start asking myself "Mmmm... why are they asking me to set a unique key, what am I missing? WHY?? Are they used by selectors perhaps ... ?" and then went on a wild chase trying to understand why these keys are not handled internally. That's how I ended here. In the end it's not a big deal, but it's it lowers my confidence that I understand what is going on, as well as the minor time waste. A simple remark in the |
Please save me from naming +1 😂 |
A good intermediate option is https://github.com/dsherret/ts-nameof/tree/master/packages/ts-nameof.macro
|
There is something called |
I don’t see that the user needs to use the defined key anywhere. So why does he/she needs to create it manually ?
The text was updated successfully, but these errors were encountered: