Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Bring useId() to Base UI #616

Closed
oliviertassinari opened this issue Sep 14, 2024 · 3 comments · Fixed by #827
Closed

[core] Bring useId() to Base UI #616

oliviertassinari opened this issue Sep 14, 2024 · 3 comments · Fixed by #827
Assignees
Labels
core Infrastructure work going on behind the scenes

Comments

@oliviertassinari
Copy link
Member

oliviertassinari commented Sep 14, 2024

Summary

The logic we have in here:

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

SCR-20240917-nrkt

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
  1. 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: -

@oliviertassinari oliviertassinari added status: waiting for maintainer These issues haven't been looked at yet by a maintainer core Infrastructure work going on behind the scenes labels Sep 14, 2024
@yash49
Copy link

yash49 commented Sep 17, 2024

  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
Copy link
Member Author

oliviertassinari commented Sep 17, 2024

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 good reasons: it becomes completely interdependant but with hard to sync release cycles.

Copy link

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

@github-actions github-actions bot removed the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Infrastructure work going on behind the scenes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants