feat: Create v9 version of chart controls

[AtishayMsft]

Previous Behavior

New Behavior

Creating chart controls native for fluent v9. These controls are a direct port from v8 with exact match for design and functionality. Currently these controls are in compatibility mode. Constructs for slots will be added in future versions.

This PR includes 6 components - Line Chart, Horizontal Bar Chart, Vertical Bar Chart, Donut Chart, Legends and Sparkline.

The controls can be seen in the docsite here. https://fluentuipr.z22.web.core.windows.net/pull/32966/public-docsite-v9/storybook/index.html?path=/docs/compat-components-charts-donutchart--docs

Related Issue(s)

• Fixes #

[fabricteam]

📊 Bundle size report

✅ No changes found

[fabricteam]

Perf Analysis (@fluentui/react)

No significant results to display.

All results

Scenario	Render type	Master Ticks	PR Ticks	Iterations	Status
BaseButton	mount	630	666	5000
Breadcrumb	mount	1682	1706	1000
Checkbox	mount	1774	1779	5000
CheckboxBase	mount	1491	1550	5000
ChoiceGroup	mount	2980	2972	5000
ComboBox	mount	695	730	1000
CommandBar	mount	6861	6720	1000
ContextualMenu	mount	14144	12543	1000
DefaultButton	mount	799	822	5000
DetailsRow	mount	2382	2214	5000
DetailsRowFast	mount	2238	2331	5000
DetailsRowNoStyles	mount	2031	2057	5000
Dialog	mount	2864	2912	1000
DocumentCardTitle	mount	235	235	1000
Dropdown	mount	2033	2016	5000
FocusTrapZone	mount	1177	1188	5000
FocusZone	mount	1112	1091	5000
GroupedList	mount	43555	44111	2
GroupedList	virtual-rerender	20882	20782	2
GroupedList	virtual-rerender-with-unmount	60594	55216	2
GroupedListV2	mount	238	236	2
GroupedListV2	virtual-rerender	223	229	2
GroupedListV2	virtual-rerender-with-unmount	243	236	2
IconButton	mount	1148	1156	5000
Label	mount	342	346	5000
Layer	mount	2823	2743	5000
Link	mount	396	414	5000
MenuButton	mount	1060	971	5000
MessageBar	mount	21445	22129	5000
Nav	mount	2055	2060	1000
OverflowSet	mount	822	792	5000
Panel	mount	1841	1950	1000
Persona	mount	733	748	1000
Pivot	mount	930	918	1000
PrimaryButton	mount	985	922	5000
Rating	mount	4796	4936	5000
SearchBox	mount	1011	943	5000
Shimmer	mount	2008	1977	5000
Slider	mount	1364	1459	5000
SpinButton	mount	3119	3021	5000
Spinner	mount	409	416	5000
SplitButton	mount	1896	1840	5000
Stack	mount	417	421	5000
StackWithIntrinsicChildren	mount	892	948	5000
StackWithTextChildren	mount	2849	3062	5000
SwatchColorPicker	mount	6460	6435	5000
TagPicker	mount	1495	1620	5000
Text	mount	390	402	5000
TextField	mount	978	943	5000
ThemeProvider	mount	858	856	5000
ThemeProvider	virtual-rerender	597	582	5000
ThemeProvider	virtual-rerender-with-unmount	1303	1291	5000
Toggle	mount	638	612	5000
buttonNative	mount	192	193	5000

[AtishayMsft]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 4 pipeline(s).

[AtishayMsft]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 4 pipeline(s).

[AtishayMsft]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 4 pipeline(s).

[AtishayMsft]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 4 pipeline(s).

[JustSlone]

Awesome PR @AtishayMsft, thanks for getting this work going!

@GeoffCoxMSFT can you take a look at this as the expert on v8 to v9 migration @sopranopillow can you take a look at this as the expert on compat components

[AtishayMsft]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 4 pipeline(s).

[JustSlone]

Im not sure we wanna have charting part of our v9 patterns etc as it is "out of core team control". The better approach here would be to live in your domain/structure similarily to web-components.

This should be brought up to core team at tech sync to discuss further. ty

Is the idea here that we would move this to packages/react-charting instead of packages/react-components/react-charting. I like this since overall the intention of packages/react-components is to house the packages that ship in the v9 suite package, which we would not want to include charting in (as it would want to maintain the flexibility to make possible breaking changes).

@Hotell what would be involved in moving this to packages/react-charting and keeping the same build capabilities that we have under packages/react-components? i.e. what's the cost, any issues with publishing to storybook or losing access to testing? also what are the benefits (possible independent pipelines?).

We can take this offline with @AtishayMsft and me if the conversation is more involved.

[AtishayMsft]

Im not sure we wanna have charting part of our v9 patterns etc as it is "out of core team control". The better approach here would be to live in your domain/structure similarily to web-components. This should be brought up to core team at tech sync to discuss further. ty

Is the idea here that we would move this to packages/react-charting instead of packages/react-components/react-charting. I like this since overall the intention of packages/react-components is to house the packages that ship in the v9 suite package, which we would not want to include charting in (as it would want to maintain the flexibility to make possible breaking changes).

@Hotell what would be involved in moving this to packages/react-charting and keeping the same build capabilities that we have under packages/react-components? i.e. what's the cost, any issues with publishing to storybook or losing access to testing? also what are the benefits (possible independent pipelines?).

We can take this offline with @AtishayMsft and me if the conversation is more involved.

Thanks for initiating this discussion. Our primary requirements are to get the platform support like vr tests, docsite, perf monitoring, api extraction and release management. Ideally we would prefer react-charting to be the nodal point to host our v8, v9 and web component versions. This also gives us opportunities to share common logic and we have a lot of business logic code.

I am investigating this and will let you know if we see any gaps.

We went with hosting these inside react-components so that we are able to stand up the system without worrying about the platform level nuances.

[AtishayMsft]

Im not sure we wanna have charting part of our v9 patterns etc as it is "out of core team control". The better approach here would be to live in your domain/structure similarily to web-components. This should be brought up to core team at tech sync to discuss further. ty

Is the idea here that we would move this to packages/react-charting instead of packages/react-components/react-charting. I like this since overall the intention of packages/react-components is to house the packages that ship in the v9 suite package, which we would not want to include charting in (as it would want to maintain the flexibility to make possible breaking changes). @Hotell what would be involved in moving this to packages/react-charting and keeping the same build capabilities that we have under packages/react-components? i.e. what's the cost, any issues with publishing to storybook or losing access to testing? also what are the benefits (possible independent pipelines?). We can take this offline with @AtishayMsft and me if the conversation is more involved.

Thanks for initiating this discussion. Our primary requirements are to get the platform support like vr tests, docsite, perf monitoring, api extraction and release management. Ideally we would prefer react-charting to be the nodal point to host our v8, v9 and web component versions. This also gives us opportunities to share common logic and we have a lot of business logic code.

I am investigating this and will let you know if we see any gaps.

We went with hosting these inside react-components so that we are able to stand up the system without worrying about the platform level nuances.

Our requirements seem to be satisfied by moving charts v9 package inside a charts folder. The charts folder will host react-charting (v8) and react-charts (v9) version of the charting library.

Thanks for your inputs. Closing this comment.

[Hotell]

@AtishayMsft @JustSlone

Our requirements seem to be satisfied by moving charts v9 package inside a charts folder. The charts folder will host react-charting (v8) and react-charts (v9) version of the charting library.

Thanks for your inputs. Closing this comment.

that sounds good to me, ty !

not sure what about the storybook and official documentation for charts:

• ideally we don't wanna load charting there during dev loop
• for official deploy we can probably adopt similar approach like we are doing for fluent-contrib ? ( storybook composition ) https://github.com/microsoft/fluentui/pull/33108
• if charting domain encapsulates various platforms ( web-components, react, etc ) IMO we should go with something like https://charting.fluentui.dev/

thoughts ?

[AtishayMsft]

@AtishayMsft @JustSlone

Our requirements seem to be satisfied by moving charts v9 package inside a charts folder. The charts folder will host react-charting (v8) and react-charts (v9) version of the charting library. Thanks for your inputs. Closing this comment.

that sounds good to me, ty !

not sure what about the storybook and official documentation for charts:

• ideally we don't wanna load charting there during dev loop
• for official deploy we can probably adopt similar approach like we are doing for fluent-contrib ? ( storybook composition ) docs(public-docsite-v9): embed fluentui-contrib docsite #33108
• if charting domain encapsulates various platforms ( web-components, react, etc ) IMO we should go with something like https://charting.fluentui.dev/

thoughts ?

As per offline discussion with Martin, we will create a new charting docsite and remove direct dependency from v9 docsite. We will try the composition approach to enable charts in the v9 docsite.

[github-actions[bot]]

📊 Bundle size report

✅ No changes found

[github-actions[bot]]

Pull request demo site: URL