The need for our own solution
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.
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.
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.
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.
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.