miksuv

Yep. React was adopted a long time ago and it is also now the "industry winner", so no complaining there. Styletron is also older - created more than two years ago.

However, CSS in JS is more controversial and there are some other more popular libraries now. We keep monitoring them and at the same time we are bringing the best features back into Styletron. Also, you could use BaseWeb+Styletron and some other CSS solution for everything else. It's not a big deal (Styletron has like 7kB). But all CSS in JS libs are very similar anyway.

So overall, Base Web was not a big tech switch, React and Styletron have been already widely used.

That's just partly true. From the Base Web website:

"Base Web is a set of reusable React components that implements the Base Web design language and can be used in two different ways:

To build an application that fully adopts the Base Web design language, you import and use Base Web components out of the box.

To build a new design system inherited from the Base, you take Base Web components and customize them through the Overrides mechanism.

If you are building an application using the Base Web design language (the first scenario), you should avoid further customization. This helps to keep the design of your application consistent and makes future upgrades easier."

Uber uses Base Web in both ways since there are some additional related design systems (historic reasons) and that's why a lot of effort was put into overrides.

We currently use https://screener.io/ for Base Web itself and working on an app that should automatically crawl all our web apps, analyze them and provide insights into how exactly our components are being used. It should be open sourced eventually.

Right. We do exactly that as well. You can import all our styled subcomponents separately and then plug them back into render props. We just call it a bit differently - it's the "overrides" object prop and not a top level renderFoo prop. Example: https://baseweb.design/theming/understanding-overrides/#over...

The ability to extend the styles is just a shortcut. If I want to change a border for some specific subcomponent, I could import it, change the color (in our case through a css-in-js API) and plug it back through a overrides.FooComponent.component (which is nothing else then a render prop).

But that's a lot of steps to just tweak a border, isn't it? Why not to just have "overrides.FooComponent.style" and let the library do the rest. This doesn't open more surface, just a quality of life API. Arguably you can run into the same type of style breakages when devs are restyling our subcomponents. They will not look inside of them every single time we release a new version.

To be honest, the only really unique thing about Base Web is that you can replace every single subcomponent (1 subcomponent always renders 1 styled DOM Element) through render prop pattern and you can even do it in a layered fashion (passing children through). "overrides.Foo.props" and "overrides.Foo.style" are just shortcuts for render props. Other than that, it's just an another React component library.

"people are going to start using our components ways that we can't possibly ever fully anticipate" - That always happens no matter what you do! Unless you make your API super strict and then nobody will want to use your library. It's a delicate balance - keeping other teams moving fast and happy while not introducing breakages often.

I get this concern and I used to have a very similar feeling about it. Uber had an older React component library that was more locked down in a way you pretty much described. Number one complain was "not easy to customize" and that probably applies for every component library out there.

You describe render props as a "middle ground". For us, it is the last resort / nuclear option (as described here https://baseweb.design/theming/understanding-overrides/#over...). You give the consumer all the freedom to completely replace the guts of your component. Sure, nothing provides more flexibility but at the same time, consumer has to do a lot of heavy lifting - creating a whole new component.

However, developers usually want to tweak some small things. Maybe changing some color or padding. Forcing them to swap the whole subcomponent through render prop is an overkill and once they "opt-out" that way, they will never get any updates from us since that part of component is completely replaced.

Of course, ideally we want them to always use the defaults but that's not how real organizations with thousand of engineers and hundreds of apps work so we rather let them customize but on our terms. We don't want to see them hacking the styles through CSS selectors or "render prop" everything which equals not using our visual components at all. It's a compromise we had to make to make everyone reasonably happy.

Surprisingly, it's not a nightmare to maintain. We don't consider changed styles as a breaking change and in last 6 months I haven't seen complains about that. Although, it makes the Base Web codebase more complex and all changes need to be thoughtful. But that's a cost that Base Web pays so other teams don't have to.

What you describe in the first paragraph is exactly what you can do with overrides as well. Again, it gives you access to any subcomponent in the component and you can replace it with your own component.

Note, that you can replace a single layer and pass the "children" through OR "replace the whole branch" of subcomponents when NOT passing the children through.

Also all overrides get various state props. For dnd-list, it can be something like $isDragged, so you can conditionally render different things.

At the same time, every Base Web component is exporting all these subcomponents. For example, component DND List also exports:

- StyledRoot - StyledList - StyledItem - StyledLabel - StyledCloseHandle - StyledDragHandle

https://baseweb.design/components/dnd-list/#overrides

You are free to use these Styled subcomponents and recompose them any way you wish. You can build your own component from scratch (this approach works great for tables) or you can use overrides and utilize existing state handling etc.

Give me specific example: What customization of dnd-list you can't make with the existing overrides API and what other API would allow you to do that better.

I recommend to read through this to better understand the Base Web overrides: https://baseweb.design/theming/understanding-overrides/

It actually does everything you propose.

For render props, the BaseWeb API is not <Select renderDropdown={...} renderArrow={...} renderLabel={...} /> but it's collapsed under a single prop overrides={{ Dropdown: { component: {...} } ... }} naming convention. This "map" includes (and gives you access) to every single subcomponent.

The same goes for "adapting styles based on props".

BaseWeb uses exactly same patterns and techniques that you mention. The difference is the naming consistency and uniformity across all components. Instead of "littering" the top level API, we have a single prop "overrides" and instead of deciding what should and shouldn't be customizable, everything is customizable. Again, without a need to keep adding new top level props.

Are you talking about the theme? Can you be more specific?

It does use Flow.