3 ms·

It's not really well explained in the article, but the argument against Symbols is that you (client code) have to store them somewhere for reuse in different ca

It's not really well explained in the article, but the argument against Symbols is that you (client code) have to store them somewhere for reuse in different calls. That is that, you could do... useState("someID") ...and somewhere else (* or in the same place but on a different call) again... useState("someID") ...and this indeed refers to the same item. But using a Symbol, you need to first create it, store it somewhere and then use it. That is, you can't do this... useState(Symbol("someID")) ...because this will fail through different repeated calls. Instead you'd need to first... let someSymbol = Symbol("someID"); ...and then... useState(someSymbol) Or, alternatively, use Symbol.for("someID"), which then has both problems: creating the symbol first and clashing of identifiers. While the article does not explain this clearly, the example used alludes to this in an indirect way. Personally I do think that this would be a more desirable sacrifice to make than restricting call order, but the React team thinks otherwise, it seems.

thomasfoster96 8y ago
That’s not really all that different to everyone moving their CSS-in-JS and GraphQL queries out of a functional component body though, is it? This is kind of exactly the scenario Symbols seem to have been intended for. Also... a nitpick, but `new Symbol` always throws a TypeError. And Symbol.for() is a useful escape hatch.
- genezeta 8y ago
  > Also... a nitpick, but `new Symbol` always throws a TypeError. And Symbol.for() is a useful escape hatch. Yes, you're right. I was distracted with other stuff and meant just Symbol, without new. I'll fix it. Thanks. As for the rest... Well, I don't really care much for React and many of the decisions they make. I don't like CSS-in-JS at all, and GraphQL... well, that one's nothing new.
- danabramov 8y ago
  >That’s not really all that different to everyone moving their CSS-in-JS and GraphQL queries out of a functional component body though, is it? I suggest you to take the `useSubscription` example from the "diamond problem" section and try to convert it to your proposed API. I think you'll see why it falls apart. (Don't forget effects would also need keys.)

thomasfoster96 8y ago

That’s not really all that different to everyone moving their CSS-in-JS and GraphQL queries out of a functional component body though, is it? This is kind of exactly the scenario Symbols seem to have been intended for. Also... a nitpick, but `new Symbol` always throws a TypeError. And Symbol.for() is a useful escape hatch.

genezeta 8y ago
> Also... a nitpick, but `new Symbol` always throws a TypeError. And Symbol.for() is a useful escape hatch. Yes, you're right. I was distracted with other stuff and meant just Symbol, without new. I'll fix it. Thanks. As for the rest... Well, I don't really care much for React and many of the decisions they make. I don't like CSS-in-JS at all, and GraphQL... well, that one's nothing new.
danabramov 8y ago
>That’s not really all that different to everyone moving their CSS-in-JS and GraphQL queries out of a functional component body though, is it? I suggest you to take the `useSubscription` example from the "diamond problem" section and try to convert it to your proposed API. I think you'll see why it falls apart. (Don't forget effects would also need keys.)