[core] Use re exported utils from packages in docs examples

[LukasTy]

This is a follow-up to: #13823 (comment)

• Add <package>/utils export with utilities, that are used within documentation examples
  • Add paid package re-exporting of such utility from base package (Charts, Pickers)
  • What to do with DataGrid? It already has utils export and it is also re-exported on root. 🙈
• Use new re-exports in the documentation examples in turn "hiding" the @mui/utils usage from end users

[mui-bot]

Deploy preview: https://deploy-preview-13901--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 5079f86

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[flaviendelangle]

This PR is several month old, is not a draft but has no review requested
What is its current state?

[mnajdova]

The general direction of the PR makes sense to me, but I wouldn't want to be the reviewer, as I am not fully aware of the scope and usage of these utils in all X products :)

[flaviendelangle]

The logic seems nice to me
I just wonder what it should look like once we have Base UI X (and stuff like useId is in the Base UI utils package)

Do we export from Base UI X packages AND MUI X packages ?
Do we only export from the Base UI X packages ?
If the Base UI utils package is public, do we say to people to use it directly ?

Just to avoid doing something we would undo in a few months

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[LukasTy]

The logic seems nice to me I just wonder what it should look like once we have Base UI X (and stuff like useId is in the Base UI utils package)

Do we export from Base UI X packages AND MUI X packages ? Do we only export from the Base UI X packages ? If the Base UI utils package is public, do we say to people to use it directly ?

Does the relation still matter if we know that the docs are going to be different and the package will be probably standalone as well? 🤔
I think that we would solve this question when such a problem is present. 👌
Personally, I don't see a big problem in showcasing the @mui/utils usage and having it public.
But it has a drawback as it would require the @mui/utils dependency to be present in most cases on user setups. 🙈

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[michelengelen]

@LukasTy is this still something we want to pursue?

[LukasTy]

@LukasTy is this still something we want to pursue?

That's up to the team and Olivier to decide.
It was the result of exploring a way to "hide" @mui/utils usage. 🤷

[flaviendelangle]

From what I understand, most (all?) of those utils will move to the base ui utils package.
If this new package is public, then IMHO this PR should be closed
If this new package is internal, then we still have the same topic

[LukasTy]

Closing it as it looks like there is no consensus in this regard yet. 🙈
I can return to this PR if we reach a decision. 👌