[docs][base-ui] Add Tailwind & plain CSS demos for Autocomplete page

[mj12albert]

Part of #37222

Preview: https://deploy-preview-38157--material-ui.netlify.app/base-ui/react-autocomplete/#introduction

[mui-bot]

Netlify deploy preview

• docs/data/base/components/autocomplete/autocomplete.md

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against b358d6c

[mj12albert]

@zanivan I've adjusted the proportions of the Autocomplete intro to match #37836 and #37750, would you mind having a quick look before I go on to make the plain CSS one and the rest of the demos on the page ~

Preview: https://deploy-preview-38157--material-ui.netlify.app/base-ui/react-autocomplete/#introduction

[zanivan]

Hey, that's great! I've just added some tweaks to box-shadow, but the proportions look good!

Just one quick question, will you create the plain CSS and Tailwind demos for all the demos on the page? Otherwise, if you're only doing one, perhaps would be better to start with the Basics demo, to keep it consistent with the other components

[mj12albert]

@zanivan Planning to do them all as the design is more or less identical ~ do you wanna exclude the introduction one for consistency though 😅

[zanivan]

No worries, if you're adapting all the demos it'll still be consistent—and also very helpful ✨

[oliviertassinari]

The toggles on the introduction demo looks great.

However, the toggle on the other is a no-no as long as the styles/source are duplicated between each demo.
We don't have the resources to maintain this at a high level of execution. We have all the demos of https://mui.com/material-ui/react-autocomplete/ to migrate to Base UI (no need to have most of them duplicated in Material UI IMHO).

Instead, I would propose we follow #37222 (comment), which will involve some docs-infra work to pull-off.

[mj12albert]

the toggle on the other is a no-no as long as the styles/source are duplicated between each demo.

@oliviertassinari do you mean to only add the Tailwind/plain CSS demos for the intro then and keep all the rest as system-only ?

Here it is the most complete one, as it includes use of Popper while the "Basics" one does not CC @zanivan

[oliviertassinari]

@mj12albert I mean that the heavy lifting of the component style, I think it should only be done once. I would propose that the demos that come after the introductory one either import the introduction component or be as simple as possible to explain the concept.

[zanivan]

Just to clarify, @oliviertassinari are you suggesting that we add the Tailwind and Plain CSS style selector only to the first demo?
If that's the idea, I wonder if it wouldn't harm the easiness of copying and pasting code from demos, regardless of the chosen style engine. I agree, though, that having the styles on all demos could harm the scalability, because it'd be very hard to maintain all these files.

Or, do you mean that we should have the style selector in all demos, but the demos from different styles shouldn't be visually different? If so, I agree with this and I resonate with your comment on #37222. We should definitely start using Joy UI design language on Base UI demos, but, as you said, it would be exhaustive to revamp all Base UI demos at once.

I propose we keep this discussion centralized on the Notion page created by @mnajdova to discussing this matter, at least up until we have a clear approach. In the meantime, we can continue adding styles only to the Basics and Introduction demos and also add to #37222 to keep track of these.

[oliviertassinari]

What if we were removing all of these Custom, Styled, or prefixes to keep it raw?

Suggested change

	const CustomAutocomplete = React.forwardRef(function CustomAutocomplete(props, ref) {
	const Autocomplete = React.forwardRef(function Autocomplete(props, ref) {

#38256 (comment)

It would be one step closer to how developer would export and use these components in their codebase.

[mj12albert]

Makes sense, I have renamed the components in the demos c62eb62

[oliviertassinari]

Just to clarify, @oliviertassinari are you suggesting that we add the Tailwind and Plain CSS style selector only to the first demo?

@zanivan I think it's OK to have the switch on all the demos, however:

1. The Introduction demo feels like the only one that truly matters, if we only have multiple styles and it's greatly done, I think it will get us 80% there.
2. For the others, unless it's automated, it feels like a negative ROI. Or at minimum, I would expect the path to user feedback to be easy enough for them to start to complain so we could start without.

Why? because 1. is what you will copy and paste in your code 2. is mostly what you will read to understand.

but the demos from different styles shouldn't be visually different?

No strong preference for this. I like the path of having the exact same style to keep it simple. This would reduce the combinatory of color contrasts we need to check to make sure it feels great. So increase our chance to provide a consistent great UX.

In the meantime, we can continue adding styles only to the Basics and Introduction demos and also add to #37222 to keep track of these.

I would even say Introduction is enough. On all the pages of Base UI, the Basic section feels like one we could remove tomorrow while improving the DX because it feels like a systematic duplicate of the Introduction section.

[mnajdova]

LGTM

[mnajdova]

I scoped #37222 to only the Introduction demos.

[oliviertassinari]

Looks good 👍

1. In the introduction section, It might be great to have the source of the component in a separate source tab. In the case of the autocomplete const top100Films = [ takes a lot of space. In the other pages, it would help to copy the source of the component.
2. @zanivan The style of the autocomplete connects back to this feedback on Joy UI: https://www.notion.so/mui-org/Olivier-design-review-on-Joy-Design-3ada9a7bcfa44b9fab1fe5032dfb33bb?pvs=4#40c4519ac5bf4e8d9f721f2d51377f9c. I think we should pick a side 😁

3. It feels like we should invest in style conversion automation. There is so much code to convert to Tailwind CSS and CSS, I fail to see how doing it manually is more efficient. If we could turn [docs][base-ui] Add plain CSS, MUI System, Tailwind CSS and non-styled option for the Introduction demos #37222 into a good to take to delegate to the community, we could maybe get away without automation for some time, by delaying it, but long term I don't see how.

[mnajdova]

In the introduction section, It might be great to have the source of the component in a separate source tab. In the case of the autocomplete const top100Films = [ takes a lot of space. In the other pages, it would help to copy the source of the component.

There are some disadvantages to this, especially for short demos:

• I can't just copy and paste it locally anymore, I will have to create few files and then copy each file
• have to switch between tabs if I want to see the source of the component vs how it is used

I like the idea, I just want to emphasize that it is not a silver bullet

It feels like we should invest in style conversion automation. There is so much code to convert to Tailwind CSS and CSS, I fail to see how doing it manually is more efficient. If we could turn #37222 into a good to take to delegate to the community, we could maybe get away without automation for some time, by delaying it, but long term I don't see how.

We could use tools like this for the conversion of the styles - https://tailwind-converter.netlify.app/. I am not sure if the automation will scale, for e.g. we use different methodology for creating the components, styled vs using slotProps. It would mean that we should match the class name selectors to slot names. More over, the tokens would kind of need to be matched manually (only once so that's fine). If we want to try it, we could do it with the select component as a test case, but honestly I feel like we are going a lot of time on it, and there will always be cases that won't be supported :) Maybe I am wrong, but that is my takeaway.

[zanivan]

@zanivan The style of the autocomplete connects back to this feedback on Joy UI: https://www.notion.so/mui-org/Olivier-design-review-on-Joy-Design-3ada9a7bcfa44b9fab1fe5032dfb33bb?pvs=4#40c4519ac5bf4e8d9f721f2d51377f9c. I think we should pick a side 😁

It indeed looks better! @siriwatknp How hard would it be to add a margin on the Joy UI select list, and a border radius to the items? If you're ok with this, I think we can open a PR to address it.

[mj12albert]

Thanks everyone for the review, I will merge this first!