Layout-Isolated Components

Layout-Isolated Components visly.app3 months ago in #Dev Love62

The move to component-based development has enabled a large number of really incredible improvements to tools and the front-end ecosystem as a whole. Remember when we were building our apps as a set of screens and pages instead of thinking in components? The component model has changed this entirely – now, we think of pages as a composition of reusable components. As a result, we’ve also seen a huge increase in the number of open source UI components being built, published, and reused between applications. This modular approach to UI is vital to us at Visly since it’s what enables our product to work with any app right away. In the pre-component era, we would have probably required you to build your whole app inside of Visly from scratch. However, a lot of CSS layout patterns come from this pre-component era, and I want to discuss with you here how some of those patterns should be deprecated, as they break the modularity and composition assumptions of components. Layout isolation Before we jump into the properties and patterns we should be avoiding, I think it’s worth exploring conceptually what we’re trying to avoid. Essentially, we want to avoid any properties on the root element of a component that affect, or are affected by, elements outside of the bounds of that component. I would discourage properties like margin, because they act on elements outside of the component’s scope; the same goes for properties like align-self, as it will stretch the width or height of the component depending on the flex-direction of its parent. In contrast, properties like padding are fine, as they are confined to the scope of the component. Basically, if a property depends on, or impacts, other components outside of its scope, I would discourage using it. Layout-isolated component – A component that is unaffected by the parent it is placed within, and does not itself affect the size and position of its siblings. Something I think worth reiterating is that this only applies to the root element of a reusable component. So for example, as you can see in the code below, using align-self does not make a component break layout isolation automatically, just if it is placed on the root element. // Does NOT comform to layout isolation principals function MyComponent() { return ( ) } // This component is layout isolated function MyComponent() { return ( ) } What properties make a component break layout isolation? Any property which affects, or is affected by, elements outside a component scope are not layout isolated properties and should be avoided on the root layer of your component. I’ll cover a couple of the most common properties (and why they pose a problem) below. Align self The reason align-self is not layout-isolated is that it will apply vertical or horizontal alignment to the component depending on the direction of the container in which it’s placed. It’s especially bad when using stretch, as setting that as the value means your component will end up stretching either vertically or horizontally depending on its container. Some components are built to be stretched in either direction, but this is not the case for the vast majority of components. So how do you solve this? Should you stop using align-self? Not at all! All you need to do to make your component reusable while still using align-self is to allow the parent to pass in the alignment value. // Don’t do this.  » Read More

Like to keep reading?

This article first appeared on If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply