The need for our own solution

Cookie policy. Hate it or love it, they are a necessity nowadays. As a digital product studio, setting up cookie policies - and the technicalities behind it - is part of our job. Most of the time, we make use of a third-party plugin in order to manage cookies for our clients: easy to set up and very straightforward for users. 

While the idea for building our own cookie-solution was on our radar for a while, it suddenly became a priority since the third-party decided to end support for the plugin. Eager to tackle this problem head-on, we decided to create our own solution. Say hi to Cookie Though, almost as sweet as the Ben & Jerry’s one. 

Discover the architecture behind this solution, what building blocks we used to set it up and where you can find it.  

Architectural decisions

During our brainstorms, some features for the plugin immediately popped-up on our priority list. First of all, we no longer wanted to have a dependency on a third party as we realised it could cause problems in the future. Not having a dependency on another service also meant that we were in full control of the plugin, allowing it to be lightweight, adaptable and accessible. 

Before actually building, we needed to consider the configuration of the plugin. One thing quickly became certain: the plugin would need to allow for multiple configurations, as it would open the gates for fast implementation to support translations. 

Thanks to the in-house expertise we added inclusion as a major focus during the design and development stage.

Next up, it was time to talk design. We wanted our cookie product to offer top-notch user experience, so we took it up with our designers. Eating our own dog food, accessibility should also play a major role in our design. Thanks to the in-house expertise we added inclusion as a major focus during the design and development stage.

As the last requirement, we wanted to create something that could be used by everyone. Not narrowing it down to products built by us at In The Pocket, but also making it available to everyone who’s interested. In order to achieve this, we published Cookie Though on npm & unpkg.

How we built it

The puzzle was nearly finished to kickstart development. But before getting our hands dirty, we still needed one crucial piece: setting up the project. While making the final preparations before development, some last knots needed tying together.

Preact

As mentioned before, our cookie plugin needed to be lightweight. In order to keep it as light as possible, we did a small comparison between multiple JavaScript frameworks and their bundle size. 

Looking at the bundle size, it was an easy choice for us to pick Preact as our go-to framework. The choice for Preact also meant that we were able to transfer all our knowledge from React straight to Cookie Though. Currently, the plugin is only 32kb with JavaScript and CSS combined!

One drawback of choosing Preact was its rather small ecosystem. Since Preact is a lightweight alternative to React, it doesn’t implement all the same features. So, in order to utilise open-source packages, we had to use the compatibility feature of Preact with React which doubled our bundle size. To keep the bundle size to the minimum, we only used one npm package (events) that’s built in vanilla JavaScript. Challenging, for sure, but it turned out to be worth the effort, looking at our production bundle size.

Parcel

In order to develop with Preact, we had to make use of a bundler. We opted for Parcel, as it is blazingly fast for building the application and allows hot module replacement, which cleared the path to fully focus on development.

Shadow DOM

For the plugin to be plug & play, we had to make sure the CSS of the site/app wouldn’t have a direct effect on the Cookie Though plugin. We used shadow DOM to tackle this issue. Shadow DOM allows in essence hidden DOM trees to be attached to elements in the regular DOM tree, thus encapsulating CSS within the plugin. 

To set up the render of the plugin within a site/app, we wrote this tiny piece of code:

Ensuring the plugin was configurable, we integrated CSS variables that can be fixed on the Cookie Though class.

In closing

Et voila, our Cookie Though plugin was born. After rigid testing, Cookie Though is now in use on our very own website and we’re already shipping it to some of our clients. 

By making the right architectural, design and project decisions early-on, we managed to create a simple, accessible and low-footprint plugin. And the best of all? Since the plugin is open source, it allows us and other developers to maintain it in the future. That leaves us with only one question: cookie though?

‍

You can find Cookie Though right here.