Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Components and States: Responsive Changes

DZone's Guide to

Components and States: Responsive Changes

· Web Dev Zone ·
Free Resource

Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.

Responsive web design taught us a thing or two about component-based front-end development. Before we were talking RWD, front-end components were pretty straight-forward. They presented a singular solution to a problem and that was that. Each component matched a more or less fixed HTML structure that could be brought to life using CSS and JavaScript. But since responsive design took over by necessity, varying layouts and devices started to affect the once so robust patterns we devised for ourselves.

Still, HTML-wise very little has changed. In the end HTML just describes what a piece of content is, rather than describing its appearance or functional behavior. On the CSS side of things we were helped by media queries. A far from perfect solution but we can make do for the time being. But what about functional changes (ie JavaScript is involved) ?

A lot of functional components we used to define (carousel, accordion, tabpane, swipe list) are more or less interchangeable depending on the context. What is a carousel on non-touch desktop can become a swipe list on tablets and could even be turned into a plain old list on mobile. The actual component here is a mere container of data clusters, which can then be given a different functional behavior depending on its context.

The dilemma here is whether to hardcode this information into the HTML, or to leave it up to JavaScript to implement the correct behavior for each instance of the base component. Hardcoding it into the HTML means that you lose some flexibility in your CSS and JavaScript when something needs to be changed. Finding a syntax for hardcoding isn't that easy either. You have to list the condition (which could be a breakpoint, touch context, OS context, ...), a value for that condition and the corresponding state while making sure you don't create conflicts. Relying entirely on hooks on the other hands means that you could end up a few hooks short to properly implement everything.

It's an interesting exercise that will require some balancing between defining components and states. Trial and error is probably the key here, but it will definitely change the way we look at components in the future.

What’s the best way to boost the efficiency of your product team and ship with confidence? Check out this ebook to learn how Sentry's real-time error monitoring helps developers stay in their workflow to fix bugs before the user even knows there’s a problem.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}