Open oliviertassinari opened 1 month ago
- 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?
@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.
Summary
The logic we have in here:
https://github.com/mui/base-ui/blob/890b49ec51cfd966e61d8da1156ad14e50d32385/packages/mui-base/src/utils/useId.ts#L4
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:
Search keywords: -