fix: useIdWithFallback for react 17 and lower

[jorgeepc]

This PR fixes a compile error in projects using React 17. The change introduced in #113 implements unique IDs for components assuming that the useId react hook will be available. The proposed fix changes the import format to exclude the useId import from the build.

Related Issue or Design Document

See conversation in #120

Sample dependencies to reproduce the issue:

"dependencies": {
    "@ory/elements": "0.0.1-beta.7",
    "loader-utils": "3.2.1",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-scripts": "5.0.1"
  },
  "devDependencies": {
    "@types/react": "17.0.2",
    "@types/react-dom": "17.0.2",
    "typescript": "5.0.2"
  },

Checklist

• [x] I have read the contributing guidelines and signed the CLA.
• [ ] I have referenced an issue containing the design document if my change introduces a new feature.
• [x] I have read the security policy.
• [x] I confirm that this pull request does not address a security vulnerability. If this pull request addresses a security vulnerability, I confirm that I got green light (please contact security@ory.sh) from the maintainers to push the changes.
• [ ] I have added tests that prove my fix is effective or that my feature works.
• [ ] I have added necessary documentation within the code base (if appropriate).

Further comments

[Benehiko]

I don't think we should implement webpack workarounds when the problem is useId is only supported in React 18. I think we should try find an alternative to this hook and remove it entirely. This ensures we have support for React < 18.

Others also have the same issue as we do: https://github.com/roginfarrer/collapsed/issues/117

[aeneasr]

If this works with R17 and R18 we should merge it, and remove it once webpack or React fix the issue upstream.

If it doesn't work, replace useId with a random string generator (potentially using setState), which has the same effect.

[LBBO]

What about outsourcing the dirty work? @over-ui/use-id also uses a webpack workaround (https://github.com/over-ui/unstyled/blob/main/packages/useId/src/useId.ts; the .toString() serves the same purpose as my workaround and is much nicer IMO) with a similar fallback to ours. Or should we rather keep it under our control so we can decide when to change back?

[LBBO]

After a brief chat with @aeneasr, we agreed to just keep it in our code. I switched to the other workaround anyways since it has better runtime. This version has been tested without npm link (I manually copied the build output into node_modules) in React 17 & 18 projects and work as expected.

[jorgeepc]

Hey @LBBO thank you for the priority with this. I tested the new release 0.0.1-beta.9 and it's working as expected. 🙌