Thread by @GroundControl

Let's try a tech talk in a tweet thread. Shall we? I gave this lightning talk at #ReactBoston2019 this weekend.

Implementing design systems is a big trend in software development right now. But how can we enforce them?

Once upon a time, there was Shippy the App. #shippy.

Shippy is our baby. Our Minimum Valuable Product. Shippy's job is to ship, and make our customers happy. Our task is to nurture Shippy, and raise it from an MVP to a Minimum Lovable Product.

Shippy will go through several iterations. For example, we might change the branding. Shippy is now blue.

And we might find out that the blue branding doesn't work. So we tweak Shippy, and Shippy is now orange.

And then maybe the CEO doesn't like the branding, "Shippy feels like it should be light blue". So we tweak Shippy again.

And maybe Shippy isn't performing like it should be. So we add a big button.

And maybe that button doesn't work. So we change the button to something we think will perform better.

But we didn't do that very carefully because we're going very fast. So we didn't really remove the old blue button from Shippy.

And maybe we also forgot to remove some of the old branding.

And the button still isn't performing how we want it to so we tack on a different button.

And because we're constantly adding new features, and at the same time trying to change branding and tweaking UX, Shippy ends up looking like this over time. It's a weirdly branded, incoherent experience.

I come to design systems from startups, and this is a common problem.

As the product gets bigger and you have more design iterations, it gets harder and harder to implement change across a whole app.

Startup teams tend to leave code correctness and design systems for later.

But when the product gets messy, engineering gets slower and slower, until it becomes a liability.

"Oh, it's time to finally pay that technical debt." It’s not technical debt. It's product risk.

But ironically, having discipline and implementing a design system can help the most AT THE BEGINNING of the journey.

The longer a design system exists, the more value it can give you.

But, design systems are a "big development team" thing for a reason. They require cultural buy-in, and a bureaucratic process to ensure that everyone is sticking to it.

How can small teams stick to a design system? Well, we can use existing tools. We already have @geteslint.

@geteslint We use ESLint to have a uniform coding style and to check for correctness.

Can we use ESLint to check for Product Correctness??

@geteslint Yeah, we can. We can build our own ESLint Plugin to enforce whatever kind of rules we want.

Building an ESLint plugin is not that bad. There's a good tutorial by @FlexportEng on how to write your own plugin. flexport.engineering/writing-custom…

@geteslint @FlexportEng Writing an ESLint Plugin involves understanding Abstract Syntax Trees. en.wikipedia.org/wiki/Abstract_…

For a long time I thought that ASTs were for super nerds. But it's actually not that bad. It's actually quite simple to understand. Play around with astexplorer.net

@geteslint @FlexportEng But some of you might be skeptical.

@geteslint @FlexportEng It's ok, cause I made you a plugin to help solve this issue.

(It's still in the experimental stages, but try it out!)

@geteslint @FlexportEng Let's take a look at Shippy's code here. It's a #reactnative app.

In a codebase that's iterating on design quickly, we might have a lot of instances of hardcoded colors. For example, line 14:

`backgroundColor: "#07313A",`

@geteslint @FlexportEng You probably want to have all the colors in your codebase come from constants. In order to solve this problem, we can add the design-system plugin rule to give us an error when it detects hardcoded colors.

(js only)

@geteslint @FlexportEng Another problem we might have is that we're using the wrong components.

We might have deprecated components from an old design...

We might have forbidden platform components, where we want to use our Design System instead...

@geteslint @FlexportEng To solve that problem, we can add the `use-design-system-components` rule.

You can configure that rule by adding a `settings.design-system` section to your eslintrc file, and you can specify which imports you want forbidden. You can deprecate old components!

@geteslint @FlexportEng If we run eslint on our codebase, these are the design system errors (or warnings! you can configure that) we get.

It's like a list of things we need to do to make our product consistent 😇

@geteslint @FlexportEng (A small note, the isRelative flag is required for now, and the module value should be a substring that can be found in all the import declarations.

Eventually I'll be able to change this to use globs. Maybe you can help me?)

@geteslint @FlexportEng So, give this plugin a try. It only works on JS right now, if you want to lint CSS it requires a different set of tools.

Because I'm mostly a React Native dev, there might be some things I missed for React Web.

But you can help me improve it here:

github.com/dslounge/eslin…

@geteslint @FlexportEng Here are the takeaways from the lighting talk, given at @ReactBoston.

Make sure to help #Shippy grow up happy and healthy!

@geteslint @FlexportEng @ReactBoston Thanks for coming to my tech talk!

@geteslint @FlexportEng @ReactBoston ^ Thanks to @tranhelen and @pifafu, who were inspirations in how to talk and present this idea about design systems.