Early Proof of Concept: Menu with BaseUI

[ZakaryH]

Motivations

Changes

Added

Changed

Deprecated

Removed

Fixed

Security

Testing

Changes can be
tested via Pre-release

---

In Atlantis we use Github's built in pull request reviews.

[github-actions]

⚠️ Pull Request titles in this repo follow the Conventional Commits specification.

No release type found in pull request title "Early Proof of Concept: Menu with BaseUI". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit

[ZakaryH]

using an opt-out approach maximizes consistency, and UX on mobile while still offering the ability to diverge when needed.

when someone sets responsive={false} we know they thought about the mobile scenario and didn't want it for whatever reason. this is as strong of a signal as we can possibly get.

whereas with an opt in approach, not only does it create more work since that's not how Menu worked historically - but it also leaves room for ambiguity. did someone not want it because they really didn't like it? or did they not know about this case?

if they didn't know about it, then that's the best possible outcome of an included default. you didn't think about it, and you don't have to. your user will have a good, consistent experience on mobile.

[ZakaryH]

it may seem that this is structure, but I would argue it is not. this is behavior, and it includes logic. in the same way that a Modal has a dismiss Button, but you wouldn't use the mere presence of a Modal.Dismiss to control that because there is more to it than that. you are making a decision about the behavior of the overall component that is more than markup in isolation.

as such, adding a Menu.Drawer is not optimal.

abstracting with a Menu.Content is the right boundary and responsibility for Menu at the components level.

as a consumer, you don't need to be concerned with the precise mechanism Drawer vs Popover. you just need to think about the items, and their content (icons etc.). we give you those tools and take care of the rest.

using sub components to dictate behavior or configuration is not a good fit for that problem, and additionally adds to the already sizeable amount of sub components in the Menu name space.

[cloudflare-workers-and-pages]

Deploying atlantis with    Cloudflare Pages

Latest commit:	d6bd76f
Status:	✅  Deploy successful!
Preview URL:	https://b408bb3a.atlantis.pages.dev
Branch Preview URL:	https://cleanup-menu-but-with-baseui.atlantis.pages.dev

View logs