The thing is, that sometimes we do ought that our entry component would be conditioned by a device property - thus, in this regard, we need to think about another strategy. Indeed, the DOM tree remains the same so mismatches aren’t expected. We merely style the basic “layout” above according to the viewport width, nothing else. This doesn’t mean avoiding responsiveness completely - but just not making the entry component (and its child components) a device-based conditional.īasically, this strategy says that the initial render wouldn’t produce any different DOM trees for various device properties, whereas different styles (such as fontSize, margin, width, etc.) are unrestrictedly permitted: The easiest way to deal is probably to prevent from the initial render to render components conditionally based on device properties.
Let’s introduce a couple of possible strategies while examining if they meet our challenge. Well, we apparently understand now that rendering a responsive application on the server-side isn’t really trivial and raises interesting questions. The challenge becomes even more complicated. So, whatever strategy would be adopted - we still want that to be performed efficiently, because otherwise - we detract a substantial benefit of SSR. PerformanceĪs we already mentioned, one of the major benefits of SSR is allowing better performance (by preparing the markup for the client ahead of time). Put it simply - this might cause the server to render our application incorrectly, which eventually, leads to partial hydration that patches the mismatches (namely potential bugs?). How would you expect the server to render the markup without the window, and even if it’s hypothetically polyfilled somehow, what about the dimensions? How would it respond once the initial render contains a responsive component that conditionally affected by a breakpoint? This means that the device, in other words, cannot detect obligatory properties (such as the viewport dimensions of the client) - thereby it needs to infer them someway, which means, a pretty limited and non-accurate way to respond.įor instance, imagine we’ve an application that uses matchMedia (which, as you probably know, is a Web API that arrives on top of the window) to render components conditionally based on the viewport dimensions. The server doesn’t recognize the window neither document. Having said that, mixing SSR with applied responsive concepts definitely pretends to be a challenge. Responsive Design - an approach to design and implement web applications which flexibility respond (visually or behaviorally) to the device that renders them so that they keep looking well and functioning depending on the device constraints.Server-Side Rendering - a technique to render client-side applications on the server thereby returning a complete HTML markup, which was rendered in advance, to the client (in a nutshell, the major benefits are better SEO and performance).In order to deeply understand the challenge, we should be familiar at first with the following terms: Note: We’re going to use React mainly to describe the problem comfortably and to demonstrate simply the ideas hiding beneath the possible strategies. This article will specifically focus on the challenge that might arise when implementing an application that’s rendered by the server-side, but on the other hand, needs to behave responsively on different platforms.
Sometimes, however, it’s not so straightforward to mix them together, both for technical and conceptual aspects.
Integrating React’s ecosystem, for instance, with the available Web APIs - allows us to make a fully-responsive application that’s also discoverable and well-performed. In order to make it happen, these applications tend to implement principles of discoverability, progressiveness, responsiveness and so on.Įven though that PWAs aren’t based on a specific technology, but merely an approach with principles to build web applications - they involve technical ecosystems, Web APIs and practices. It’s not a surprise, especially when applications like these are expected to have cross-platform support and actually to function everywhere.
Progressive web applications (PWA) are being developed more and more for the last few years.