dwyl / learn-tachyons

:heart_eyes: Learn how to use Tachyons to craft beautiful, responsive and fast UI with functional CSS!
https://tachyons-bootstrap.dwyl.com
673 stars 39 forks source link

How we should extend tachyons? #24

Open gabrielperales opened 7 years ago

gabrielperales commented 7 years ago

Currently, I'm working on a project with tachyons, I realised that there are some CSS properties that couldn't work well with the functional approach of Tachyons, I mean there are some properties that can't be composable. For example, tachyons comes with some box-shadow classes, but if I want to change any of its values I can't compose it like if it were a padding with padding-left, padding-right and so on. So, is there any approach to extend tachyons properly?

Right now I'm just adding new css rules to my css file like:

.shadow-6 {
    box-shadow: 0 0 10px 0 rgba(8, 19, 38, 0.05);
}

but of course, they wouldn't work for media queries because I'm not adding .shadow-6-ns, .shadow-6-m and .shadow-6-l.

iteles commented 7 years ago

@mrmrs Might have a view on this one 😊 Might also be a good question to ask on the tachyons repo @gabrielperales ?

gabrielperales commented 7 years ago

Ok @iteles ! I'm going to do it :)

mrmrs commented 7 years ago

There is a lot to unpack here in this question and I'd like to make sure I'm answering all of the questions (some which seem not stated explicitly). Feel free to correct my misinterpretations of your question(s).

The proper way to extend Tachyons is, to be honest, however you see fit. There are a myriad of different circumstances and workflows that can work depending on the context of your problem. Generally I think the best practice is to customize partials to your liking and then manually merge in all upstream changes from the repo. Some people do not like this method as it involves manual work but I don't like to automatically grab any updates from a css lib without review as it is a global space no matter what naming methodology you are using.

Many users I've spoken to just add their own files with naming schemes like _box-shadow-extensions.css and add those to the main tachyons build file. I don't love this method personally as if someone is looking at the box-shadows file it can be tough to know there is an additional file to check if you want to see all box-shadows. So really depends on what the team finds to be easiest. Tachyons doesn't have a ton of changes at this point so even larger additions / updates should be fairly easy to merge in. The benefit though is they can pull in upstream changes without having any conflicts.

Box-shadow values are one of the more 'opinionated' things in Tachyons. I say opinionated mostly because it's prescriptive but without a deep sense of design rationale compared to some of the other chosen values. So for extending it you might just choose to customize all of the values entirely. This is still composable though in my mind. You just have longhand properties of box-shadow that are eligible for composition which is a css limitation unfortunately.

If the question is - if I add a class how do I automatically add additional classes to scope that class to each breakpoint, there are two solutions. One is to create your own loop / generator. A bunch of people have created solutions like this. I believe you can find a few of them in the tachyons org or in pull requests / issues on the tachyons project.

For me this is an information finding anti-pattern. It won't affect your compiled outputted code necessarily but through user testing I have found this to be highly tricky for both newbies and veterans alike. It can make grepping / searching the source for a generated class impossible which I think isn't worth the effort of dev savings. For me I just have a vim script that handles keeping everything in sync as I view it as a text-editing problem and not a css problem. Some people will point to source maps as a solution to this - but I have not found that to be a great solution with many of the users I've tested with. If they do work for your team, that is awesome. Generally for css compilation I find their setup to be more trouble than it's worth especially considering the myriad of technical skills people that touch front end code have. I like to keep things as simple as possible if possible. This for me is one of those cases.

Another point - is that it isn't necessary for all classes to have equivalents across all breakpoints. While a very common pattern in Tachyons - it isn't a requirement or the point. There are definitely things I don't change often across breakpoints and adding them to each breakpoint would just be too much weight to be worthwhile. So it's not a rule / necessity to add equivalents if you're adding a box-shadow.

Feel free to ping me with more questions.