Tachyons: What is the best way to extend Tachyons?

[zehfernandes]

Hi,

I put some thoughts but don't find a solution. I understand Tachyons is excellent for only websites and quick prototypes. But thinking in a constantly revisited project. What is the best way to use Tachyons and extend it?

For example, bootstrap uses the cascade in our service and have a custom build for typography and color. So to update you just change the bootstrap.css version.

Thinking Tachyons for a long run. After creating new breakpoints, new typography scale, new color set. How I update it? Is it correct to change this value in the source?

[enociz]

Good question. I too have been wondering...

[colepeters]

@zehfernandes It sounds like you’re using Tachyons’ all-in-one bundle, which I could see being challenging in the situation you describe. You might instead consider using the individual modules. If you find yourself customising or replacing many of the different Tachyons modules, while using others as they come out of the box, I would imagine a workflow something like this would make sense:

• For modules you use as-is: npm install tachyons-hovers (or use another install method), update as needed
• For modules you customise: Fork that module, make your updates, and use your fork instead of the upstream module, merging upstream changes as you see fit
• For modules that you author: Do what thou wilt

For example:

1. Let’s say I like using Tachyons’ classes for everything except the type scale, colours, and breakpoints. I update my package.json to include all of the individual modules except those 3 mentioned. I then import those modules into my app/website’s app.css/style.css/whatever.css, and I keep those updated as I see fit.
2. Let’s imagine I like and use most of the colours in Tachyons, but I need the blue to be my brand’s colour of blue because we all know brand colours are totes major important. So, I fork the tachyons-colors module and switch up the relevant colour variables. I then import my fork of the module into my project using a method that makes sense for me, and use it the same as I would any other set of Tachyons classes.
3. Finally, let’s imagine that Tachyons‘ breakpoints aren’t working for me — I need some very specific breakpoints because my marketing manager is going crazy because things are just not looking right on their weird-sized tablet and their internet-connected fridge. So, I’ll go and create my own custom media queries and import those into my app — but I’ll also likely need to modify some existing modules in order to work with these (like in step 2). For example, if I need to set some font-weights to bold just on my fridge media query, I might need to fork the tachyons-font-weight module to include a class like this:

@media (--breakpoint-superSmartFridge) {
  .fw7-ssf { font-weight: 700; }
}

I then manage my custom media queries module as part of my app/website/whatever's own codebase, making modifications to the relevant Tachyons modules as forks as needed down the road.

This is similar to how we manage customisations to library code at my work, and it’s worked well for us so far.

Having said all this, I’m not one of the authors of Tachyons, and they might have some totally different/way better ideas for you.

Lastly:

I understand Tachyons is excellent for only websites and quick prototypes.

Wherever you have a need for CSS, you can use Tachyons and it will be awesome. It’s perfectly as relevant to use Tachyons in a massive web app as it is in a quick throw-away prototype.

[mrmrs]

@zehfernandes It's definitely encouraged to change the values in the source. You should feel free to modify colors, type, breakpoints, class names etc.

I think there are a lot of benefits in having a scale based on powers of 2, but it definitely isn't the only aesthetically pleasing ratio.

We're currently working on a custom generator that would help automate this process a bit, but don't know when that will be ready/available.

As far as how to update:

I've often used patterns from external libraries but modified them to fit my teams needs (maybe class names need to change or color values etc.) and generally I just manually patch in updates if I find the update valuable / needed. There won't be a lot of changes to most of the tachyons modules moving forward and I feel that they'll be reasonable to patch in manually if you want to stay up to date.

To clarify when I say 'manually patch' I mean I'll generally copy new src files into my local setup and then run git diff, which allows me to see what has changed and grab the things I want and leave the rest. As all the css is global scope here, I'd want to review any additions to the code base, no matter what I was updating or adding in.

Hope that helps. Let me know if there are any points I can clarify.

[zehfernandes]

@colepeters Thanks for clarifying my questions. Using fork modules is a good point. I don't like to repeat my self. But put in numbers the changes is basically at _spacing.css, _typography.css, _colors.css so is not a big deal to manage an update by git diff.

@mrmrs I believe in spacing and proportion being an essential element of the brand identity. The generator would be so cool ❤️