tailwind-clj icon indicating copy to clipboard operation
tailwind-clj copied to clipboard

spit-css! not being able to account for different namespaces

Open ava-sig opened this issue 5 years ago • 2 comments

Hello, I've been using this library with great pleasure and it's amazing, great job by the way. My code started to become bulky so I wanted to split in different ns for ease of management. I've noticed that even if I run (spit-css! "..") only in my main namespace (where all components are required) or try to run it in each ns individually, it still deletes randomly some classes that I still use. Am I missing something ? Should I run it some place specifically ?

ava-sig avatar Jan 22 '20 15:01 ava-sig

I ended up generating different css-es for each namespace and imported them in the html separately instead of having one giant css that keeps being aggressively modified by each figwheel compilation. I still see classes added and removed randomly (while not even working in a specific namespace for example) but overall it's not affecting me as it used to. not sure if this is a good workaround because it just moves the issue of ordering rules to ordering <link ref>s of css files, but so far so good, no rules overwrite each other in a seemingly random list of imports.

ava-sig avatar Jan 30 '20 13:01 ava-sig

@vladanghene Thanks for the feedback. I have to admit I've only used this on small demos so far and I agree the way the library currently collects the tailwind rules via macros is fragile W.R.T. to figwheel reloading. Also it's not obvious where to call spit-css!. I'm guessing if figwheel doesn't recompile a namespace then it won't see those rules before spit-css! is called causing those rules to vanish. My understanding of macro evaluation with figwheels hot reloading is a bit sketchy maybe there is a figwheel setting or a different approach is needed in development

I'll try and reproduce this on a larger project

mrmcc3 avatar Feb 11 '20 00:02 mrmcc3