Fluentui: office-ui-fabric-react package breakup

[jdhuntington]

In an effort to ensure maintenance and development in
office-ui-fabric-react continues to be sustainable, we are proposing
the task of breaking out controls into smaller packages within this
repo. These packages will be consumed and re-exported by
office-ui-fabric-react as to not change the API surface of
office-ui-fabric-react itself.

Doing this work has several benefits:

• Allow packages to be deveoped in standalone packages without
  introducing circular dependencies when releasing.
• Allow packages to release versions at different cadences. Targeted
  hotfixes can be picked up by groups at their own need while other
  packages are free to iterate at their own pace.
• Gives us options of moving chunks of code to separate repositories
  more easily in the future.
• Creates framework for allowing larger ecosystem of high value-add
  controls.

The specific packages will contain the following controls:

| @uifabric/$PACKAGE | controls |
|--------------------|----------|
| react-fundamentals | ActivityItem, DocumentCard, HoverCard, Breadcrumb, CommandBar, Nav, OverflowSet, Pivot, ResizeGroup, ContextualMenu, Announced, Color, Divider, Grid, Icon, Icons, Image, Keytip, KeytipData, KeytipLayer, Link, Separator, Stack, Text, Callout, Dialog, Layer, Modal, Overlay, Panel, Popup, ScrollablePane, Sticky, Tooltip, FocusTrapZone, FocusZone, Autofill, Button, Checkbox, ChoiceGroup, ChoiceGroupOption, ComboBox, Dropdown, Label, Rating, SearchBox, SelectableOption, Slider, SpinButton, TextField, Toggle, Coachmark, MessageBar, PositioningContainer, ProgressIndicator, Shimmer, Spinner, TeachingBubble |
| react-data-views | Check, DetailsList, GroupedList, List, MarqueeSelection, SelectedItemsList, ShimmeredDetailsList |
| react-date-time | Calendar, DatePicker |
| react-people | Facepile, Persona, PersonaCoin, PersonaPresence |
| react-pickers | ColorPicker, ExtendedPicker, FloatingPicker, Pickers, SwatchColorPicker |

Work will be staged 1 package at a time, moving necessary controls from office-ui-fabric-react then publishing a minor release. This will ensure that pull requests are reviewable and releasable at regular intervals.

Please add comments!

[KevinTCoughlin]

@jdhuntington should we rename the recently created @uifabric/lists package in #9106 as you have it above, @uifabric/react-list?

Luckily, we have deferred publishing and are free to perform a rename without penalty. Though I personally think it should be plural since it will contain a number of list components and helpers.

[KevinTCoughlin]

@jdhuntington will we be tracking build time as part of the success criteria of this modularization effort?

My hope would be that the modularization work results in a quicker inner dev loop or at the very least does not regress.

[jdhuntington]

@KevinTCoughlin Good question. I think that "not making the build slower" is an important goal, though I don't expect it to improve either. The main success criteria is to break circular dependency chains and enable more flexible versioning/release schemes in the future.

[acoates-ms]

The react-commanding package sounds like it has various heavy components, that people might want to avoid... and ContextualMenu which I assume even pretty light apps will need. Maybe the code is more related than I might thing, but should ContextualMenu be more separate?

Also Nav is often big enough to be its own thing. -- (I'm not that familiar with the actual fabric controls... just some gut thinking thoughts)

[soettl]

@KevinTCoughlin I wonder whether it could make sense to use a more generic name for react-lists, like react-collections. Would allow us to add components in the future that don't use a row-based layout strategy.

[Vitalius1]

Here are my 5 centomments 😄

1. Tooltip should probably be classified as a surface.
2. Some controls are just utilities and could have their own package: OverflowSet, ResizeGroup, Keytips and some list utils maybe like Selection, AutoScroll.
3. ContextualMenu could easily be classified as a surface too.
4. If taking out OverflowSet, ResizeGroup and ContextualMenu from react-commanding it can be easily named as react-navigation. The only odd player here is CommandBar...
5. What happened with a discussed react-layout which would have within itself Stack and in the future Grid?

[JasonGore]

My comments:

1. I'm curious if component size should really be a determining factor for splitting packages. Is tree shaking something not available in React Native solutions? If it is a factor, it's going to have knock off effects on Fabric package hierarchies, as well. (No sense in splitting out ContextualMenu if most of the other packages use it, for example.)
2. Omit is just a type helper that is replaced with Omit in TS3.5, although it's probably a bit too soon to deprecate it entirely. Maybe a react-helpers or react-types package?
3. I'm not sure where Keytips would fit, maybe surfaces? It is used by a number of components. Maybe @kelseyyoung has some input.
4. GlobalSettings is part of packages\utilities.. are those also being split? Would also affect Customizations, Customizer, etc.

[kelseyyoung]

I'm up for any categorization of keytips really; out of the ones listed in the original table I think it mostly fits in react-commanding because it gives a way to trigger executable controls through keyboarding; the Keytip component itself is just a visual way to show that. However, as Jason mentioned, because it's used by many components perhaps it does need its own package

[jdhuntington]

Putting this on hold, as it would mean several major changes across consuming codebases.

[dzearing]

We will likely be picking this up again soon.