131–140 of 156 posts
Referencing and being inspired by someone‘s Design System is a good thing. Try looking at a bunch of them to get a better perspective. However, using someone's Design System may not always be a good choice. Unless, they are lean, non-directional and are mostly patterns that you can adapt to any tech stack or systems. For instance, Google’s Material Design Philosophy is a good starting point and you can leverage it as…
It does force everyone in your organization to not only use React, but also Styletron which might be a pretty large switch for some teams. Has this been a problem?
I think this could lead to limited adoption in some organizations because autonomies teams want to keep delivering with their current stack.
One idea I considered is to have an Atomic CSS library for theme stuff like whitespace, color and typography, and compose those into components for React or Svelte 3 or whatever is hot right now.
All other styling could be done with Styletron, styled components, or plain CSS, whichever suits your team.
Earlier quoted context omitted.
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.de…
I can appreciate that you guys weighed the tradeoffs and decided that giving users freedom to override arbitrary styles is worth the cost of whatever breakage might result from that decision as you upgrade the library. We're all engineers who build things to solve real world problems at the end of the day, and I don't have any of the context that led up to your decision, so I can't say for certain that I'd have weigh…
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.
Referencing and being inspired by someone‘s Design System is a good thing. Try looking at a bunch of them to get a better perspective. However, using someone's Design System may not always be a good choice. Unless, they are lean, non-directional and are mostly patterns that you can adapt to any tech stack or systems. For instance, Google’s Material Design Philosophy is a good starting point and you can leverage it as…
Any recommendations?
Earlier quoted context omitted.
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.de…
Do you use any sort of visual comparison tools or snapshotting in CI to catch regressions caused by changes to Base? Seems like this would remove any (technical) objections to having overrides.
Earlier quoted context omitted.
Note that the above mostly applies to company/product specific component libraries where maintaining design/brand consistency is of great importance. For components meant for public consumption, I personally would only use libraries that yield _all_ rendering decisions to the user: not just styling, but the components being rendered as well as the way in which those components are composed. Usually that means providi…
I think there's a big difference between Downshift and Base Web. Downshift is a low-level component offering powerful behaviors that you can use to build your own UI widgets, etc. Base Web looks more like a set of ready-to-use UI widgets. You use it because you specifically want a button that's styled and works the Uber Base Web way. Uber wants all of their buttons to look consistent, so obviously Base Web is going t…
"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.
Nice, looks very well made. It does force everyone in your organization to not only use React, but also Styletron which might be a pretty large switch for some teams. Has this been a problem? I think this could lead to limited adoption in some organizations because autonomies teams want to keep delivering with their current stack. One idea I considered is to have an Atomic CSS library for theme stuff like whitespace,…
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.
Earlier quoted context omitted.
You're out of your mind if you think that's an better way to compose components. How would you do something like this? { switch(listItem.type) { case 'foo': return {listItem.title} ; case 'bar': return {listItem.title} ; default: return {listItem.title} ; } })}>
https://gist.github.com/tajo/a84d96f248d454d1226e12bb07c8157...
Earlier quoted context omitted.
I've been evaluating most of these frameworks, and as far as I know Base UI is the smallest and lightest out of all these: https://bundlephobia.com/result?p=baseui@6.15.1
They're all still big and bloated (like including big sets of icons) but you should only only include what you're using. Tree shaking with webpack and babel and a css optimizer can trim them down significantly.
I guess we can add Uber to this list of corporate frameworks... https://news.ycombinator.com/item?id=18235887 https://element.eleme.io/ https://ant.design/ https://quasar-framework.org/ https://at-ui.github.io/at-ui/ https://developer.microsoft.com/en-us/fabric https://vmware.github.io/clarity/ http://appnexus.github.io/lucid/ https://ng-lightning.github.io/ng-lightning/ https://blueprintjs.com/ http://www.jetbrains.…
Other sites tend to have rendering issues with some lines in letters either becoming doubly thick or barely visible, white text pixelating out to bright backgrounds, anti-aliasing turning some pixels colorful or too dim etc. Some of them seem to be exposing edge cases of text rendering! Text could be too gray to read or too thin.
Designers need to consider people still buying laptops with 1366X768 screens.