Over a million developers have joined DZone.

Components and States: Responsive Changes

· Web Dev Zone

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

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.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.


Published at DZone with permission of Niels Matthijs, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}