RFC: Vertical and Horizontal Flow Component

[SiTaggart]

Creating horizontal and vertical flow in UI

Problem

As an engineer, I often have to lay UI elements on a page in a stack or row with each element being evenly spaced. Right now, there are a few ways I can achieve this but they are fiddly and not easily repeatable.

Prior art

https://bold.bridge.ufsc.br/storybook/?path=/story/components-hflow--default and https://bold.bridge.ufsc.br/storybook/?path=/story/components-vflow--default

Constraints

No component should style things that it does not own. It might be easy to create a styled component that uses a descendant and/or pseudo selector that controls the margin of child elements but it's really not a good idea to apply styling to something that a consumer is providing. You have no idea of the side effects, and the upgrade path is dangerous as you might cause a breaking style change in the future.

This works, but you shouldn't do it, IMO;

.flow > * {
  margin-bottom: 1rem;
}

.flow > *:last-child {
  margin-bottom: 0;
}

Design

A Flow component that can create vertical or horizontal flow within a UI, by wrapping the elements you wish to "flow". It takes a spacing prop that allows you to apply a spacing token and the creates the gap or gutter between elements.

<Flow direction="horizontal" spacing="space30">
  <Button variant="secondary">
    Button 1
  </Button>
  <Button variant="secondary">
    Button 2
  </Button>
  <Button variant="secondary">
    Button 3
  </Button>
  <Button variant="primary">
    Button 4
  </Button>
</Flow>

<Flow direction="vertical" spacing="space40">
  <Card>
    <Heading as="h2" headingStyle="heading20">
      First Card
    </Heading>
  </Card>
  <Card>
    <Heading as="h2" headingStyle="heading20">
      Second Card
    </Heading>
  </Card>
</Flow>

Check the code here in an Experimental example

Considerations

Perf

The CSS approach is browser optimised. On extremely large lists of things, this will (I'm at least sure) always beats mapping over children in react.

Feedback wanted

• Is this an idea you would want to see in Paste
• Is Flow a good name? Stack? Spacing?
• Should VFlow and HFlow be different or one component?
• What am I missing?

[GiantRobots]

Is Flow a good name? Stack? Spacing?

Grid makes more sense to me especially with the underlying primitive being css-grid. (Does this support IE 11? If not what's the fallback?)

Row/Column might be good choices as well (however this might be ambiguous with other components specifically table)

Should VFlow and HFlow be different or one component?

I like different components because I think the API is clearer if they do end up with different api surfaces. If the api surface is the same I don't mind if they're the same.

How do we expect people to have the correct width on these components (should this be handled by min-width?) Probably unsolvable through the api but a callout in docs with a preferred method might be wise. (should the default overflow be scroll or hidden?)

[serifluous]

Open question for anybody: If you want to see this component in Paste, where do you imagine you'd use it?

[TheSisb]

In light of Max Stoiber's recent article validating my beliefs that components should not have outer margins by default, I'm definitely for this.

Is this an idea you would want to see in Paste

Yup

Is Flow a good name? Stack? Spacing?

How about Spacer?

Should VFlow and HFlow be different or one component?

I think they can be two components from the same package, but we should play around with it for a bit to figure out what feels best.

What am I missing?

/shrug

[cfree]

Is this an idea you would want to see in Paste

Short answer: No.

Long answer: IMHO, it seems like an unnecessary level of abstraction. I would prefer that the containing component have control over where the children are displayed and often times that means writing custom styles to suite a particular design (as opposed to wrapping a style component around a set of components to then put in the containing component). Personally, don't love the idea of components just for styles; I'd rather see a set of utility classes that can be extended/included as needed.

I'm 💯% for having guidelines for vertical and horizontal rhythms, but I don't think one component (or a couple) can realistically accommodate all possible use cases.

Sidebar: As a newcomer to the Design Library discussion, is the ultimate goal to prevent engineers from ever having to write CSS? I understand the idea of having things be as consistent as possible across the brand.

[SiTaggart]

is the ultimate goal to prevent engineers from ever having to write CSS

Yes and no. The goal is definitely to stop folks having to write CSS is the old, global way with static classes names etc. This is proven in Console, a multi-tenant application, to not work. Teams regularly override one another, and because there is no global orchestration, no way to detect your changes don't break anyone else.

The goal of Paste and it's design primitives is to allow engineers to create custom CSS with design constraints and encapsulation. Box only allows certain values for properties such as background and border colors as an example. The css it generates is then unique to the application (to an extent, Emotions does some deduping and combining) and the version of that component. The values it allows are Design Tokens from the system, an abstraction layer from the components themselves.

What that allows us to do is continually role out updates to Paste component design, and anyone creating custom components are never negatively impacted. They are always protected from our component updates, but also always stay up to date with the design language via Design Tokens.

Separating layout from components is also just another safety net, it allows us to predict exactly what our updates will do to a downstream application, as we don't need to care. A component never has margin, it never affects another element on the page. You're then up to yourselves to lay them out as you wish.

For what it's worth, the Stack component has been released already for this purpose. https://paste.twilio.design/layout/stack

[SiTaggart]

To round this out, we shipped the Stack component. https://paste.twilio.design/layout/stack/