That is that, you could do...

    useState("someID")

    useState("someID")

    useState(Symbol("someID"))

    let someSymbol = Symbol("someID");

    useState(someSymbol)

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.

Also... a nitpick, but `new Symbol` always throws a TypeError. And Symbol.for() is a useful escape hatch.

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

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.

Then `useFormInput()` wants to add another state (e.g. `isHovered`). How are you going to compose Symbols? We get to the next flaw (manual composition is annoying and error-prone).

I would’ve used a WeakMap with Symbol keys that mapped to a list or object containing Symbols.

Sorry if I’m just overlooking something obvious, but most of the examples that I’ve seen to explain why Symbol keys aren’t better than the current proposal seem to be just be examples of badly implemented custom hooks, not necessarily flaws with Symbol keys per se.

A key design goal is that creating a custom Hook is easy. You should be able to literally copy paste part of your component (e.g. a bunch of useState calls and some event handlers) and call it a day.

I'm struggling to see how what you're suggesting could be easy for the end user but maybe I'm missing something.

> A key design goal is that creating a custom Hook is easy. You should be able to literally copy paste part of your component (e.g. a bunch of useState calls and some event handlers) and call it a day.

I'd totally understand that reasoning, because the keyed Hooks are more verbose and would generally require two or three parts of a component to be copy-pasted – but the examples under Flaws #3 and #5 didn't make this clear (to me at least), and I hadn’t seen ‘ease of custom Hook implementation’ cited as an argument against keyed hooks before.

I’m really just playing devil’s advocate here, because in my playing around with Hooks I haven’t yet found a case where keyed Hooks are necessary, but I have accidentally put calls to useState() inside a conditional a heap of times.

Edit: Flaw #5, not #7

My post does mention that we care about copy paste experience:

>Code passing non-unique or badly composed keys would accidentally work until a Hook is called multiple times or clashes with another Hook. Worse, if it’s meant to be conditional (we’re trying to “fix” the unconditional call requirement, right?), we might not even encounter the clashes until later.

>Remembering to pass keys through all layers of custom Hooks seems fragile enough that we’d want to lint for that. They would add extra work at runtime (don’t forget they’d need to serve as keys), and each of them is a paper cut for bundle size. But if we have to lint anyway, what problem did we solve?

I later go into why allowing conditional declarations of state or effects isn’t even particularly useful or desirable because the semantics are too confusing. So I do think I kind of addressed that.

The book keeping could be moved into a couple of utility functions - it’d be largely the same for most custom hooks.

I’m also not sure relying on a linter is necessarily going to make static call Hooks simpler. Poorly written hooks are going to be buggy whether they’re Symbol keyed or not. I think that one of the big disadvantages of static call Hooks would seem to be that incorrect conditional usage could still accidentally work.

> My post does mention that we care about copy paste experience

I think I misunderstood that section when I first read it - it makes sense now. I’m not convinced it’s a huge win though.

> I later go into why allowing conditional declarations of state or effects isn’t even particularly useful or desirable because the semantics are too confusing.

We’ll have to agree to disagree - while I’m not eagerly wanting to use Hooks in conditionals, I dont think the semantics are that confusing.

A) Symbols often get interned as a part of the modules that own them and may never be garbage collected in the lifetime of an app. Thus the items in the WeakMap may never expire (because modules themselves are currently rarely unloaded/garbage-collected).

B) Primitive data types are actually expressly prohibited from being WeakMap keys in the spec (to avoid issues like [A]), and proper implementations are expected to throw errors if you try. MDN expressly makes this clear that this means that Symbols are not allowed to be WeakMap keys:

> Primitive data types as keys are not allowed (e.g. a Symbol can't be a WeakMap key).

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

the example would become something like:

    const nameNamespace = [Symbol()];
    const surnameNamespace = [Symbol()];

    const name = useFormInput(nameNamespace);
    const surname = useFormInput(surnameNamespace);


    const valueKey = Symbol();
 
    function useFormInput(namespace) {
      const [value, setValue] = useState(extendNamespace(namespace, valueKey));
      return {
        value,
        onChange(e) {
          setValue(e.target.value);
        },
      };
    }