neolabs.io: Using react-static, styled-components and Netlify

von Yannik Wissner
05.02.2019

Seamlessly creating and hosting static sites powered by a static site generator, a headless CMS and a free page host.

At Neoskop, we try dipping our toes in new technologies quite often - to know our options, choose the best solution available and, of course, out of sheer interest. Outlined in this blog post is a small side project called neolabs, with which we were able to gain valuable experience working with technologies we had not or only rarely used before.

It began with the idea to present the open source creations that people here at Neoskop have created and worked on with kind of a landing page. It seemed like the perfect place to try out some technologies that had spiked our interest. Being a project mainly driven by the enthusiasm of us developers, we had complete freedom with all of the technical decisions. Although we wanted to use some state-of-the-art technologies, in the end we decided on what may just be the flavor of the month JAMStack setup. And it worked out pretty nicely.

You can check out the end result @ neolabs.io.

JAMming 🎶

We didn't think a lot about the technologies to use, but instead we dove right in with what came to our minds. Anyway, here are some thoughts about the stack we ended up with.

The Frontend

Having previously worked with React, using it for this project was kind of a no-brainer. So we evaluated the needs of the website and came to the understanding that this would be a great opportunity to try out a static site generator. Of the more popular ones, we had used Next.js before, so we instead settled on react-static. That turned out to be the right decision for a small side project like this, with pretty much zero setup hassle and / or configuration intricacies to worry about. We really just plugged in our api endpoint into the static.config.js and off we went to code the components we would need. Also, because neolabs is a one-pager, we could almost completely ignore the routing aspect of react-static.

styled-components

After reading many enthusiastic blog posts about styled-components, we, of course, had to try them as well. Although we did initially run into two problems: Starting with the basic template of react-static instead of the styled-components template meant we had to configure a thing or two by ourselves; a process that, in my opinion, could have benefited from better documentation on the side of react-static. The second problem probably had its roots in the first: We had to fight the FOUC. Fortunately by adding Server Side Rendering for the styled-components, we managed to get a hold of the Flash Of Unstyled Content effect that plagued neolabs during its initial development. In hindsight, we probably wouldn't have had to scratch our heads about that problem in the first place had we started development using the styled-components template of react-static. This way around, it gave us a nice excuse to play around with the static.config.js of react-static.

Deploying with Netlify

Setting up the deployment pipeline of this project was very effortless: For us this was the main selling point for Netlify and why we chose it (well, and because it's free to mess around with). While not giving us a whole lot of configuration options, what it gave us satisfied our needs. Also, instead of rolling a more customized CI solution and spending time configuring that, we were able to fully focus on developing the actual site. Of course, for more sophisticated projects this would not suffice. Still, adopting Continuous Delivery as a way of providing page stability and a fast development pace ensured our motivation as developers as well as a speedy development and iteration process.

Keeping up-to-date

The way Netlify works is that whenever you push to your repository, Netlify runs your pre-defined (e.g. yarn build) build task and deploys the result to production as soon as it's done. However, while the code of our static site sure enough does come from the repo, the content on it does not (although there definitely are many headless CMSes that do use Git to keep track of and distribute their content). Instead we consume the API of the CMS we chose to use to get the data we need. This meant we had to add another web hook to Netlify to initiate a rebuild whenever content changes or else we would have outdated content being served. Luckily for us, Netlify has a web hook setting for just that usecase.

We ended up with the following workflow: Adding, editing or deleting content in the CMS results in the build hook of Netlify being called, which then starts the build task during which the actual content gets fetched from the API of our CMS. Pushes to the repository would also trigger the usual rebuild of the page.

The CMS

With us currently being in the process of evaluating the headless CMSes on the market, a project like neolabs was a golden opportunity to actually try out at least one of them with a real (albeit limited in vision) use case.

In the end, our choice fell on Prismic, because... well, it seemed like a good fit at the time: There are several features that also seemed enticing for some other, bigger projects that we might want to plug Prismic in to as the data source at some time.

Of course, with neolabs being so limited in scope, we did not have an appropriate use case for most of Prismic's data model - which can be used to map much more complex data than what we needed by involving what Prismic calls 'slices'. Still, it was enough to get some first impressions what it's like working with this headless CMS.

Prismic also gives the ability to POST to a specified URL whenever content changes, which was perfect for us and our Netlify webhook integration that was mentioned in the previous chapter.

We did not have a whole lot of touching points with Prismic. All we did was create 'Singleton' content type for neolabs, filling it with the necessary strings (all content on neolabs.io, including the emojis in the headlines 😊,  is managed there), and, creating another content type for the open source tools we wanted to display. That second content type of course was a repeatable type because we wanted to be able to add as many tools as we need.

Due to Prismic offering a npm package for integrating their API in Node projects, fetching data from the API during the build process of react-static was also pretty painless.

Aftermath: What we learned 🎓 & what we think 🤔

Being free to use whatever technologies absolutely turned out to be a lot of fun - however it did also highlight a modern programmer's dilemma: Especially right at the start of the project, sitting in front of this clean slate that's waiting to be filled by us, we felt a litte of what might best be described as decision fatigue. This, of course, is tightly linked with the fact, that the vast ecosystem React offers (more than 350.000 packages on npm at the time of writing!) makes you think about the optimal choice at every corner. In the end, we settled on popular choices, because these are the ones where experience with them might actually benefit us in "real" projects. Had this been a hobby project, we might have considered some less widely-used options.

It feels like a good way to actually get web development done is not to ponder about framework choices for days and instead just picking one and then go with the flow. Although for customer projects one should err on the side of caution and use established solutions.

Flow is a good cue, because we didn't actually get to use it while working on neolabs. At Neoskop we use TypeScript for most JS projects and thus the obvious choice would have been to experiment with Flow as an alternative. However we did not start out with it in mind (we used just plain JavaScript instead). Implementing it as an afterthought might be an interesting approach to also pick up some knowledge about converting legacy JS codebases to something more modern. However, until now, we couldn't really justify spending more time on this (yet!). All in all, it seems TypeScript (and the same probably goes for Flow if you choose to go that route) should really be a first-class-citizen in projects, starting with the very first line of code.

Regarding styled-components 💅

As with most things different, using them for the first time felt weird. Writing CSS in JS is a new way of doing styles, but in the end, a lot stays the same really. We had already used single BEM-scoped SCSS files on a react component level in other projects, so, in the end, the only thing that changed was that the CSS was now in the same file as the rest of the component.

Anyway, this was rather unexciting - it didn't fundamentally change the way we write styles. Sometimes components felt more messy, because we mixed logic and presentation; of course, a fault we could solve by more strictly separating presentational ("dumb") components from higher order ("smart") components.

Wrapping up 🌯

Overall, this was a very educational experience. It gave us some leverage for deciding on technologies in the future, hopefully making those decisions easier. Also, using only technologies you choose yourself is a lot of fun - but there's also no one else to blame when things don't work!

Thanks for reading! 👏

Du bist Frontend-Entwickler*in aus Leidenschaft und hast Lust auf smarte Projekte?

Wir sind stets auf der Suche nach frischen digitalen Köpfen, die Lust haben, die perfekte User Experience zu gestalten! Neben Projekten jeglicher Größenordnung kommt bei uns natürlich auch der Spaß nicht zu kurz. Was das heißt? Hier findest du weitere überzeugende Gründe, warum Du dich auf jeden Fall bei uns bewerben solltest!

Du suchst einen interessanten Job im Bereich Web-Entwicklung? Bewirb Dich jetzt!

Bitte gib uns in Deinem Anschreiben einen Hinweis auf das frühstmögliche Eintrittsdatum und Deine Gehaltsvorstellung. Außerdem freuen wir uns immer über Projektreferenzen.

Maik Jablonski
Maik Jablonski Geschäftsführer +49 511 700 208 14