[RFC] Code organization in @mui/base

[michaldudak]

🖼 Background

As we are in an early stage of @mui/base development, it's worth establishing code organization rules to follow when creating new components. We could simply adopt the rules from @mui/material and other existing packages, however, a new package gives us an opportunity to take another look at it and see if we can introduce any improvements.

💡 Proposal

1. Separate hooks from unstyled components and place them in their own top-level directories:

   mui-base/
     src/
       ButtonUnstyled/
       useButton/
       ...
   

   This would have the following advantages:

   • better separation of hooks and components
   • each top-level building block would be imported from a directory matching its name

2. Adopt the following file structure in components/hooks directories:

   Component/
     Component.tsx
     Component.spec.tsx
     Component.test.tsx
     Component.types.ts
     componentClasses.ts
     index.ts
     ... (other if necessary)
   

   useHook/
     useHook.ts
     useHook.test.tsx
     useHook.types.ts
     ... (other if necessary)
   

   The primary change is renaming the *Props.ts files into *.types.ts.
   During the development of existing unstyled components, it became clear it's necessary to export much more than just props.
   ButtonUnstyled, MenuUnstyled, and SelectUnstyled already follow this pattern.

3. Use named exports instead of default ones. This has been discussed in [RFC] Avoid or "prefer not to use" default exports  #21862 already.
   For component authors, it would eliminate the need to switch between default and named exports when re-exporting from index files. It would also make it easier for developers to switch from top-level (import { ButtonUnstyled } from '@mui/base') to deep imports (import { ButtonUnstyled } from '@mui/base/ButtonUnstyled').

4. Do not use the Unstable_ prefix for components hooks, as the whole library is unstable right now (this is the case with Unstable_TrapFocus.

---

cc @mui/core

[siriwatknp]

1. Separate hooks from unstyled components and place them in their own top-level directories:

Love it 👍. This will make the imports like this right?

import useButton from '@mui/base/useButton';
import useAutocomplete from '@mui/base/useAutocomplete';

Component.types.ts

Yes, looks a lot better than ComponentProps.ts. Joy components are exporting SlotKey which is not props, it makes more sense to be Component.types.ts.

Use named exports instead of default ones

I don't think it is worth going that far. In this case, it is not like "A" is better than "B" so I would keep the existing way of import and focus on other improvements instead.

Do not use the Unstable_ prefix for components hooks, as the whole library is unstable right now (this is the case with Unstable_TrapFocus.

Sounds good.

[mnajdova]

Agree with @siriwatknp's comments. For the Unstable_TrapFocus it was like that exported from the @mui/material package, we need to re-export it by that name, but sure it can be simply TrapFocus in the @mui/base package.

[michaldudak]

I'm closing this one - I feel we reached an agreement.

For point 1 I created an issue: #33903.

Points 2 and 4 have already been done.

Point 3 is dropped.

[oliviertassinari]

So if I understand correctly, the problem we are trying to solve in the RFC is to recognize that hooks should be a first-class citizen. Material UI and Joy UI will likely be built on top of the hooks directly, mostly to improve the DX with the React dev tools and marginally improve the runtime with fewer layers of React components at the expense of allowing inconsistency mistakes between Joy UI and Material UI (which would be reported and fix thanks to the community).

Point 3 is dropped.

Great, one step at a time 😁.

[michaldudak]

Material UI and Joy UI will likely be built on top of the hooks directly, mostly to improve the DX with the React dev tools and marginally improve the runtime with fewer layers of React components

Also, hooks make it easier to create components that are customizable further (i.e., expose the componentsProps prop)