Overcoming Challenges through Modern Technologies

Sam North
FiscalNoteworthy
Published in
5 min readJan 9, 2023

In Part 2 of this series, we’ll highlight the technical challenges we faced and how we utilized different modern technologies to overcome them. We’ll discuss these technologies to demonstrate how they solved our particular problems — and we’ll cover other beneficial features these pieces of tech contain. We covered LaunchDarkly and feature flagging in Part 1.

Backstory (Recap):

In 2021 we renovated the user interface (UI) of our web applications for VoterVoice, a FiscalNote product. This was not a small task as we have numerous applications across several different technologies. Our design team had already laid the groundwork for designs, icons, states, color palettes, and such; and we began planning how to overcome two major challenges.

First, we needed the ability to simultaneously support the existing UI as well as the new UI and switch back and forth at runtime.

Covered in Part 1 of this series.

The next challenge involved our navigation menu included in the redesign. It was replicated and reused across multiple applications for a seamless transition between applications — but produced a maintenance headache. Any time a change needed to be made to the navigation menu, the developer had to remember to make the change in all locations where this menu was coded. Relying on memory or awareness isn’t exactly setting up the best future for the codebase. We’ll cover a chunk of this challenge in this piece, but there’s still more to come in Part 3.

Challenge: New UI, refactor and unify some duplicated code across applications. Enter web components and Tailwind CSS.

“The navigation menu is currently replicated and reused across multiple applications for a seamless transition between applications but produced a maintenance headache.”

Our second challenge proved more difficult but was solved with the use of modern technologies. In order to tackle refactoring and unifying duplicated code into one place while still being used across multiple web technologies, we landed on web components.

Web components aren’t new, but have recently gained traction in a community much slower than other available front-end options. Web components would allow us to develop a component once and reuse it across as many applications and technologies as needed — significantly improving our development maintenance process.

Finally, another bonus born from the web components pivot related to our ability to integrate the last bit of new technology, Tailwind CSS, at the same time within the same new build process. WHOA! Let’s not get ahead of ourselves yet though — Tailwind CSS awaits you in Part 3 of this series. Back to web components . . .

Web Components

“Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps.” — MDN

Sounds great, right? Why isn’t everybody using them? Well like everything in life, there are pros and cons. If you’re like us, your journey into web components may have taken several quick prototype attempts and discussions splitting hairs regarding the benefits and trade-offs for your specific team. Through all of the trials and a collaborative decision, we settled on using a toolset consisting of Lit, Storybook, and Vite. Lit is the development library for the web components themselves. Storybook is what we use for rapid development, testing, demoing, and documenting of the web components in their own isolated environment outside of our business domain. Lastly, Vite is handling the lightning-fast build process. Research Storybook and Vite on your own — they’re both great products that can be used outside of web components. We’ll keep our scope to just Lit and web components from here on out, however.

Lit

Lit.dev touts the same general features as any other library for making web components. It’s simple, fast, and lightweight exactly as it claims; the community backing and growth of the library was a point that our team felt was stable. Lastly — and probably most importantly — the syntax and workflow resonated with our development team. Below is an example of one of our team’s custom card web components: vv-card.

import { html, customElement, LitElement } from 'lit-element';
import { VvElement } from '../../elements/vv-element';

@customElement('vv-card')
export class VvCard extends LitElement {
static styles = [VvElement.styles];
render() {
return html`
<article class="flex flex-col flex-1 bg-white shadow-md rounded overflow-y-hidden">
<slot></slot>
</article>
`
}
}

Above is the code for the component itself. Beneath, you’ll observe how we put it to use in a simple HTML file. By adding the script tag for loading our vv-components.umd.js file, it allows us to use <vv-card> as if it is any other ordinary HTML element.

<!DOCTYPE html>
<html>

<head>
<title>Test App</title>
<link rel="stylesheet" href="vv-components.style.css">
</head>
<body>
<vv-card>
<h1>Hello World</h1>
</vv-card>
<script src="vv-components.umd.js"></script>
</body>
</html>

That’s it: launch in the preferred web browser of your choice and you will see the component rendered just like any other component. Pretty nifty!

When it comes to the advantages and disadvantages of Lit itself, I think it is best left for the team to decide. In my experience, all of the competing libraries and frameworks will contain the necessary features to develop most applications. Try out the various frameworks and choose the one that resonates with your team the most. Adding web components to our arsenal has really helped with reusability, and accessibility, and has also sped up some of our development time due to the newer and faster tooling.

Conclusion

Deciding to switch development over to web components was a great choice and has been a treat for the entire development team. We have at least four different web technologies we’ve accumulated over the years and have implemented our freshly developed and reusable web components during every one of them. They work well and helped us unify development in one location — and reuse in many. If you have some tech debt and are in search of a way to simplify development work, web components is a solution worth exploring.

Thank you for reading — the next and final installment of this series is coming soon. We will discuss the features of Tailwind CSS and how it pushed our team across the finish line to ultimately accomplish our goals.

Visit FiscalNote’s technical blog: F(N)novate

--

--

Sam North
FiscalNoteworthy

VoterVoice Senior Software Engineer at FiscalNote