Make possible to get component stack or at least its hash

[finom]

Do you want to request a feature or report a bug?

feature

What is the current behavior?

There is no good way to get the a list of component parents. The only way to do it is to wrap the rendered component to an error boundary, throw a dummy error and pass componentStack to the rendered component without throwing the error again.

Unfortunately the idea of hiding thrown errors was refused (see #11098) so this experimental hack isn't useful.

What is the expected behavior?

I'd like to deterministically identify components at DOM tree and use this data to assign persistent data to it without using any custom identifiers. For example store visibility state for a specific component at window.localStorage.

Related to #1137

[gaearon]

The notion of having a persistent identifier is flawed unless you can somehow guarantee you're going to get 1:1 exact tree structure after reload. What gives you this guarantee?

[finom]

@gaearon thank you for the response. Every use of a non-list component gets its unique stack of parents (in case if component names different). For example the heading of every issue here could be a child of the following "stack": <Issue /> <- <Repository /> <- <Page /> which always remain the same because props (data) don't affect on it. Every component can be re-used at different places but then it will get its own stack of parents which means this is another "logical element".

A component can be rendered as a child of one parent then it can be rendered as a child of another parent but for me this "child" actually changes its meaning and the identifier must be different.

<Container>
  <A>
    <Child />
  </A>
</Container>

<Container>
  <B>
    <Child />
  </B>
</Container>

Are these Childs different (as logical elements)? I think yes.

I imagine the unique ID as a checksum of concatenation of parent component source codes and its key: md5(Parent1.toString() + Parent2.toString() + Parent3.toString() + key) that's the ideal case. IMO the hash function can be simpler (because there is no requirement to make it secure) and instead of toString() we could use name or displayName here.

What do you think?

[gaearon]

I guess I'm saying that there's no way to enforce that this stack is "stable". You might have a library in the middle that will choose to rename some internal component in a patch release. A minifier could change semantics of your code by reusing the same "name" for different components (because functions get mangled). I can see how a feature for grabbing a DEV-only stack would be helpful for some cases, but this is too fragile to rely in production. Maybe context and some explicit nested providers would work better for you?

[finom]

@gaearon hmm, makes sense. But what about component source code (Component.toString() like I proposed above)? I'm not sure how would it affect on performance. Providers and stuff sound overcomplicated for this issue. I would prefer to use custom identifiers then.

[gaearon]

Component's source is just as fragile; two components can trivially share the same source code.

Providers and stuff sound overcomplicated for this issue.

It explicitly models what you're trying to do. It's the implicit assumptions like stable function names or source that make it complicated.

[finom]

Hmm, makes sense. Thank you.