[website] List Tree View features on the Pricing page

[flaviendelangle]

Follow up on #42100

I did some cleaning in the code.
I struggle to understand some choices in the code of this page. Why do we have 5 listings (one for the JSX Element of the name, of for each plan and yet a 5th one to actually render the row)? This make the action of adding a new item super tedious...

Preview: https://deploy-preview-42328--material-ui.netlify.app/pricing/

Problem

• We have a doc for the Simple Tree View and a doc to the Rich Tree View. To which pages / doc sections should I link in the Pricing table?

[flaviendelangle]

We have "Row reordering" below

[mui-bot]

Netlify deploy preview

https://deploy-preview-42328--material-ui.netlify.app/

@material-ui/core: parsed: +Infinity% , gzip: +Infinity%
@mui/joy: parsed: +Infinity% , gzip: +Infinity%
@material-ui/lab: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Autocomplete: parsed: +Infinity% , gzip: +Infinity%
@material-ui/unstyled: parsed: +Infinity% , gzip: +Infinity%
Autocomplete: parsed: +Infinity% , gzip: +Infinity%
TextField: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Select: parsed: +Infinity% , gzip: +Infinity%
SpeedDialAction: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Menu: parsed: +Infinity% , gzip: +Infinity%
Tooltip: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Tooltip: parsed: +Infinity% , gzip: +Infinity%
SwipeableDrawer: parsed: +Infinity% , gzip: +Infinity%
TabList: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Drawer: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/Snackbar: parsed: +Infinity% , gzip: +Infinity%
SpeedDial: parsed: +Infinity% , gzip: +Infinity%
Pagination: parsed: +Infinity% , gzip: +Infinity%
@mui/joy/MenuButton: parsed: +Infinity% , gzip: +Infinity%
Alert: parsed: +Infinity% , gzip: +Infinity%
and 264 more changes

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 0501833

[oliviertassinari]

We have a doc for the Simple Tree View and a doc to the Rich Tree View. To which pages / doc sections should I link in the Pricing table?

This could be asign that the docs organization should be inverted. Group per feature, before per component type 🤔

[oliviertassinari]

This might be simple enough, feels almost clearer

Suggested change

	'tree-view/item-virtualization': <ColumnHead label="Item virtualization" />,
	'tree-view/item-reordering': <ColumnHead label="Item reordering" />,
	'tree-view/item-virtualization': <ColumnHead label="Virtualization" />,
	'tree-view/item-reordering': <ColumnHead label="Reordering" />,

[oliviertassinari]

Maybe clearer

Suggested change

	label="Multi item selection"
	label="Multi selection"

[oliviertassinari]

Maybe clearer

Suggested change

	<ColumnHead label="Item selection" href="/x/react-tree-view/rich-tree-view/selection/" />
	<ColumnHead label="Single selection" href="/x/react-tree-view/rich-tree-view/selection/" />

[flaviendelangle]

Should we update the grid equivalent feature?

[oliviertassinari]

In my view, the data grid, needs to differentiate between row and cell selection, but the pricing page stills uses the same terminology as in the docs pages.

I would see the pricing page always matching with what the docs use, it's one less thing to have to think about. So I think "Should we update the grid equivalent feature?" is truly about asking:

should stay like this, or become:

I personally feel that it works well as it's today in the docs.

[flaviendelangle]

This could be asign that the docs organization should be inverted. Group per feature, before per component type 🤔

Both component do not always behave the same.
So the logic for us was to avoid docs with a lot of "IF YOU ARE ON X THEN DO Y, OTHERWISE DO Z".
Basically, to have the doc as readable as possible, even if it costs some duplication.

[oliviertassinari]

We have a doc for the Simple Tree View and a doc to the Rich Tree View. To which pages / doc sections should I link in the Pricing table?

Both component do not always behave the same.

@flaviendelangle Ah right, so <RichTreeView> isn't as simple as <TreeView><TreeItem> composed together and avoid code repetition for developers? Because otherwise, it could be documented like in https://mui.com/material-ui/react-text-field/#components.

Overall, I would propose to be consistent, we have a similar problem with composition for charts, Material UI vs. Base UI + Pigment CSS. Maybe it could be like this:

• Link/show to the higher-level API first. If people can get away with this, great
• In the higher-level API pages, reference the lower-level API so that once people hit a wall, have them have an escape path.

For example in https://mui.com/x/react-charts/bars/. I imagine we will create docs for how to recreate the <BarChart> with the lower-level component API cc @alexfauquette

Now, the downside of showing the higher-level API first, and the lower-level API second is that people might stop at the higher-level API, but turned-off and not look further enough to find the lower-level API. But I don't know, the opposite failure mode feels as bad.

It relates a bit to a discussion we had with @colmtuite & @danilo-leal during React Conf about either Material UI v7 should drop the <TextField> API and be pure composition, matching Base UI like API, or be like today, or provide both.

[flaviendelangle]

isn't as simple as composed together and avoid code repetition for developers?

It is not
The SimpleTreeView is an improved version of the component that comes from the core. It has several limitations due to how items are handled, for instance if you disable an item on mount, it flickers because it's the Tree View which stores this information and during the 1st render the item did not have the time to register itself. Collapsed items are, by definition, not rendered so their state is lost, etc...

We could probably heavily re-work the SimpleTreeView component in order to have it fully work with all features and have RichTreeView be a wrapper on top of it, but it's not the road we took. SimpleTreeView is a component meant for basic use cases, with a few items and no complex data manipulation, whereas RichTreeView should be compatible with virtualization, re-ordering, lazy-loading etc... RichTreeView is IMHO not comparable to what the Base UI component are doing, it's closer from the DataGrid in essence, so I don't think the ongoing composition discussions really apply here.