Button: Decoupling ContextualMenu to improve bundlesize

[khmakoto]

Pull request checklist

• Addresses an existing issue: Refactor: Button #6134
• Include a change request file using $ npm run change

Description of changes

This PR takes a stab at decoupling ContextualMenu from the new Button rewrite in the experiments package in an effort to improve bundle size. The way that this is being done is by introducing a new ButtonMenu that has a subset of the props in ContextualMenu, consisting of:

• target
• onDismiss
• items
• directionalHint

A fifth prop not existing in ContextualMenu, menuType, is also added to indicate what type of component the menu is going to be rendered as. The examples have also been updated to work with this change.

The bundle size change for the components is illustrated below:

Before decoupling (Stat: 533.43KB, Parsed: 160.75KB, Gzipped: 45.13KB):

After decoupling (Stat: 250.59KB, Parsed: 69.71KB, Gzipped: 20.45KB):

Difference in Size Auditor Dashboard: (Props to @aftab-hassan for sending this exactly when I needed it 👍 )

Focus areas to test

(optional)

Microsoft Reviewers: Open in CodeFlow

[size-auditor]

Size Auditor did not detect a change in bundle size for any component!

[JasonGore]

Is this intended to be a legitimate viable default menu option? Are there any examples that use it? (It seem all the examples were converted to use ContextualMenu.)

[JasonGore]

Do we need to duplicate props in IContextualMenuProps? We should be able to depend on types without affecting bundle size.

[JasonGore]

I'm concerned about how much of this is "filler" just to avoid using ContextualMenu. I'd like to talk through some other options of what you were considering and what I was envisioning to see if there are any other alternatives. I was really hoping we could use some kind of slot helpers without creating standalone variants for every function, like menuing.

[khmakoto]

Per discussions offline we have chosen to do this via a different approach, which is done in PR #8291.