[core] Bring useId() to Base UI

[oliviertassinari]

Summary

The logic we have in here:

base-ui/packages/mui-base/src/utils/useId.ts

Line 4 in 890b49e

export { default as useId } from '@mui/utils/useId';

made sense in the context of moving Base UI out of http://github.com/mui/material-ui to its own repository quickly.

But it makes no sense in the long term. We want the dependency tree of @base-ui/react to be as lean as possible. It can't have @mui/ dependencies. So I believe it should work the other way around: be a helper that Base UI exposes for Material UI, MUI X, etc. https://npm.anvaka.com/#/view/2d/%2540base_ui%252Freact

Examples

No response

Motivation

This is a subset of https://www.notion.so/mui-org/engineering-mui-utils-purpose-9a9fc9da3a004864b6c4e1f4d1f24f95.

---

Also to be noted that this logic will stay duplicated in the bundle of users. It duplicate with: https://github.com/floating-ui/floating-ui/blob/2f5132ede1f02758bc5f8b96647e97deb546771c/packages/react/src/hooks/useId.ts#L39. If we really want to obsess over bundle size, I see two possible solutions:

1. Put the helper in a public @base-ui/utils helper package that Base UI could use. But this feels a bit odd:

graph TD;
    A["@base-ui/utils"]-->B["@floating-ui/react"];
    B-->C["@base-ui/react"];
    D["@floating-ui/core"]-->B;
    A-->E["@mui/x-data-grid"];

Loading

2. or have it into an internal package that we expose for other projects at MUI to use (if we don't want to make it public API). Rely on the core version of Floating UI, instead of the React one. This could be simpler, it would solve other modules duplications:

graph TD;
    A["@floating-ui/core"]-->C["@base-ui/react"];
    B["@base-ui/internals"]-->C;
    B-->D["@mui/x-data-grid"];

Loading

Search keywords: -

[yash49]

1. Put the helper in a public @base-ui/utils helper package that Base UI could use. But this feels a bit odd:

@oliviertassinari why option 1 feels odd to you?

[oliviertassinari]

@yash49 If sandwiches Floating UI with Base UI. I don't remember ever seeing this in the open source ecosystem, and I assume it's for go reasons: it becomes completely interdependant but with hard to sync release cycles.