SPIKE: Tailwind, is it the future?

[moshie]

Introduction

As part of a spike I investigated the possibility of trading styled-components in the react-components library for tailwind.

I found a number of benefits and drawbacks to this approach which I hope will make for some interesting reading.

My reasoning for opening up an investigation into a utility class methodology is that I suspect it is a far more flexible approach to component based development.

Allowing us to put more power into our applications while maintaining the branding & reducing duplication of styles throughout the Zopa development community.

What did you try?

Initially I started hacking at the existing react-components library and found out quickly that the foundation of the react-components library doesn't make it easy for implementing tailwind.

ZRC (Zopa React Components) uses styleguidist which acts as an isolated environment in which to develop react components as well as produce a style guide.

Styleguidist gives very little in the way of documentation when it comes to implementing tailwind in fact all I could find which tied the two together was this issue: styleguidist/react-styleguidist#1547

I looked at the post-css method of implementing tailwind but the issue with this method is that styleguidist bundles everything up including tailwind and since we want to handle tailwind on the application side this wont work.

Instead of working with the existing ZRC I went for a different approch creating my own stripped down version of the ZRC library to see what would work.

I started by separating the style guide from the exported library by creating two different webpack configurations.

I put the concept into a Repo which you can find here

What a button component might look like in ZRC lib with tailwind:

Could we use a bespoke approach to utility classes instead of tailwind?

We certainly could write our own bespoke utility classes very much like the margin & padding we have at the moment.

Although this certainly would be less work and offers an easier migration plan I feel doing this would mean we find ourselves in the long run just re-writing tailwind.

Since tailwind has more community backing & support It's my personal opinion that we should use that where possible.

What about the instances where we want to write css that isn't in tailwind?

I would sugest putting a css file alongside components which use custom classes and import them into the component allowing webpack to bundle them appropriately.

For global utility classes which don't make sense in the ZRC library they can be placed in a css file at the root of your project.

What kind of work would be involved with adding tailwind to ZRC?

I don't think it's going to be possible to write tailwind into the existing react-components without a serious refactor and bumping to a breaking version.

Because of the way tailwind utilises webpack, tailwind will need to be implemented at the app level meaning refactoring for existing Zopa applications.

Existing components in the ZRC lib currently export out css styles which would be replaced by classnames if we used tailwind this would break for anyone using those exported styles.

Can we use the css for marketing teams?

Absolutely, you can export out css using the configuration we have and very quickly mock up html elements in zopa styling.

What does tailwind's roadmap look like (breaking changes)?

It looks like they have a well established library and I don't foresee them drastically changing it anytime soon.

Their focus seems to be on pre built components using tailwind so If they break the base library they undoubtedly would break that as well.

What are some of the Benefits?

• From the repo I created I found that the development process is much easier and dealing in classnames leave little margin for error our snapshot tests would also be much smaller.

• Classnames make it easier to focus on the component since you don't have a large amount of CSS at the top of the file.

• Theming would certainly be possible we can export out different tailwind configs from react-components library and the consumer could choose which one they want to implement. (https://tailwindcss.com/docs/theme)

• Implementing Tailwind at the app level will give the app more control over bundle sizing and Post CSS will give more finite control over auto-prefixing & browser support ect..

• We could have tag agnostic components for example a button could simply export out the classnames and the consumer could decide if they want to use an anchor tag or button tag.

Links

• https://github.com/tw-in-js/twind
• https://github.com/ben-rogerson/twin.macro

Conclusion

Coming soon..