Chad R. StewartIntroduction
I’ve been a Front-End Engineer for several years now and have built a wide range of components for a variety of projects. In these various projects, I used different tooling to build components ranging from just having raw HTML, CSS and JavaScript to more modern tooling like React.js and the overall JavaScript ecosystem. Despite this, my development experience remained relatively the same while what mainly grew was the complexity of what I could build. That was until I built onboarding experiences for two different projects in the same year.
Here’s how tooling vastly changed my development experience and velocity.
Building the app.opensauced.pizza onboarding experience
For the first project’s onboarding experience, I was tasked to build something to replace the previous onboarding. The previous experience felt more disjointed and it was very easy for users to get lost and so another experience was designed and given to me to implement. A lot of the work was developing around the original page as I needed to insert the new experience into the previous page. The hardest part of delivering this project was working with the styling because of how the component was built initially and the general structure of the project. Styles were not packaged together with components and so understanding which style went with which component and adding new styles took a bit of time. It took me a few days and most of the time I spent wrestling with the CSS to get things just right.
Tools used for app.opensauced.pizza project:
Styled Components:
CSS was written in Styled Components. CSS can be tricky to work with including Styled Components because CSS tends to be written in a separate file than the markup you intend to use it in. This increases the cognitive load on the developer by forcing them to understand which CSS rules are applied to which component. If you were writing raw CSS then selecting the correct HTML element would be required and can also be painful but Styled Components allowed us to create the component with the Styles and just leverage it directly so we don’t have to deal with that.
React.js:
Want to note that this is a React 17 project. This doesn’t affect the experience directly as the other project I describe also leverages React 17, I wanted to bring this up for full transparency.
My overall experience working on app.opensauced.pizza:
This wasn’t that bad of an experience at all, just a standard Front-End development experience. The biggest difficulty was working with the CSS, using Styled Components and the locations of the styling. Outside of that, I’d say the experience was okay but uneventful.
Building the OpenSauced Insights Platform onboarding experience
For the second project, I was building an onboarding feature for a much more greenfield project. In this case, I was implementing an onboarding feature which was brand-new and was independent of any other design for the rest of the project so I had to spin up a new page to build it and so I got to work. Started a new page and quickly got to work styling the page. The interesting part of this onboarding experience was that the page was split into two where one half would track your progress in onboarding and the other half would change based on which step you were on. I remember starting the page at around 12 pm and working through it, quickly solving any problem that came up and progressing. A few hours later the page was completed. A few more hours of tweaking brought the total dev time to around 6 hours.
Tools used for OpenSauced Insights Platform project:
Component-Driven Design:
For this project we practiced Component-Driven Design. A quick synopsis would be that instead of building a page from top-level down, we build the components that make up the page first and then put them together like Legos. Component-Driven Design is best paired with a Design System that gives you a selection of components that you can use to put together pages quickly and make changes quickly.
Atomic Design Design System
To effectively leverage Component-Driven Design, we used the Atomic Design Design System to break up our components into atoms, molecules and organisms allowing us to get the Lego-feel of building components and ultimately assembling pages brick by brick.
Storybook:
To document our design system, we leverage Storybook in our project. This allows us to quickly look at what is available in our design system, assess what we need and put together components and ultimately pages quickly and easily. What we also do with Storybook is that the Storybook environment allows us to build components in isolation. Using Storybook, we can build components without interfering with the rest of the project and potentially introduce bugs or issues. Once we are confident in our components, we place them on the page where we need them and add the necessary data to power them.
Tailwind CSS:
Tailwind CSS makes styling a page quick and easy. Just apply the css class that you need and Tailwind classes will take care of the rest. Another key part of the benefit of Tailwind CSS is that it keeps your css isolated in the component that relies on it. This relieves one of the biggest pain points of CSS, accurately selecting and styling ONLY the classes YOU WANT. This is especially handy when you are building components in isolation in Storybook and having confidence your CSS won’t mess with the rest of the project once implemented.
TypeScript:
TypeScript and the intellisense that it gives through the proper use of types is probably the most valuable tools a developer could have when building a project with a very established design system. If a component is properly built, the component effectively documents itself and (depending on your IDE of choice) presents that documentation at the most crucial part of development, when you are actually implementing the component. This saves hours of development time in making sure you’re using the component correctly and reducing errors in implementation before it can get to production.
Next.js:
Our project is built with Next.js, which allows us to put together a Single-Page application quickly with all the tooling needed to make that application functional. While this has been invaluable in building the overall project quickly, it wasn’t a direct benefit in building this particular feature. For full transparency, our Next project leveraged React 17.
My overall experience working on the Insights Platform:
This was a far better Front-End development experience, from the time it took for me to complete this to its readability and maintainability. While this was a far more complex onboarding experience, the amount of code to make it work was comparable. It was 100 more lines of code than the previous experience but it was to build a completely new web page from scratch! Unlike the previous experience, styling wasn’t a pain point at all and honestly, I can’t think of any real pain points on this project. Probably the reason why I flew through it so quickly
Conclusion:
Overall, I love the dev experience with working with the tooling I am working with currently. I do feel I should bring up some caveats that I didn’t not cover in this post. While the new code I wrote was 100 more lines of code than my previous project, there was a lot more knowledge and infrastructure being brought to bear to complete this task that existed previously. Setting up that infrastructure and then getting used to that workflow takes time but let this story be an example of what you can accomplish and how quickly you can accomplish it with the right tools in place.
