Automatic ID generation does not work well with server rendering

[lemonmade]

Issue summary

In the latest edition of "mistakes Chris made several years ago", it's been bugging me that the approach to doing automatic ID generation in Polaris doesn't work properly for server rendering. I think all cases that need an ID generate one using createUniqueIDFactory. This creates auto-incrementing IDs (they aren't guaranteed globally unique, but they're fine for our purposes). However, they rely on module-global variables, which means that each request a node server gets will increment those IDs, even though the client will always start them back at 0. This creates a mismatch between client and server markup (not a huge deal, but an annoying warning in dev at the very least).

My proposal for addressing this would be to allow passing some sort of idFactory in to Polaris via context. This idFactory could default to being module global (e.g., const IdContext = createContext(idFactory())), which preserves the 0-config behaviour. However, for our apps, we could provide a fresh idFactory for each server render, allowing it to remain consistent with the eventual client markup.

Two things that would be nice to see out of it:

• Make it a shared package so we could use it in other React components
• Make sure it can be reset; our server rendering approach relies on rendering the whole app multiple times, so we need the ability to reset the counter between each pass.

[BPScott]

See also #1283

This issue has been inactive for 180 days and labeled with Icebox. It will be closed in 7 days if there is no further activity.

[BPScott]

This is still an issue.

[BPScott]

I've been low-key working towards a solution for this. Here's a state of the world update

History:

• Sometimes our usage of createUniqueIDFactory was faulty and it caused incrementing Ids for every render of a component instead of just on initial render
• functional components didn't have a good way of doing unique Ids that remained consistent across multiple renders of that component in the client, never mind keeping consistent between client and server initial renders

Mitigation so far:

• useUniqueId() is a hook created to ensure stable ids across rerenders on the client side. It supports specifying a custom id factory, however that is not exposed from the AppProvider.
• Most components that used createUniqueIDFactory have been converted to be functional components that use useUniqueId

The final fix for client/server mismatches will be contained within useUniqueId().

Next steps:

• Migrate components that use createUniqueIDFactory to be functional components that use useUniqueId. Ongoing effort for this is tracked in Post v4 cleanup work #1995
• Migrate Banner to be a functional component that uses useUniqueId (for some reason Banner has decided to go its own way and reimplement createUniqueIDFactory

Consider moving useUniqueId into @shopify/react-hooks

Update our ID handling by either:

• Allow the id generator that useUniqueId uses to be specified in the AppProvider so that it may be resettable
• Wait for a new version of react to ship with a stable version of useOpaqueIdentifier (see Add useOpaqueIdentifier Hook facebook/react#17322) that will automatically ensure consistent ids and update our useUniqueId to use that instead. The "provide a default and prefix" functionality will still be useful so keep them at least.

[Tom-Bonnike]

FYI you’ll be able to replace useUniqueId with an official react hook soon: reactjs/rfcs#32 (comment) Oh you mentioned that in the comment above. Nice.
I was bothered by the client/server mismatch for a while, I am refactoring the banner to a functional component using useUniqueId in #3199.

This issue has been inactive for 180 days and labeled with Icebox. It will be closed in 7 days if there is no further activity.