Difference between Lab and Core components?

[jcafiero]

I was wondering if anybody could tell me what the differences are between the Lab and Core components. What is required of a component before it can move from the lab to the core package?

[oliviertassinari]

@jcafiero The main difference between the lab and the core is how we version the components.
The lab allows us to release breaking changes anytime we want while the core follows a slower-moving policy.
As our users battle test the components and report issues, we learn more from the design flaws of our components: lacking features, a11y, bugs, API, etc. The older and the more used a component is, the less likely we will find new flaws and we will need to introduce breaking changes.

In the current state of the lab, we are not aware of any significant breaking change we will need to apply. However, we will use them to incentivize users to upgrade to v5 (Q3-Q4 2020), to counterbalance the breaking changes we have planned.

We might want to improve this page https://material-ui.com/components/about-the-lab/ to clear it up.

[paul23-git]

Is there a clear path to core though? As in, can we as developers know if a certain component is "almost ready" for moving to the core? - Will it be next version, or the one after that or.....

[oliviertassinari]

When do we move a lab component into the core?

I think that we need the component:

1. To be used. We can look at the Google Analytics stats to evaluate the usage. A low usage component either means that we don't have it right yet or that there is a low demand for it.
2. To match the quality of the core components. It doesn't have to be perfect, none of the core components are and will ever be. It's about nor harming the trust developers have in our solution, to be reliable, so developers can depend on us.
3. Can it be used as a leverage to incentivize users to upgrade to the latest major? The less fragmented the community is, the better.
4. Have a low probability of breaking change in the short/medium future. For instance, if we know we want to introduce a new feature that likely require a breaking change. We might as well delay the promotion of it in the core.

A few notes on the current components in the lab.

• Tree View: not ready to go into the core, we still miss a few important features, and it's unclear how they will impact the API once implemented
• Autocomplete: the frequency of issues is going down, which is a good signal. For features we might want to add, I can think of built-in virtualization, enhanced data fetching integration, pagination. I don't think these features will require breaking changes (they might not even be in the core but enterprise, I have no idea, we will see).
• Skeleton: we had a couple of iterations recently. It's unlikely we will need to introduce a breaking change.
• Alert: a recent component, but from a complexity standpoint, pretty low.
• SpeedDial: it has been around forever, nothing to report.
• Rating: the accessibility of this one is challenging to implement. It's also hard to test with our test infrastructure (maybe we would need puppeteer or playwright?). It starts to be in pretty good shape.
• Toggle Button: I wonder if we shouldn't merge it with the ButtonGroup component 🤔.

[jcafiero]

@oliviertassinari Thank you for clarifying this for me. I agree, I think it would be beneficial to add a small description of the difference between a lab and core component to the page you highlighted above.

Where can we find a list of the features missing from a component, like what you mentioned about Tree View?

[oliviertassinari]

I think it would be beneficial to add a small description of the difference between a lab and core component to the page you highlighted above.

@jcafiero If it's something you want to contribute, we would be happy to review it.

Where can we find a list of the features missing from a component, like what you mentioned about Tree View?

You could look at the issues that have the TreeView label.

[jcafiero]

Yeah I can submit a PR sometime next week. Thanks!

[mbrookes]

I would add:

5. Needs type definitions.

We recently agreed that a component doesn't need to be typed to be added to the lab, but it would do to move to the core.

6. Needs good test coverage.

I may be mistaken, but I don't think all the lab components currently have comprehensive tests.

Toggle Button: I wonder if we shouldn't merge it with the ButtonGroup component

I agree, we shouldn't merge them. 😉

More seriously, I'll give basically the same answer I've given every other time this has been suggested: The have distinctly different concerns, both functionally and stylistically, so no, they shouldn't be merged.

[bthall16]

1. To be used. We can look at the Google Analytics stats to evaluate the usage. A low usage component either means that we don't have it right yet or that there is a low demand for it.

@oliviertassinari I'm curious what's meant by using Google Analytics to evaluate component usage. It's ambiguous if this refers tof how often a component's documentation page is being read or if analytics code is being injected into production apps using lab components. The latter would be worrying, especially since the lab documentation doesn't expand on this point further, but it also seems unlikely. Could you clarify?

[oliviertassinari]

@bthall16 It's a reference to the documentation pages. I will clarify it, thanks for raising it.