No bundle size changes comparing c8176bb...da8541f

Generated by 🚫 dangerJS against da8541f

Currently trying to tidy up the text field demos, as part of this and #17643 we should probably move the select demos from TextField completely and link to the actual select page. Although I'm not sure how clean having the select prop is.

cc @mbrookes Just for visibility - Still changing things though :)

Still need to add the Select demos back

Looking good so far. A few random thoughts:

1. I wonder if it would be worth keeping a comprehensive (Edit not as in a big list of examples, but one that shows all the key features (label, placeholder, helper-text etc.) example of each of the variants at the top of the page for visibility? (Edit: "visibility" such that a casual visitor to the page can see an example of the three variants without having to interact with the playground.)

2. It would be helpful to show the code needed to recreate the selected options, as we do in the other "playgrounds".

3. We need to decide what to call it, if not "Playground" – we already have a showcase (for sites built with Material-UI).

4. I don't think the warning triangle and tooltip for are needed for the standard variant.

@mbrookes
Cc @mui-org/core-contributors

1. Might be helpful, I’m not sure though
2. @oliviertassinari suggested this too but I’m not sure either, I’ve never used something like that before
3. Playground seems fine
4. Fair enough

I’m interested in what everyone else thinks. I’m not sure if we even need an interactive demo since it will just add to the duplication.

TBH I don't know what designers prefer. If I see screenshots from design systems these days it's mostly each combination next to each other.

For a designer it might be more helpful to have a fully customizable (a withStyles(configurableStyles)(TextField) textfield with c&p capability of the used styles object.

But material.io also has an interactive demo now so this seems fine as a starter.

I would only question the use of tabs for variants. Have you considered moving those to the left as a radio group? Basically mirroring the options but on the left.

TBH I don't know what designers prefer. If I see screenshots from design systems these days it's mostly each combination next to each other.

@eps1lon Interesting insight!

I think that it supports the idea that humans prefer to move the eye and scroll rather than click to trigger actions. I personally find the cognitive overhead higher when I have to click on something vs scrolling. I think that it's an argument for more small demos instead of a playground/showcase.
You can get a sense of this experience difference when browsing Vuetify (with playground) vs Bootstrap (without). I enjoy the Bootstrap docs experience more. So I'm in favor of as little playgrounds as possible and more small demos.
In the case of the text field, it would mean breaking the existing demos in x5? more.
Why not have a playground, but lower on the page and importantly, with sources people can copy and paste.

material.io also has an interactive demo now so this seems fine as a starter.

I'm curious, why do you guys think they have such an interactive demo? The main value I see in it, for them is: "look, guys, we have this implemented, you can use it, today" and a bonus point for being compact, leaving space for the specification sections. I don't think that it's a problem we are facing.

In our case, I think that the playground is interesting when there are too many props permutation we can demonstrate in small demos. I believe looking at the existing playground highly part of their interest. We have added them, along the way to solve the problem we were facing, at different points in time. I don't think that we had a global strategy, a master plan. But now, as we have this past history of solved problems, we can, with hindsight, look at them and think: "OK, so what makes good usage of the playground, when did we add them, can we find common patterns?" I think that I have answered part of it in the first paragraph.

What do you guys think?

I think that it's an argument for more small demos instead of a playground/showcase.

Agreed - see my comments about wanting to at least keep a demo of the key features of each variant to avoid having to click around in the playground to see the component variants.

I like the idea (Bootstrap style) of having the demo side-by-side with just the essential code snippet that only shows the component and the props that affect its appearance / behaviour:

<TextField label="Email address" placeholder="[email protected]" />

The show-code button could still be used to see the full worked example with imports, callback logic etc.

I like the idea (Bootstrap style) of having the demo side-by-side with just the essential code snippet that only shows the component and the props that affect its appearance /behavior:

Same feeling. It's great not to have to click on the show code button and not to have to dig in the sources to find the correct props to apply. You scroll, you evaluate, you copy. End of story.

However, it won't work with all the demos. Some are too complex. We could look at the % of demos we have that could benefit from such an approach. If this figure is high enough (to be defined) it could make sense to invest time in it. Sebastian has done an effort in this direction a few months ago. He has added support for a source panel open by default. It has helped.

Some are too complex.

Agreed. I had the words "for those that are simple enough" in my comment, and edited down for brevity.

support for a source panel open by default

Yeah, that's super useful where the code sample is the primary concern, and the output is secondary. For this though, it's a minimal subset of the code used to render the demo. "Show source" is still useful to see the full code sample, but the default view is the bare essentials.

So based on everyone's feedback. I think we should take the following steps:

1. Keep the demo refactor (splitting up) from this PR and remove the Playground
2. Revisit the Playground focusing on overriding CSS or the common props e.g. label, placeholder?

Keep the demo refactor (splitting up) from this PR

@joshwooding I think that this change (and it's possible developments) alone is valuable 👍. I hope it will answer the problem reported by the users: struggle to find the source / too large demos.

remove the Playground / Revisit the Playground focusing on overriding CSS or the common props e.g. label, placeholder?

It depends on the objective, what problem(s) do we solve?

I like the idea (Bootstrap style) of having the demo side-by-side with just the essential code snippet that only shows the component and the props that affect its appearance / behaviour:

@mbrookes I have found the following projects that explore this space (I mention the diffs with us, I have ignored the libs that do it like us, e.g. fabric, atlaskit):

• https://evergreen.segment.com/components/tab. They display the code below. The code is automatically expanded when small. You can't see the imports.
• https://primer.style/components/FilterList. They display the code below. Only simple demos. You can't see the imports.
• https://auth0-cosmos.now.sh/docs/#/component/avatar. They display the code below. You can't see the imports. It always starts with a playground. The code is no expanded by default (unless for the playground)
• https://ant.design/components/auto-complete/. They display the code below.
• https://www.smooth-code.com/open-source/smooth-ui/docs/card/. They display the code below. Only simple demos.
• https://react-bootstrap.github.io/components/dropdowns/. They display the code below. Only simple demos.
• https://reactstrap.github.io/components/alerts/. They display the code below. Only simple demos.
• https://sancho-ui.com/components/avatar/. They display the code below. The code is automatically expanded when small. You can't see the imports. You can edit the demo.
• https://semantic-ui.com/collections/breadcrumb.html. They display the code below.
• https://baseweb.design/components/checkbox/. They display the code below. They start with a playground.
• https://chakra-ui.com/accordion. They display the code below. You can edit the demo.

So to summarise:

For those that don't display the full code, all show just the content of the render method, but Chakra also shows the full component function if it contains assignments used in the render method.

@mbrookes Do you have a preference for each of these dimensions? (our benchmark isn't comprehensive) Which one would improve the UX?

"Bye TextFields you will be missed."

Uh, nope! 😄

👌