Adaptive?! Responsive? Reactive!
I hope somebody told you – your site should be mobile friendly and adaptive.
I hope somebody told you – responsible is a must.
I am not sure did someone told you the difference between adaptive and responsible, and what you actually have to do to be responsible for being adaptive 🤔. Even more – information I could found in internet is a bit… is a bit complicated. And it is complicated after all.
To make things even more tangled — some Google own sites are not quite responsible, Facebook uses a old-school static grid, and blows up then you “zoom in”. It’s not easy to follow the Lead, then your Lead is not following their own propositions and recommendations, drown down by a legacy code.
So, the best thing I could tell you-
Don’t look how bad something is,
look how good is something else.
There are million sites, which get it right and did it right.
Responsive
Responsive stands for flexible or fluid design, able to adopt to any screen resolution, and use all of it. Fill all the space available, present the information from the best prospective. Always the right point of view.
Responsive is like a water, thank you Wikipedia.
The golden rule of responsive grids – never use pixels, but percentages everywhere. As result – some blocks will always take 50%, not 400px of customer screen, and all the information on site will be scaled proportionally (if should). And very predictable! And very useful. Very responsible.
Feel free to use CSS Media Queries to more accurate “tuning” the way elements are displayed. You can use Media Queries even for moving stuff around, using position, or index properties.
🤔 I would say — Responsible is a static HTML powered by a dynamic CSS.
Adaptive
And, you have to know it, one template cannot fit all the screens. It is not always possible. Some design decisions could not be done using responsible approach, due to more deep changes they might require.
And Adaptive Design will save the day.
Adaptive design adapts to media target change, providing different results, different templates, for different resolutions or devices.
“Adapts” in the different way — adaptive could change the way menu is rendered. Or replace a gallery by a slider. Or replace one-step wizard by 3-steps wizard for the usability sake. Some times changes could be huge.
It will not just try to do the best — it will take a look from another angle, to overtake the problem. Will burn everything to ashes and raise again.
🤔 I would say — Adaptive is a static CSS powered by a dynamic HTML.
🧠: If Responsible and Adaptive would get lost on inhabited island – Responsible will become a wild animal, in the human body, able to survive the new conditions.
Adaptive will put the wings on, and fly away 🚀
Mobile first
While being responsible you may add, move or remove some blocks to render a better result for a current media.
The secret is – it is much harder to remove something from design, than add it.
If you will take desktop as base resolution, and then hide some elements to fit into small mobile screen, then.. then good luck – it is really hard doable. You will have to pick which very important information you are ready to loose.
The right and the easy way is to start from mobile, keeping all important things, and then add not so important elements while resolution will grow.
That’s why it’s called mobile first. Mobile goes First.
Which technique to chose
Should you go with adaptive? Should you prefer responsible?
I still couldn’t get the point why it is a question. Sure — use both! They complete each other.
Adaptive to adapt to the device specific details, and responsible to be fluid in the medium.
And if you are using React you are already could be adaptive from “React” point of view, and responsible from CSS. You can adapt to data in real time. Think about it — if you can adapt to data, then, probably, you can adapt to everything.
Is where any difference which variable use for conditional render — real, or computed from device resolution?
Reactive ⚛️
That’s a deal! React could render everything you will ask it to render. And the goal — just to render different markup depending in Media Query.
You can use the same Media Queries, you used in CSS,
but in JS!
Let’s start with React-Media component, from React-Trainings:
I hope this example is oblivious — it will “matches” provided media, and you can pick what to render, depending on the result. This approach could enable new features, and open new horizons.
More Reactive and more Adaptive.
It’s common to render ToDo item, based on the data in the State. It should be common to render your application differently, based on the Device.
🤔 I would say — Reactive is a dynamic HTML, powered by a dynamic CSS.
What could go wrong?
Media component, it the example above, and 99.9% component of such type, are working a but differently from CSS version, and… lead to hell.
“RenderProp”, provided by <Media/> component, could be true or false. As long usual adaptive site contain at least 3 different resolution, not 2. But might more, and even rely on device orientation. It’s easy to make a mistake, and render literally nothing.
You can forget provide content for specific target, or use different targets in the different places. Media should not be a “variable”.
It’s easy to make a mistake.
Media should not be a “variable”.
Let me be more concrete — here is an example from React-Responsible
It does violate a few Base Principles, basically half of SOLID, and very allergic to errors. It’s just a bug-magnet. And just a GOD component.
I am not feeling ok blaming others work, but I have to warn you about this quite popular library. It is something I am fighting against. Something I have to kill.
And it’s easy to fix mistake by changing used code pattern. Don’t try to fix your code, try to fix the way you code, to make it more resilient and error prone.
That’s a thing nowadays — we all “here”(in React, in ES6, in Chrome, in Medium) as long we are trying to find a better ways. And founding them.
To make adaptive rendering a bit more “safer”, lets create constant device placeholders — mobile, table, desktop, and provide a value for each placeholder.
Like a changing binary if logic to a switch. It’s like a structure in typed language — always known which fields to provide, and which are optional.
And what if you will skip one render target? “Mobile first” principle will just use previous one. As result — you can’t forget to provide a view for some device, and get nothing instead of amazing page.
Now, let me introduce another React Media Query “interface”(it’s always the same media-query underneath) — react-media-match. It’s based on no binary logic. Like changing if to switch, as I said before.
This is similar how “mobile-first” works — starts with minimal set of features, and uses the maximal available variant. If maximum is desktop — desktop will be used. If tablet — tablet in the first case, and mobile in the second — cos mobile will be “maximum possible” match. What if you have only desktop? Then it will be “maximum possible” match. What if you don’t want to render something — define target as “null”. Null is defined, but still null.
The same pattern could be used to provide different values for a button label, depending on a device. You can “pick” the right value from the set.
The same approach could be used to do a Server Side Rendering. As long you are not matching “media — query”, but “device” — the information about device used become a State. And state could be changed.
Media Query is a State. You can control a State.
If you are looking for adaptive solution, or just a comprehensive media-matcher — take a look on react-media-matcher. It’s the best. And the only
Probably this moment — contant placeholders for a media devices and treating media as a state is the major difference between react-media-match and other libraries.
It’s typed, error proof, compatible with SSR, well designed, and tested in combat.
Reflexible
But sometimes you cannot predict what you will have to render, or cannot design different templates for different devices, and responsible approach is not fitting all your needs (it’s not about changing the content).
So you need a “flexible” solution.
Something like this:
In this example browser itself will try to pick the “best” view to display, letting you less worry about details, and focus on content.
Powered by React-Reflexible. Magical, and very.. flexible :)
Should I go reactive way?
The short answer — NO!!! Please don’t try. You will success, but user will not.
Just follow a simple rule: if something is doable using CSS — do it with CSS.
if something is doable using CSS — do it with CSS.
Flexbox index — could move stuff around. Grids — even easier. Display:none? Why not, sometime it’s better than controling visibility of an element via React conditions.
CSS is controlled by browser, and sometimes it’s better explain to browser what are you going to do.. than just do it.
Changing labels on buttons? Doable with :after + content. Hardly doable to generic components, but still.
Making “burger menu” from “top line” menu? Probably not a big problem, if menu has a good semantic, and is just a <UL/>.
Is there any cases when CSS-only solution will suck? Sure. Depends on your design. Designers are often affraid of so “complex” design, as long they were taught, that is it super super hard to do. Tell them — it’s time to break free!
Conclusion
- Responsible? Yes! Fluid grids rule!
- Adaptive? Yes! The best UX still requires a few changes to be different between PC and Mobile. Very different.
- Reactive? Sure! A lot of people are changing browser window size, or rotating their phones.
- Flexible? Like a water!
- Could skyrocket your site, and make it looking great? 🙀 Sure
🤘
Follow me, I am always about rethinking well known boring things, and making them awesome.
PS: But, to be honest, react-media-matched was made by my wife.’
PPS: We could discuss this article on Spectrum —
