Add useOpaqueIdentifier Hook #17322
Add useOpaqueIdentifier Hook #17322
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 815042f:
|
Details of bundled changes.Comparing: 7785a52...815042f react-dom
react-test-renderer
react-art
react-native-renderer
react-debug-tools
react-reconciler
ReactDOM: size: 🔺+16.5%, gzip: 🔺+15.6% Size changes (experimental) |
Details of bundled changes.Comparing: 7785a52...815042f react-dom
react-debug-tools
react-native-renderer
react-art
react-test-renderer
react-reconciler
ReactDOM: size: 0.0%, gzip: -0.0% Size changes (stable) |
packages/react-dom/src/__tests__/ReactDOMServerIntegrationHooks-test.internal.js
Outdated
Show resolved
Hide resolved
| @@ -110,7 +110,7 @@ export function getValueForAttribute( | |||
| return expected === undefined ? undefined : null; | |||
| } | |||
| const value = node.getAttribute(name); | |||
| if (value === '' + (expected: any)) { | |||
| if (value === toString(expected)) { | |||
There was a problem hiding this comment.
if expected is the opaque object, this would throw the string error. toString doesn't convert the opaque object, which makes this just return value, which is what it should be anyway.
| @@ -18,7 +19,11 @@ export function setAttribute( | |||
| attributeName: string, | |||
| attributeValue: string | TrustedValue, | |||
| ) { | |||
| node.setAttribute(attributeName, (attributeValue: any)); | |||
| if (attributeValue.$$typeof === REACT_OPAQUE_OBJECT_TYPE) { | |||
There was a problem hiding this comment.
This works for updates, but need to handle similar case in setInitialDOMProperties, which is called during initial render.
There was a problem hiding this comment.
I think node.setAttribute is called during setInitialDOMProperties as well to set attributes:
setInitialDOMProperties -> setValueForProperty -> setAttribute/setAttributeNs
| } | ||
|
|
||
| container.innerHTML = | ||
| '<div data-reactroot=""><div id="s_0">Child One</div><!--$!--><div>Fallback</div><!--/$--></div>'; |
There was a problem hiding this comment.
You should also assert that React didn't replace the original DOM node. I would grab a reference to the divs here, then after you hydrate, make sure they match the hydrated ones (you can use a ref for that part, or grab them out of the container again). Then do the same after the update.
| Scheduler.unstable_flushAll(); | ||
| jest.runAllTimers(); | ||
|
|
||
| expect(container.innerHTML).toMatchInlineSnapshot( |
There was a problem hiding this comment.
The output is correct, but let's also test that there was only a single commit. You can do that with useEffect:
const id = useUniqueID();
useEffect(() => {
Scheduler.unstable_yieldValue('Did commit');
});I expect this test will fail; let's write the test first and then I can work with you on how to fix it.
| root.render(<App />); | ||
| }); | ||
|
|
||
| expect(container.innerHTML).toMatchInlineSnapshot( |
There was a problem hiding this comment.
if you do expect(container).toMatchInlineSnapshot pretty-format will format the inner html as html (newlines and less escaping, closer to how you'd write html manually).
If you explicitly want innerHTML, you can do expect(wrap(container.innerHTML)).toMatchInlineSnapshot to at least avoid the inline escaping and wrapping quotes. wrap comes from jest-snapshot-serializer-raw and is already used in react-refresh's tests
| `); | ||
| }); | ||
|
|
||
| it('generates unique ids for client render on good server markup', async () => { |
There was a problem hiding this comment.
The snapshot below contains the server ids. Is this testing for preservation of ids from the server?
There was a problem hiding this comment.
Yea. I agree. Snapshot tests aren't a good way of testing these things. Especially when there are so many of them. I'd drop all the snapshots and replace them with more specific assertions.
We don't provide any guarantees that this is actually the format we will use. In fact, these IDs are way too likely to conflict with a manual user provided ID. So we probably should change the format and we might have to change it again.
A change in the format will yield a lot of manual work to verify if it's correct or not.
The tests also don't actually test the important properties that are useful to preserve regardless of which format we use. I.e. that a client generated ID can't overlap with a server generated ID. Does any of your tests fail if you just change it to be react_ prefixed on both server and client? Or what if you accidentally make remove the auto-incrementing, does it fail any tests?
Instead of asserting against a snapshot, you could assert on the DOM that the IDs match. E.g. find the divs and spans and assert that node.getAttribute('aria-labelledby') matches node.id and that they don't match the other's IDs. Also, write a test where the client generated IDs are not suppose to match existing server generated
content. E.g. by on the client adding a client-rendered pair. That's all that really matter. Not the exact format.
| expect(Scheduler).toFlushAndYield([]); | ||
| jest.runAllTimers(); | ||
|
|
||
| expect(divNode).toEqual(ref.current); |
There was a problem hiding this comment.
Do we still need this assertion if we have the inline snapshot below?
| if (getIsHydrating()) { | ||
| return { | ||
| $$typeof: REACT_OPAQUE_OBJECT_TYPE, | ||
| _setId: () => { | ||
| setId(() => 'c_' + (clientId++).toString()); | ||
| }, | ||
| toString() { | ||
| throw Error( | ||
| 'The object passed back from useUniqueID is meant to be passed through to ' + | ||
| 'attributes only. Do not directly modify the output.', | ||
| ); | ||
| }, | ||
| }; | ||
| } else { | ||
| return 'c_' + (clientId++).toString(); | ||
| } |
There was a problem hiding this comment.
The body of this function looks identical to the mount function. Should we try to share it across mount and update?
There was a problem hiding this comment.
The update shouldn’t need to create the initializer (normally). Can we short cut this and avoid creating the unnecessary closure and array?
| return { | ||
| $$typeof: REACT_OPAQUE_OBJECT_TYPE, | ||
| _setId: () => { | ||
| setId(() => 'c_' + (clientId++).toString()); |
There was a problem hiding this comment.
This has the same problem as most of the "userspace" solutions: this ID is unstable and depends on commit order which, especially in combination with Suspense and partial hydration, is not necessarily the same as tree order.
One thing library authors often asked for is a way of getting the "tree position" of the element, which is better and relatively stable, but still not perfect; it'll probably work better for hydration and will be globally unique, but might get reused if a component is swapped by another for example.
There was a problem hiding this comment.
I think with this solution it doesn't matter whether the counter changes between server and client since react is able to patch it up properly during hydration which wasn't possible before.
This hook is exclusively for IDREF attributes. It's not a generic, unique ID of your component instance.
There was a problem hiding this comment.
Ah, so the point is it not being seen as a hydration error but just as something to be patched 🤔
There was a problem hiding this comment.
At least this is how I understood it. There's an argument to be made about hydration warnings for attributes in the first place (e.g. <button disabled={!process.browser} /> but IDREFs seem like a safe place to start.
There was a problem hiding this comment.
It’s not as simple as just patching. Partially because we don’t actually compare any props in hydration. But mostly because if you do it the naive way you may patch up one side but not the other side when partial hydration is being used.
This impl enforces that we force hydration of the things that needs patching on both sides.
We should have a test for that.
|
How about It’s not necessarily an ID in its implementation. It’s just some way of referencing one node in two places. The connection to I’ve thought about having this in React Native as a way to pass a native box around. So that I can pass a reference to a native View instance to native APIs. Eg getting a handle to a native View instance from another view’s View Manager on Native threads. Unlike useRef, this kind of ref’s current value would only be accessible from native code. That’s very similar to how you can think about this use case too. It’s a bit strange since you might expect to pass the target side like |
| toString() { | ||
| throw Error( | ||
| 'The object passed back from useUniqueID is meant to be passed through to ' + | ||
| 'attributes only. Do not directly modify the output.', |
There was a problem hiding this comment.
What does “don’t modify the output” mean? I’m just reading the value. Not modifying it.
There was a problem hiding this comment.
This should be an invariant since our error minification pipeline doesn't support error constructors, yet.
| ) { | ||
| node.setAttribute(attributeName, (attributeValue: any)); | ||
| if ( | ||
| typeof attributeValue === 'object' && |
There was a problem hiding this comment.
This is probably React’s hottest path that we’re making slower (and not inlinable). Is this the best place we can do this? Where does TrustedValue do its check?
| @@ -260,6 +264,17 @@ function useDeferredValue<T>(value: T, config: TimeoutConfig | null | void): T { | |||
| return value; | |||
| } | |||
|
|
|||
| function useOpaqueReference(): string | IdObject { | |||
| const hook = nextHook(); | |||
| const value = hook === null ? 'FAKE_ID' : hook.memoizedState; | |||
There was a problem hiding this comment.
The name "FAKE_ID" doesn't say much and is kind of confusing if you do end up seeing it. What's Fake about it? Can I search for it? It also doesn't apply as a string when in React Native for example. Let's just leave it as undefined if it's not there.
I believe this can also cause an error if you inspect a hydrated component since toString and valueOf will throw. We should probably detect if it's a REACT_OPAQUE_OBJECT_TYPE and do something special. Perhaps just leaving it as undefined as well.
You can add tests to: https://github.com/facebook/react/tree/9fe1031244903e442de179821f1d383a9f2a59f2/packages/react-debug-tools/src/__tests__
| const container = document.createElement('div'); | ||
|
|
||
| container.innerHTML = | ||
| '<div data-reactroot=""><div id="s_0">Child One</div><!--$!--><div>Fallback</div><!--/$--></div>'; |
There was a problem hiding this comment.
I'd use ReactDOMServer.renderToString(...) to render this string so that you don't have to hard code the format.
Example:
| @@ -60,7 +86,8 @@ if (enableTrustedTypesIntegration && typeof trustedTypes !== 'undefined') { | |||
| trustedTypes.isScript(value) || | |||
| trustedTypes.isScriptURL(value) || | |||
| /* TrustedURLs are deprecated and will be removed soon: https://github.com/WICG/trusted-types/pull/204 */ | |||
| (trustedTypes.isURL && trustedTypes.isURL(value))) | |||
| (trustedTypes.isURL && trustedTypes.isURL(value)) || | |||
| value.$$typeof === REACT_OPAQUE_OBJECT_TYPE) | |||
There was a problem hiding this comment.
This doesn't seem right. This will be toString:ed by the DOM and throw an error anyway. No need to add a special case, is there? Just let it fail below.
| value !== null && | ||
| typeof value === 'object' && | ||
| value.$$typeof === REACT_OPAQUE_OBJECT_TYPE && | ||
| typeof value._setId === 'function' |
There was a problem hiding this comment.
You shouldn't need this extra check. You've asserted the type. Just cast it through let obj: IdObject = (value: any) below to satisfy Flow.
| value._setId(); | ||
| return ''; | ||
| } else { | ||
| return toStringOrTrustedType(value); |
There was a problem hiding this comment.
The point to collocate these was so that you could use the same type check to quickly determine if this is not an object which is the common case. However, by calling this second function, you have to check the type again in the other function. Leading to two checks instead of one, for the common case.
You should inline this here so that you can avoid extra type checks. However, the bigger question is why you need two functions at all.
| @@ -44,14 +45,39 @@ export opaque type TrustedValue: {toString(): string, valueOf(): string} = { | |||
| valueOf(): string, | |||
| }; | |||
|
|
|||
| export function evaluateToStringOrTrustedType( | |||
There was a problem hiding this comment.
Does this need to be its own function? Can't it just be the same as toStringOrTrustedType?
toStringOrTrustedType is called in two other places.
This one seems like you might have missed: https://github.com/facebook/react/pull/17322/files#diff-214d5116dd8b5a7d184cdf5b2160f94cR183
Seems like it should also trigger this path.
The other one is here but I think that's actually already the wrong place to do this and it shouldn't toString this at all since the initial rendering doesn't:
But it doesn't hurt that we check for
REACT_OPAQUE_OBJECT_TYPE. Even though the existing call is a bug in the first place.
That way we need less code overall.
| @@ -110,7 +114,7 @@ export function getValueForAttribute( | |||
| return expected === undefined ? undefined : null; | |||
| } | |||
| const value = node.getAttribute(name); | |||
| if (value === '' + (expected: any)) { | |||
| if (value === toStringOrTrustedType(getToStringValue(expected))) { | |||
There was a problem hiding this comment.
This call site seems like it breaks with trusted types already.
But this fix doesn't seem right. Why call getToStringValue? Why would you need to ignore function values or symbol? getAttribute should never return those types.
toStringOrTrustedType also doesn't seem like the right fix neither.
For trusted types, the server generated string won't match the object on the client, so this wouldn't end up matching. Causing a hydration error. This will need to dig into the trusted type and inspect the value to see if it's equivalent.
For REACT_OPAQUE_OBJECT_TYPE the returned object will never match. So that will also be a hydration error.
It seems to me that this needs to just perform some more custom matching logic instead of trying to use the toStringOrTrustedType helper.
| @@ -197,6 +198,9 @@ if (__DEV__) { | |||
| if (didWarnInvalidHydration) { | |||
| return; | |||
| } | |||
| if (clientValue && clientValue.$$typeof === REACT_OPAQUE_OBJECT_TYPE) { | |||
There was a problem hiding this comment.
This seems like the wrong place to do this check. If we get here it's because we already thought that there was an error. If you do the check in getValueForAttribute instead, then we don't have to treat it as an error in the first place.
| const [id, setId] = mountState(() => { | ||
| if (getIsHydrating()) { | ||
| return { | ||
| $$typeof: REACT_OPAQUE_OBJECT_TYPE, |
There was a problem hiding this comment.
Other than its creation, this object is only ever referenced in ReactDOM. That's a good thing because on other platforms like the React Native use case, this object will look very different and have a very different signature.
To do that, though, we need to make the creation of this object something platform specific. Let's make a HostConfig method to create this object and only implement it in ReactDOM.
For React Native, we should make that method throw since this feature is not yet supported there. Later we could add some specific implementation.
You probably need to pass setId in as an argument to the HostConfig method.
| }, | ||
| }; | ||
| } else { | ||
| return 'c_' + (clientId++).toString(); |
There was a problem hiding this comment.
This should also move to ReactDOM since it's specific to how an "Opaque Reference" is constructed in the DOM.
Also, don't call toString(). Rely on + '' casting instead like we do elsewhere. .toString() becomes a dynamic look up which can be monkey patched by Number.prototype. It's more bytes and less efficient.
Actually, scratch that, let's use toString(36) instead to save some bytes in memory on the ID. On the client it doesn't matter as much but nice on the server so might as well use it for consistency.
| </div> | ||
| </div> | ||
| `); | ||
| }); |
There was a problem hiding this comment.
We should add a similar test where Child One is in a Suspense boundary that is still suspended. I.e. if we're only partially hydrated. Then we do an update that shows the second Child. This should suspend and wait for the suspense boundary to resolve before letting the update through.
It should not leave them inconsistent.
That test would ensure that we don't forget about this case and try to implement the "patching strategy approach" in the future. That test is really the main driver for this particular implementation strategy so we should ensure we test for it.
https://github.com/facebook/react/pull/17322/files#r354445736
We currently use unique IDs in a lot of places. Examples are:
*
<label for="ID">*
aria-labelledbyThis can cause some issues:
1. If we server side render and then hydrate, this could cause an hydration ID mismatch
2. If we server side render one part of the page and client side render another part of the page, the ID for one part could be different than the ID for another part even though they are supposed to be the same
3. If we conditionally render something with an ID , this might also cause an ID mismatch because the ID will be different on other parts of the page
This PR creates a new hook
useOpaqueIdentifierthat generates a different unique ID based on whether the hook was called on the server or client. If the hook is called during hydration, it generates an opaque object that will rerender the hook so that the IDs match.