Root.Item pattern export

[receter]

For some components we have this pattern:

<OverflowMenu>
  <OverflowMenu.Item>I am an item</OverflowMenu.Item>
</OverflowMenu>

Items that "belong" to a parent component like in this example the Item are attached to the parent component and can be used with "Parent.Item".

Currently all this is defined and exported inside the folder of the "parent" like lib/components/OverflowMenu:

…
export const OverflowMenu = Object.assign(OverflowMenuRoot, {
  Item: OverflowMenu_Item,
});

Because the item is defined inside the components/OverflowMenu folder and it would be possible to create a new folder/component with the same name (components/OverflowMenuItem) creating a name conflict with the global hooks, we decided to use the underline naming convention for the needed global hooks, like: useOverflowMenu_Item and useOverflowMenuItem can coexist.

I do not really like the underline naming.

One Idea I had is to instead not define the item inside components/OverflowMenu and make the hierarchy more flat by moving the Item outside to components/OverflowMenuItem.

Then connect them just before exporting, for example in lib/main.ts:

…
import { OverflowMenu as OverflowMenuRoot } from "./OverflowMenu";
import { OverflowMenuItem } from "./OverflowMenuItem";
export const OverflowMenu = Object.assign(OverflowMenuRoot, {
  Item: OverflowMenuItem,
});

But also this still has a downside: If the consumer does not use all composition elements, like for example only <OverflowMenu> is used but <OverflowMenu.Item> is not, the code of <OverflowMenu.Item> would still land in the final bundle as it is attached to OverflowMenu.

The only solution to this would be to stop using this pattern and instead simply go with:

<OverflowMenu>
  <OverflowMenuItem>I am an item</OverflowMenuItem>
</OverflowMenu>

I don't see any real disadvantage here as also autocomplete would help to find which composition components are in the namespace by typing <OverflowMenu, right?

[wattsjay]

I agree with the last solution. It must mean something also that the bigger component libraries I think mostly use that pattern. That also all said, semantically, if an OverflowMenuItem exists, I think it should be as close as possible to where it will be used, ie OverflowMenu folder. If a generic OverflowMenuItem has to also exist, I would name it something more generic like ListBoxItem or something (not sure what exactly), and then if required, OverflowMenu can import and extend it. To me this is a bit of a higher-order problem.

I would not really consider the export combination option, as I think it breaks a bit of the encapsulation. Index files should be very dumb imo

[receter]

I would not really consider the export combination option, as I think it breaks a bit of the encapsulation. Index files should be very dumb imo

Yes, I agree.

if an OverflowMenuItem exists, I think it should be as close as possible to where it will be used, ie OverflowMenu folder.

I get this and I do agree that it has many positives.

This is also what nextui for example does, here is the index file for the Dropdown for example:

…
import {MenuItem, MenuSection} from "@nextui-org/menu";

import Dropdown from "./dropdown";
import DropdownTrigger from "./dropdown-trigger";
import DropdownMenu from "./dropdown-menu";
…
export {
  Dropdown,
  DropdownTrigger,
  DropdownMenu,
  MenuItem as DropdownItem,
  MenuSection as DropdownSection,
};

(What I don't really get here is why DropdownItem is MenuItem from @nextui-org/menu. And when you go to https://www.npmjs.com/package/@nextui-org/menu and click on documentation you will see a 404.)

---

Still I see benefits of a flat simple folder structure (and I really like simple)

In the end, what is exported, is a flat list of components.

My thought is that it would be very easy to understand that every exported component is one folder inside the components folder.

Every time you create a new component you will just add a new folder, with files similar to all other folders. No matter if it is meant to be used exclusively as a child in another component or not.

For both, the user and the developer, the information that a component is meant to be used as a child will be carried in the name of the component.

If sorted alphabetically it is also quickly visible which components belong together:

OverflowMenu
OverflowMenuGroup
OverflowMenuItem
OverflowMenuItemIcon

I would like to start with this and find out whether it has any relevant disadvantages and then think about grouping it. Going from flat to grouped should be easier than going from grouped to flat.

[receter]

Addendum: there isn't even a components folder yet.