Website Design Trends for Dyslexia and ADHD
Nov 06, 2023 • 6 Minute Read • Chris Anthony, Creative Director
See All Our Insights
The Evolution to Storybook for Front-end Development
Apr 08, 2022 • 6 Minute Read • Joe Fusco, Technical Director, Front End
One of the most challenging things about website front-end development is choosing a technology or a tool to help with delivery, internal efficiency and client satisfaction. There's a lot to balance and test to make sure we have a solid solution that's agnostic of the backend technology being used, as well as the context of the project. It's certainly been a journey and continues to be one as we improve our front-end stack. I believe what sets Verndale apart from other front-end groups that I've been a part of is our passion to never fall behind in our technology stack, and our outright refusal to accept that we need to slow down in our evolution.
Our goal is simple - provide static assets for the backend to implement. No matter what the backend stack is, they should have an easy way to grab our compiled HTML, CSS and JS to integrate to their solution. There are tools out there to help us with this: user interfaces that organize your components, modules and templates. As an organization that may be working with Verndale or looking to learn from our experience, it's important to understand our evolution and how we got to where we are with our building process and bundling stack.
The ultimate goal for us is automation. We try to remove the "human" in any way we can in our process of delivering assets, documentation, and testing. One of the ways we have accomplished this is choosing the right bundling tools and continuous integration tasks.
Before I get into the tools we have used previously and currently use today, I will say that our front-end code is in a separate repository than our backend code. We do this for a number of reasons. We treat front-end code as a product that we deliver to the backend using semantic versioning and automated changelogs. This makes what's being delivered in a particular build very clear and easy to create release branches. This gives us the ability to separate our solutions and develop faster. We are basically creating static sites and delivering production ready assets to the backend team.
Grunt
We got here from an organic evolution of the most popular front-end build tools. In the beginning, there was Grunt. We implemented Grunt and Webpack together to run a simple, local dev server to develop our static site. Grunt is simple to use - it's a bunch of plug-ins and configurations. When the backend needed to implement a new module, we would have to manually run a build command to compile our assets and deliver a distribution folder, which the backend would have to dig into to find specific HTML. This accomplished what we wanted at the time, but as the tech became smarter, we did too.
Gulp
When Grunt went out of style, we chose to move our tooling to Gulp. With Gulp we were really happy. Our solution compiled almost two times faster, we were able to run tasks async or in parallel to improve our development speed. Gulp was much better. We weren't just doing configurations with plugins. Gulp allowed us to write JavaScript tasks, giving us so much more flexibility and the ability to customize our build tools further. Gulp with Webpack worked for us for years and still does. It's super powerful. We had all of our build tasks in Gulp except for the JavaScript compilation. We had Webpack handle the JavaScript compilation, chunking/bundling and hashing. There were a couple of problems though...We were still having to run our build task manually and push to our repository. We were still responsible for organizing our components, modules and templates manually, essentially creating our own UI that just showed templates. This is challenging for backend because they have to go into the template HTML and dig out the module or component they need to make their rendering. This is where Storybook comes in.
Storybook
We didn't jump straight to Storybook - we experimented with Fractal first. Fractal is similar to Storybook in that it gives us the ability to develop and deliver renderings in an organized manner, as well as gives us documentation. Fractal works great for reusable component creation out-of-the-box. We ultimately went with Storybook because it just works better for us with the modules we were creating. Storybook also works better out-of-the-box with our current tooling, so we're able to integrate with it more easily. Although some aspects of our applications are reusable, and for that Fractal still plays a role, many of the applications require creating complex and custom modules per client. So Storybook wins this one.
Storybook is a tool that we have adopted and tweaked to make our own special mixture that works best for us. It makes development faster and easier by isolating components. We have taken Storybook and incorporated our own tooling within it such as linters, Webpack middleware, image minification and svg sheet creation - to name a few. We've also been able to get rid of the dependency on Gulp to run our non-related JavaScript tasks. This, ultimately, allows us to work on one component at a time. We can develop entire UIs without needing to start up a complex dev stack, force certain data into our database, or navigate around our application. Storybook is very visual and very robust at a UI level, meaning that anyone can change any field that is configured on the fly. You might want to test a really long title or the style of a secondary button. This is all possible and easy to configure in Storybook. These are called "stories." A story captures the rendered state of a UI component. We write multiple stories per component that describe all the states a component can support per our own functional specifications. The way we develop is that we create our component, module or template in our HTML folder structure.
When we're happy with the way it looks, we create a story out of it that renders it in Storybook. We have a "stories" folder in which we keep all our stories. We follow a simple interface to create a story and add some editable fields to it. This is an example of a simple input component. We've exposed some editable fields in the "argTypes" object. The end user of Storybook will be able to change these fields on the fly and see the changes in the input field immediately.
We also expose editable fields and parts of our modules so that anyone can play with it and test it in any way they want.
Storybook organizes these components and modules in folders if there are different types. This gives us separation of concern. CMS content authors are able to build their pages like Legos, so this is a very appropriate way to visualize these renderings.
Storybook is self-documenting out-of-the-box. One of the most valuable features of Storybook is the backend developer will click "show code" on the right and it will give them a small snippet to paste into their solution and their renderings - no more digging around the compiled HTML template. We also make fields editable that will change the properties (eg: for the button in this screenshot). This allows the front-end, backend and QA to "mess" with the module and test it with different properties applied. We're an all-inclusive company when it comes to development, which means we consistently create experiences that are AA-compliant. Storybook gives us a way to quickly test accessibility per module. We can easily see the passed tests and the violations.
We host the Storybook instance in Azure Storage to allow our internal team to navigate the work via a URL. We also have build and release pipelines enabling us to run our build manually, run through our linters, upload compiled files to Azure Storage, and push everything back to our repo. There is no more manual process for handing assets to the backend team. We simply push to our develop branch and a build and release build gets triggered.
We're always looking for ways to improve our build process and our tooling. Switching to Storybook, getting rid of Gulp, and adding continuous integration are huge steps towards our technological goal in our front-end department. You can count on us to always be looking for ways to evolve. When it comes down to it, we're striving to make huge moves to improve our efficiency, which will give us more time to focus on our quality and ensuring our clients are happy with their experience. If you'd like to learn more about our process, or if this makes you as excited about the future of development as it does for us, reach out and let's talk.