Recoil: Why doesn’t Recoil manage the unique key in atom and selector

[mdovn]

I don’t see that the user needs to use the defined key anywhere. So why does he/she needs to create it manually ?

const textState = atom({
  key: 'textState', // this is used nowhere, why not just abstract it out?
  default: '', 
});

[mondaychen]

See https://github.com/facebookexperimental/Recoil/issues/32#issuecomment-629403087

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?

[mdovn]

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.

[DynamicArray]

@mdovn You could always use a library like uuid to handle the uniqueness for you.

This works:

import { v4 as uuidv4 } from "uuid";

export const myAtom = atom({
    key: uuidv4(),
    default: null,
});

[DynamicArray]

...although I haven't found creating key names a burden at all :)

[dkovacevic15]

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?

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 name value to the atom definition?

[Shmew]

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.

[leeratyou]

hi, im using recoil lib custom compiled for react native with some helper:

import 'react-native-get-random-values'
import { v4 as uuidv4 } from 'uuid'
import * as recoil from './original'

const { atom: recoilAtom, ...rest } = recoil

function atom(defaultValue) {
  const uuid = uuidv4()
  return recoilAtom({
    key: uuid,
    default: defaultValue
  })
}

module.exports = {
  atom,
  ...rest
}

two weeks, working fine
atoms created only on start of application and not re-initialized during app lifetime

dont understand from where 'memory-leak' can be... if not create them inside dynamic functions... but then we cannot import them...

[uptonking]

naming is really hard.
since key can be generated automatically using tools like uuidv4(), I want Recoil to handle the task for me.
Human is unreliable, easy to make names conflict.
please save me from naming.

[pelotom]

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.

[Cast1R]

hi, im using recoil lib custom compiled for react native with some helper:

import 'react-native-get-random-values'
import { v4 as uuidv4 } from 'uuid'
import * as recoil from './original'

const { atom: recoilAtom, ...rest } = recoil

function atom(defaultValue) {
  const uuid = uuidv4()
  return recoilAtom({
    key: uuid,
    default: defaultValue
  })
}

module.exports = {
  atom,
  ...rest
}

two weeks, working fine
atoms created only on start of application and not re-initialized during app lifetime

dont understand from where 'memory-leak' can be... if not create them inside dynamic functions... but then we cannot import them...

This way may cause some problems such as cache, when you refresh page, will uuid change?

[kdmadej]

https://github.com/facebookexperimental/Recoil/issues/378#issuecomment-751221106

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. redux which has 4.4kk weekly downloads vs redux-persist with 400k – around 10% of the users being interested in persistence).

https://github.com/facebookexperimental/Recoil/issues/378#issuecomment-648314856

it enables scenarios such as debugging for dev tools, and stable persistence.

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 debug flag to Recoil, which would cause it to generate keys on its own if one hasn't been defined by the user).

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).