Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Base Web, Uber’s New Design System for Building Websites in React

eng.uber.com

Post reply on HN
Print view View original

111–120 of 156 posts

Re: Base Web, Uber’s New Design System for Building Websites in React

#111

Post by jscholes »

> drag and drop Lists are notoriously difficult to implement because browsers provide little help when developers have to build drag and drop interactions. Developers using Base Web have the peace of mind that keyboard navigation is reliable and works well with screen readers.

FYI, their drag and drop sample doesn't "work well with screen readers". It's overly verbose and requires keyboard passthrough to operate. So maybe don't take any web designers at their word when they say you can just use their framework and forget about accessibility.

Re: Base Web, Uber’s New Design System for Building Websites in React

#112

Post by manigandham »

wuliwong wrote: post #76
insomniacity wrote: post #31

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.…

You seem to trying to express a negative response to the fact that these companies create design frameworks. I'm interested as to why you feel this way?

The post is just a copy of a copy: https://news.ycombinator.com/item?id=17971337

No real intent there. It's good to have large organizations donating libraries to open-source.

Re: Base Web, Uber’s New Design System for Building Websites in React

#113

Post by tomelders »

tomelders wrote: post #77
SubFuze wrote: post #70

Earlier quoted context omitted.

A big part of the goal with the overrides mechanism was to provide usable components out of the box that could optionally be modified if something needed to be changed for a given use case. You can use the components as is, using props if you're ok with the out of the box style/functionality/etc, without ever touching overrides. The overrides provide a standardized interface to changing the component internals across…

But you’re still creating a suite of components that can be composed to create a specific instance of a date picker. Except with the override config, you’re now complicating and limiting the simple and versatile concept of composition. Your components now need to follow some pre established and short sighted rules in order to understand how to manage their own children. To use the example in the article, lets say you…

It turns out I was wrong about this, but not in a good way.

It appears you can pass functions to the config that render components, which presumably can also take an override config which in turn can take a function to render components and so on. So it's basically negating the entire point of JSX. It's halfway between JSX and React.createElement. The worst of both worlds.

Re: Base Web, Uber’s New Design System for Building Websites in React

#114

Post by steveax »

lhorie wrote: post #48
Theodores wrote: post #41

This article makes a lot of noise about Uber's commitment to accessibility. So I am led to believe that this new React gizmo is fully accessible. Yet Uber can't be bothered to make efforts to get basic accessibility right on the page that tells us this. The main content is not in a element, this element being the landmark that tells people using assistive technologies where the main content is. Then the navigation li…

Those are issues with the CMS being used to host the blog. The blog has been around for a long time and isn't using BaseWeb. What you're suggesting is that when someone releases a library with a commitment to accessibility, they are also responsible to reach out to some completely unrelated comms-focused team, take over their CMS workflow, rewrite it entirely with the new framework, and only then make a blog post abo…

There are accessibility issues beyond the landmark elements. For instance the close button on the drag and drop example has no accessible name.

Re: Base Web, Uber’s New Design System for Building Websites in React

#115

Post by lewisl9029 »

The overrides pattern they describe sounds like a nightmare to maintain. It's almost the exact opposite of how I'd design the API for a set of reusable components: provide a minimal API surface to cover existing use cases, and evolve the API deliberately to cover new use cases as they arise.

Allowing users to override arbitrary styling parameters is a recipe for disaster in a reusable component, because once you start doing that, literally any change you make to the component could become a breaking change for some usage of it in the wild. There is no more explicit interface that users of the component are expected to work with that you can hide implementation details behind, as to afford you the ability to change those implementation details without breaking users, because users can just reach into your implementation details with those arbitrary parameters and change them at will, in a way that's potentially incompatible with how you might want to evolve the component in the future. As a side effect, any sense of brand/design consistency you might want to enforce through a design system goes out the window. Interestingly enough, this set of components use component-oriented CSS-in-JS, which is a pattern developed specifically to provide style isolation between components that wasn't possible (or at least not in a foolproof way) with regular CSS, yet they chose to open that can of worms back up through their API.

I've found that a much better middle ground is to deliberately accept React nodes or render props in your components so that you can explicitly yield control of rendering to users for specific, isolated pieces of the component, like the contents of a modal or the individual options of a dropdown. This gives users freedom to render what they need to render, but within the confines of a consistent design framework that enforces overarching rules around consistent use of spacing, colors, transitions, etc. And such an API can still be evolved deliberately to support new use cases without the risk of breaking users unintentionally.

Re: Base Web, Uber’s New Design System for Building Websites in React

#116

Post by cageface »

wes-k wrote: post #110
dwaltrip wrote: post #61

Earlier quoted context omitted.

Any other good candidates? This is something I really need to look into soon.

I work with blueprint and I find it to be pretty incredible. Typescript based, fairly comprehensive, good docs, easy to use.

Blueprint looks nice but last I checked it wasn’t responsive, which nixed it for my current project. Is that still the case?

Re: Base Web, Uber’s New Design System for Building Websites in React

#117

Post by lewisl9029 »

lewisl9029 wrote: post #115

The overrides pattern they describe sounds like a nightmare to maintain. It's almost the exact opposite of how I'd design the API for a set of reusable components: provide a minimal API surface to cover existing use cases, and evolve the API deliberately to cover new use cases as they arise. Allowing users to override arbitrary styling parameters is a recipe for disaster in a reusable component, because once you star…

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 providing state & handlers through a render prop API, so users can compose their own styled components in arbitrary arrangements that wouldn't be possible with an interface that only exposes specific component overrides inside of a rigid structure. See downshift as an example of a library that does this really well (https://github.com/downshift-js/downshift), and contrast that to something like react-select that only offers the ability to provide overrides for specific components in its own predefined render tree (https://github.com/JedWatson/react-select).

Perhaps on top of that you can also provide a reasonable styled default, but not offering low level control of rendering is usually a deal breaker in my book when picking third party components to work with.

Re: Base Web, Uber’s New Design System for Building Websites in React

#118

Post by manigandham »

tomelders wrote: post #71
mmckelvy wrote: post #9

I've been searching for a basic React UI component system for awhile now. There are a lot of systems available, but each one has significant drawbacks to the point I end up just rolling my own. I think an ideal system would have a core set of "unstyled" components with the necessary functionality baked in. That way the overall aesthetic is up to you, but a lot of the painstaking UI work (e.g. showing, hiding, and hig…

For the past few years, i’ve been building “reusable component libraries” and I can say with confidence that they’re a massive waste of time. When you get into it, the UI usually the least difficult problem to solve in an app. The real challenge is state management, control flow, and wrangling sode effects. Alas, people are still wedded to the idea that UI is where all the time is wasted. The truth is, it’s always be…

If you have a github repo then please post it. It'll get some attention as this is a much more common sentiment than it seems.

Re: Base Web, Uber’s New Design System for Building Websites in React

#119

Post by cachvico »

insomniacity wrote: post #31

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.…

This is a great list! Thanks for sharing.

Re: Base Web, Uber’s New Design System for Building Websites in React

#120

Post by miksuv »

lewisl9029 wrote: post #115

The overrides pattern they describe sounds like a nightmare to maintain. It's almost the exact opposite of how I'd design the API for a set of reusable components: provide a minimal API surface to cover existing use cases, and evolve the API deliberately to cover new use cases as they arise. Allowing users to override arbitrary styling parameters is a recipe for disaster in a reusable component, because once you star…

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.

Post reply on HN