DEV Community: Patryk Staniewski

You might not need your own UI library.

Patryk Staniewski — Fri, 22 Oct 2021 16:04:28 +0000

Preface

Over the years, I came across a lot of different projects with diverse backgrounds and goals. From small, or even tiny in size and scope, to large monolithic applications with multiple frameworks and few layers of legacy code.
The vast majority of them had one key thing in common - they all had their own, custom library of UI components and various utils.

I will try to describe my experiences and propose alternatives using popular libraries and frameworks. I’ll try my best to describe the benefits and drawbacks of each scenario.

Startup - low cost, high ambitions.

When I joined this startup, let’s call it Guava to not use the real name, they were in the middle of launching their product to mobile (previously the application was only available for desktop users). It was supposed to replace their legacy app and was, for all the shapes and purposes, a real RWD. In the meantime, they had another website up and running - classical landing pages with homepage, about us, contact, and so on. They didn’t share a single line of code between them even tho they looked alike.

One of my responsibilities was creating a UI library. That way we could share and reuse the same components across both projects. We started with the design team. They prepared a style guide and described colors, buttons, inputs, etc. We discussed the details and created our own, beautiful and custom-made guava-core. It had a building blocks and some helpful utilities that could be used in all of our current and future projects.

Unfortunately, what I didn’t consider back then was the cost of developing this library. We spent few weeks discussing our APIs, another for initial implementation, another for polishing, and another for integration.

When new features came, they all were first added to our style guide. Some new variants for inputs here, a different hover state over there, a little icon in some of the buttons that weren’t used previously. We didn't want to simply add another set of properties to our components without a really good reason. We asked for a meeting to discuss these differences, sorted them out, but it took another few hours of our time that could be used elsewhere. And, we still needed to code new functionalities.

Our developer experience and user experience were good, great even. Our library had an elegant, extendable API that we based on Styled System. This doesn’t change the fact that we had to bid farewell to some of our team members, partially because of the rising costs of implementing new features, which increased a time-to-ship.

// Our custom fontScale prop
import { BoxProps } from '../Reflexbox';
import { system } from 'styled-system';

const transformFontScale = (props: BoxProps) => (value: any, scale: any) => {
  const { fontSize, lineHeight } = scale[value];
  const fonts = props.theme?.fonts ?? 'sans-serif';
  return `${fontSize} / ${lineHeight} ${fonts[0]}`;
};
export const fontScale = (props: BoxProps) =>
  system({
    fontScale: {
      scale: 'fontScales',
      property: 'font',
      transform: transformFontScale(props),
    },
  });

// <Box fontScale={[2, 4]} />

Most of our components were kept small and by using atomic design we were able to extend them when needed.

Looking back however, I would definitely go for Material UI as the designs were loosely based on material design and with some compromises in both design world and from development standpoint, we could create more features faster and at a fraction of a cost, even with half the team we had.

Small company - design flexibility and development speed.

Development of this project started without a dedicated UI team. We had a rough idea of how it’s going to look like based on descriptions and small sketches of our creative director. We wanted to focus on developing core functionalities like sign-in & login, managing users, creating content, and so on. To speed things up, we decided to use Base Web (well, we started from material-ui, but we didn’t like its approach to styling back then).

Implementing our views was trivial, each component is heavily tested, both through e2e and unit tests. It has thorough documentation with lots of examples.

Sometimes later, the design came from a dedicated design studio. They were… let’s just say a lot, different than what we had in baseweb and they came a few weeks later than they supposed to. Because of that, we had a shorter time to adjust our frontend so we had to improvise.

As it turned out, extending baseweb was rather easy, because of its theming and overrides API. In our theme file, we defined the correct colors and customized some global overrides.

export const theme = createTheme(primitives, {
  colors: {
    inputBorder: primitives.primary100,
    inputPlaceholder: primitives.primary300,
    inputPlaceholderDisabled: primitives.primary100,
    tickFillSelected: primitives.primary500,
    tickFillSelectedHover: primitives.primary600,
    tickFillSelectedHoverActive: primitives.primary700,
    buttonPrimaryFill: accents.accent,
    buttonPrimaryHover: accents.accent300,
    buttonPrimaryActive: accents.accent200,
  },
  borders: {
    buttonBorderRadius: '4px',
    inputBorderRadius: '4px',
    surfaceBorderRadius: '4px',
    popoverBorderRadius: '4px',
  },
});

We also created ui catalog in our project and made reexports from baseui/* to ui/*. That allowed us to then make overrides per component without changing its API or modifying its import path, for example, our extended tooltip looked like this:

import React, { FC } from 'react';
import { StatefulTooltip as BaseStatefulTooltip, StatefulTooltipProps } from 'baseui/tooltip';
import { mergeOverrides } from 'baseui/helpers/overrides';

export * from 'baseui/tooltip';

const statefulTooltipOverrides = {
  Body: {
    style: { maxWidth: '280px' },
  },
  Inner: {
    style: { fontWeight: 700 },
  },
};

export const StatefulTooltip: FC<StatefulTooltipProps> = ({ overrides, ...props }) => {
  return <BaseStatefulTooltip overrides={mergeOverrides(statefulTooltipOverrides, overrides)} {...props} />;
};

We couldn’t however, override some styles globally, without extending each component separately, like border-width or font-weight for labels.
We decided that it would be more beneficial for us based on our team size (2 frontends and one full-stack) to create manual overwrites in one global CSS file.

/* --------- BASE WEB OVERRIDES -------------------- */
  [data-baseweb],
  [data-baseweb="checkbox"] > [role="checkbox"],
  [data-baseweb="select"] > div {
    border-top-width: 1px;
    border-bottom-width: 1px;
    border-left-width: 1px;
    border-right-width: 1px;
  }

  [data-baseweb="form-control-label"] {
    font-weight: 400 !important;
  }

  [data-baseweb^="typo-heading"],
  [data-baseweb^="typo-label"] {
    color: ${baseTheme.colors.primary700};
  }

Yes, it’s a little bit nasty, but it’s really easy to investigate when something is being overwritten by this code in dev tools, is contained in one, tiny CSS file, and well... works like a charm.

We had a few situations, we couldn’t easily overwrite some of the design decisions. We reached out to our designers, and they were happy to help. We changed our UI just enough to not create custom components or large overrides to avoid maintenance costs and potential bugs.

The project was launched successfully and is being used by people worldwide, our codebase is tiny compared to what is happening under the hood in baseweb, is easy to test, and cheap to maintain.

Large corporation - everything custom-tailored to the product.

In larger companies, there is a strong tendency to do everything made in-house. The success of their UI libraries differs from company to company.

In some of my projects, we had a dedicated team responsible for creation and maintenance. In both of them, designs are created based on the core style guide, developers create new features using provided components. In case of missing an element or design not matching used components, a developer makes a request for changes in the library and waits. This workflow, even though it has some clear limitations and disadvantages, works well in really large projects, where the time to develop new features is a lot longer.

Other times, companies don’t see major value in these teams or are trying to reduce the costs of their IT departments. This is a long-term nightmare to maintain, as a large number of developers make changes and add components that will be used in their (sometimes very specific) use case without having a larger scope in mind. In this scenario, the codebase is getting ever larger without possible reductions insight without a huge amount of meetings and coordination between different teams. This is one of the major factors in having “legacy projects” and rewrites over time.

const ResetButton = styled(ButtonNoBackground)`
  display: flex;
  position: absolute;
  top: 0;
  right: 0;
  cursor: pointer;
  min-height: 48px;
  min-width: 48px;
`;

In both cases, however, maintenance cost is really, really high. When a company chooses to pay for a dedicated team, they have to bear in mind a developer’s increasingly high salaries. Alternatively, when moving maintenance to individual developers ad-hoc, payment is made through a longer development time.

Closing thoughts

In my opinion, companies overvalue custom-tailored solutions and gloss over existing libraries based on hypothetical problems that might come in the future.
Oftentimes, increased pace to mark a product as “legacy” and rewrites every few years are not mentioned in initial meetings. Each of us wants to create the best possible product that will last forever, but that is not the case, especially in the javascript world. New features, frameworks, libraries, and patterns come almost weekly and we all want to work in the latest stacks.

Journey to Svelte (through Gatsby)

Patryk Staniewski — Thu, 23 Sep 2021 06:41:44 +0000

Our journey began with… Gatsby, but let’s start from the beginning.

We received designs from our UI team, project manager created stories for a new project - a promo site for a new product - and we started discussing technologies. We’ve decided to go the safest route and went for Gatsby - React static site generator. It gives a lot - image optimizations, themes, plugins, GraphQL API, you name it.

We have created our atomic components, made a static homepage, and connected it to our API. Next, we’ve added the rest of the pages, such as various policies and user agreements, about us, pricing, and so on.
After that, there was a design and QA review, and they reported their feedback. We’ve made fixes, adjusted our tests, and voilà, a website was born. Slowly we’ve been adding small, simple features while polishing our actual product - a collaborative content studio platform that empowers PR & IR professionals.

And then one day, almost a year later, our planning session started. New business stories were presented - we were to add "News Hub" which would be a list of articles that we can click through with search, filters, and paginations, and a single article view with an ability to share articles on social media. Nothing extraordinary but as with almost all related sites, it had to be prerendered to have a satisfactory SEO experience. Since we didn’t know about it at the beginning, we didn’t prepare our stack accordingly hence we needed to figure out how to achieve server-side rendering in Gatsby.

It was a real brick wall. Even if we were to compromise SEO, we weren’t able to make dynamic metatags that are needed for social media, such as title, description, og:image, og:url and so on that are needed before our JS could finish rendering the page.

Finally, after few days of fighting with it, we decided we need to look for another way to avoid the Sunk Cost Fallacy. We went to the drawing board and discussed our options. The most obvious one was NextJS which is another React framework, but what differentiates it from Gatsby is that it can handle both SSR and SSG. We spent a few hours replacing configuration files, moving files around, and renaming our environmental variables. The site was up and running on our develop tier, but after running performance tests, we found out that it was a lot worse than before.

We understood that more changes were needed to match standard NextJS performance that usually reaches upwards of 80 in LH. But how many changes? How much time would we need? These were difficult questions to answer at that time and frankly, we weren’t exactly looking forward to profiling individual components to increase our score.

By that time, we had some troubles with virtual dom itself in our custom rich text editor that we based on slate - it was getting a bit laggy when creating huge financial documents (they usually have enormous tables and a lot of infographics) -so we were already thinking about other options and that’s where svelte comes into the light - especially sapper which was de facto default framework to be used with svelte at that time (SvelteKit wasn’t even announced).

We didn’t have any plans for that weekend anyway so we decided to try it out in our own free time, because well, why not. It turned out to be a lot easier than we were expecting (although not as trivial as one would hope).

First of all, we started by creating a separate branch and run rm -rf *. After a few commands and we were greeted by a sapper page.

npx degit "sveltejs/sapper-template#webpack" .
npm install
npm run dev

We got familiar with folder structure and get to work.

Our components in React were based on Styled System, which we had huge success with previously. It let us quickly build components with responsive styles based on scales defined in our theme object. Under the hood, it uses Emotion to create dynamic styles on page creation.

Our components looked something like this:

export const ContentHeader: FC = ({ children }) => (
  <Flex
    sx={{
      alignItems: 'center',
      justifyContent: 'center',
      mb: [3, 4],
      bg: 'secondary',
      color: 'white',
    }}
  >
    <Text as="h1" sx={{ fontSize: [5, 6] }}>
      {children}
    </Text>
  </Flex>
)

Although Svelte supports CSS-in-JS and we could theoretically make it work, we thought it would be better to keep it simple. We added one of the most popular CSS framework to our setup Tailwind CSS, adjusted tailwind.config.js according to our previous theme, and started converting our components.

<div class="flex items-center justify-center mb-4 text-white bg-secondary lg:md-8">
  <h1 class="text-3xl lg:text-5xl">
    <slot />
  </h1>
</div>

49% fewer characters were used to create the same component (even better than Rich has promised us in Write less code). But maybe it works great for simple, presentational components. What about more advanced examples like components with custom hooks and refs?

// REACT

export const useClickOutside = (ref: RefObject<HTMLElement>, callback: (node: HTMLElement) => void) => {
  useEffect(
    () => {
      const listener = (event: MouseEvent) => {
        if (!ref.current || ref.current.contains(event.target)) {
          return;
        }
        callback(event);
      };

      document.addEventListener("click", listener, true);

      return () => {
        document.removeEventListener("click", listener, true);
      };
    },
    [ref, callback]
  );
}

// Usage
const ref = useRef<HTMLElement>(null);
useOnClickOutside(ref, () => {})

return {
  <div ref={ref} data-testid="dropdown" />
}

// SVELTE

export const useClickOutside = (node: HTMLElement, callback: (event: MouseEvent) => void) => {
  const listener = (event: MouseEvent) => {
    if (node && !node.contains(event.target) && !event.defaultPrevented) {
      callback(event);
    }
  };

  document.addEventListener("click", listener, true);

  return {
    destroy() {
      document.removeEventListener("click", listener, true);
    },
  };
};

// Usage
<div use:useClickOutside data-testid="dropdown" />

Another win for Svelte, this time by around 35%. The pattern continued with all of our components, hooks, and pages. Our codebase shrunk by just a shy of 45% characters, was easier to read and maintain.

It took the two of us about 20 hours to complete the rewrite. We’ve made the finishing touches on Monday and ran our tests again on develop tier.

Performance on our develop tier matched our production which has additional optimizations like CDN and caching.

We presented our results, send the project to our QA team for another session, and in less than our two-week sprint - our website was redeployed and ready to add additional pages and functionalities - ready for SSR-ed articles for the world to see.

Vertical teams at scale a.k.a how to scale frontend work in growing organisation

Patryk Staniewski — Wed, 22 Sep 2021 08:59:03 +0000

What we were trying to achieve?

We want to scale our work between multiple independent teams each with its product owner, designer, and multiple engineers. To do that we have a few solutions that we’ll discuss and I’ll try to explain our logic behind making our final decision.

What are our options?

Separate applications with a host.

Creating independent applications that would live in separate repositories is one of the most popular way of building frontend. Each team has its own technologies, tools, and buildchain which some of them really value. There is unfortunately one hefty problem - versioning. In this setup, after making a change in our application we would have to update version in package registry and then bump version inside our “host application”. And then there is our UI library that each app is using.

Monorepo to the rescue?

Our current application is a monorepo, rather large monorepo.
At the time of writing this article, we have 19290 files with 3580303 lines of code with 89 authors in the last few months.
To create new applications we don’t have to think about build configurations. Linters, unit tests, e2e tests are all already set up and ready for development. It’s as simple as adding a new directory and path to our app routing. It comes at a cost of being forced to use specific technologies and tools. Changing them would need to be approved and developed by each individual team and it’s a nightmare to coordinate.
Additionally, our pipeline’s duration is already ranging between tiresome and infinite (our last worked for 52 minutes). Merge requests are happening on average every hour so we have a constant stream of workers…ehm…working.
Unfortunately, deployment is shared across all teams so even the smallest of changes needs to be verified through multiple people in code review and needs to pass our pipelines two times (one before making a merge and one after on master branch).

Microfrontend to the rescue?

A microfrontend is a microservice that exists within a browser. Each microfrontend has its own repository, its own build configuration and process, and is being able to be deployed individually. There is a lot of implementation of this concept. One of the most popular tool that helps is single-spa - a framework for bringing together multiple JavaScript microfrontends in a frontend application. It is an incredible tool and should be considered for greenfield projects. It gives a lot of tools and features, such as being able to use different frameworks in the same application.

These additional features however would mean increased initial payload and memory allocation. Although performance overhead is minor, when we don’t use these additional functionalities it’s a waste of resources, especially when setting up single-spa would be costly to implement in our existing setup.

Module federation to the rescue?

Finally, we decided to integrate new applications using Webpack’s latest feature - module federation. It integrates nicely with our webpack configuration, has a tiny boilerplate, and is straightforward to read (after understanding the complexity of webpack itself).

Multiple separate builds should form a single application. These separate builds should not have dependencies between each other, so they can be developed and deployed individually. - Webpack team

We distinguish between local and remote modules. Local modules are normal modules that are part of the current application. Remote modules are modules that are being loaded at the runtime.

The idea is simple. An application references a remote using a configured name that is not known at compile time. That reference is only resolved at runtime by the so-called remote entry point. It’s a minimal script that provides actual external.

In its simplest form, the code looks like this:

// webpack.config.js
module.exports = {
  ...
    plugins: [
        new ModuleFederationPlugin({
            name: 'mother',
            remotes: {
                "remote": "remote@http://localhost:3001/remoteEntry.js"
            },
        }),
    ]
}

// src/index.js
import RemoteApp from 'remote/App'

Our remote application will be imported from an external URL instead of our local repository and loaded at runtime.

What we gained by adopting microservice architecture?

Microfrontend gave us a lot of benefits and resolved a lot of issues we had. We’ll walk through in a bit more details.

Independent teams - independent applications

Our vertical teams can work on their own in separate repositories and are free to choose the technologies they need to create the best user experience.

Autonomous deployments

Our team can now deploy features without being dependent on the mother app. We were able to set up our pipelines that on average last about 8 minutes.

Code trimming

We are not adding additional code to the already humongous codebase of our monorepo.

Onboarding new people

Onboarding can be overwhelming for new developers, especially juniors that join our teams. We eased the process and new friends were able to contribute even on their first day with confidence.

Developer experience

It’s often overlooked, but developer experience is crucial for every successful project. Because we created a new project and were independent of our monorepo application, we were able to integrate Snowpack into our day-to-day work. It gave us instant startup time with a fast refresh and cleaner configuration.

What problems we've encountered?

On a road to production, we had a few blockades that none of us had met before. We had to be a little bit more creative.

Singleton libraries

In libraries such as React, we cannot run multiple versions of the same library at once if they don’t share the same version. We updated to the latest version in both applications which was a lengthy process. After that, we added our react library to shared dependencies in Wepback configuration.

new ModuleFederationPlugin({
    shared: {
        "react": { singleton: true }
    }
})

Preview environment

Our monorepo is using preview deployments to be able to test changes both manually and using e2e tests. By using module federation, we are not creating branches in our mother app - code is dynamically run directly on the client and server-side.
The way we were able to get around that was by dynamically injecting the correct remote based on the parameter in the URL. It was not as easy as we thought. To achieve that we had to:

Deploy our remote application to be available through some dynamic URL on each pull request. We created a deploy preview step in our CI that created dynamic storage using Amazon’s Simple Storage Service.

https://$bucketName.s3.eu-central-1.amazonaws.com/federated/remoteEntry.js

Inject this dynamic remote into our living staging environment.

// https://website.com?remoteApp1=https://$bucketName.s3.eu-central-1.amazonaws.com/federated/remoteEntry.js

const remote = new URLSearchParams().get('remoteApp1')

Insert script tag with this remote.

const element = document.createElement('script');
element.src = remote;
document.head.appendChild(element);

Load actual component to be used in our code.

const Component = React.lazy(loadComponent(remote, module));

return <Component {...props} />

Learning curve

Our setup has a steep learning curve. There is a lot to learn and understand to get a grasp for some of the low-level concepts and webpack documentation isn’t much easier to read with its building blocks defined as ContainerPlugin, ContainerReferencePlugin, and ModuleFederationPlugin.

Conclusion

Module federation filled an enormous gap in the frontend world. Lessons learned can help us extract some of the self-contained applications currently living inside monorepo to speed our development and give a lot of freedom to autonomous teams.

What’s next?

Our current setup is impressive for us. With our fast pipelines, separate deployments, and independent teams we are more agile than ever.
But we must not rest on our laurels. There is a new version of React coming and we need to figure out a way of introducing backward-incompatible changes such as this. And we have our eyes on the new cool kids on the block - Javascript’s native module system (ESM) and non-JS bundlers such as esbuild written in Go.