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 #

[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 ) 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 ?

[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]

📊 Bundle size report

✅ No changes found

[github-actions]

Pull request demo site: URL