Building responsive applications is a norm. It’s not so much of a complicated thing to do when working on Single Page Applications (SPA) with React. The reason for this is simple: declarative style programming can enable us selectively display contents on the browser since there is the
window object. We can determine the size of the browser’s window and choose the components to show to our users – or even the style to use on a component. The situation changes drastically when we want to render on the server. What does this mean?
The task becomes tedious when we want to server-render content and be selective with what we render based on screen size. There’s just no DOM; no
window object either. Thanks to Next.js our pains are washed away – at least to some extent. We can worry no more about how to render and send html responses to our clients-side. NextJS can help us do static generation and server-side rendering. Please see here to learn more.
However, using NextJS doesn’t mean we automatically have a
window object on our server. For this reason, we need to figure out how to render contents responsively. There’s the React’s Semantic-UI package to help us with responsiveness on the server. It’s easy to plug into Next.js, but it’s not so obvious. I have put together a succinct boilerplate that handles this and added some other packages often needed for development in Next.js. Find here on github.
The rest of this article breaks down the structure of the boilerplate and attempts to clarify any possible confusion that might arise. Keep in mind that this is not a framework or library. It’s just a boilerplate – nothing more.
STRUCTURE (inline with Next.Js)
This is the folder representation:
The most important folders here are:
static . While the
static folder is required by
Next.js as stated here, the behaviour for the
pages folder can be configured to suit your needs. See here.
utils folder comprises of
constants folder. The
/utils/component folder is intended to house components that will be useful to the whole application. For example,
footer or even the
layout as seen in the boilerplate. Once again, this is just semantics. It can be changed to suit your needs.
Let’s pay some attention to the
/utils/components/mediaquery folder. Here you’ll find
semantics.js . The vitality of the
MediaQuery component exported from this file cannot be overstated. Anytime you need to render a component uniquely to a type of screen, pass the
type as props to
/components/home.js for example implementation. All types are constants from
/redux folder is for all things
redux. See here to learn how you can start using
/components folder is where components related to individual pages are kept. For example,
/components/home.js serves only the home page through
If you will need to edit
_document.js, please do so with caution. Global props are generated here and passed to the
App component in
Next.js. Understand that if you edit
_app.js and remove the
<WindowsContext.Provider> then the
semantics.js will not work.
You can edit the files in the
redux folder as you deem fit. Only ensure, however, that you supply the store to the
<Provider> declared in
All you need is an understanding of Next.js and React. With these, you’re good to use the boilerplate as you deem fit. It’s a good way to bootstrap and save time when you want to build a responsive SSR application.
Please submit a PR, if you feel there are dependencies that should be added to make the boilerplate more robust.