@michael.heuberger there isn’t now but there will be a function in garden.core
called vdom-style
which produces a javascript object. you’ll be able to write [:elem {:style (garden.core/vdom-style {,,,})]
and that will work as you’d expect.
within the next week or so there should be an alpha of the next major version of garden available. there are some small and significant breaking changes on the horizon so please consult this changelog 👉 https://github.com/noprompt/garden/blob/v2.0.0/ChangeLog.md for details.
please share any concerns or questions with me on the pull request for the next major version here: https://github.com/noprompt/garden/pull/123
i’m also open to any questions here as well.
@meeli that post is fantastic! thank you for sharing. i think it captures the rational and benefit of using something like garden far better than anything i could have come up with!
garden v2 will actually have a pretty good answer for something like PostCSS because garden now works with an AST under the hood. instead of compiling CSS directly from objects, garden v2 has a parse phase which produces a CSS AST and that is compiled. what this means is that you can do AST transforms on the CSS before it’s compiled.
so basically, garden v2 comes with PostCSS baked in since there’s an AST and that can be manipulated using the clojure toolbox.
the other really, really cool thing that comes out of this is that we now have a way of going from CSS back to garden — it enables unparsing.
what i love most about this property is that existing CSS could be parsed into an AST and then transformed back into clojure data structures and garden’s records.
the vast majority of it is based on multimethods too which gives the library consumer much more control than was previously available.
@noprompt That is incredibly exciting!
@niamu i think the most exciting part, for me anyway, is all the issues that will finally be closed! 😛
Garden is probably one of my favourite libraries to show non-Clojure people. SASS never felt right to me and Garden is the perfect thing to point to that explains why.
@noprompt: Closed as in fixed? Or closed as in "new version, so let's forget about the old issues so we have room for new ones?" 🙂 I'm excited for either option, really.
@shaun-mahood literally fixed. 🙂
#31, #52, #109, #115, #116, #119, #120, #121 are fixed.
my hope is that the new design will make it a) easier for me to turn around bug fixes and/or b) make it easier for others to submit patches.
what’s on master is a clear reflection of my inexperience when i started putting it together. hopefully, what exists on 2.0.0 will reflect a much more careful and thought out design.
with the exception of a couple complex scenarios the compiler namespace should be fairly easy to comprehend by an intermediate clojure developer.
the normalize
namespace harbors most of the complexity and needs some explanation to make it a bit more clear but the nice thing is that responsibilities it has are no longer interleaved within the compiler.
clojure.spec
has been a huge when too.
@meeli this is a nice example of how by having clojure something like modular scale can be handrolled in a matter of minutes.
(defn ms-scale-up [base-font-size ratio i]
{:pre [(nat-int? i)]}
(reduce
(fn [n _] (+ n (* ratio n)))
base-font-size
(range 0 i)))
(defn ms-scale-down [base-font-size ratio i]
{:pre [(nat-int? i)]}
(reduce
(fn [n _] (/ n ratio))
base-font-size
(range 0 i)))
(defn modular-scale
([base-font-size ratio]
(fn [i]
{:pre [(integer? i)]}
(cond
(pos? i)
(ms-scale-up base-font-size ratio i)
(neg? i)
(ms-scale-down base-font-size ratio (- i))
(zero? i)
base-font-size)))
([base-font-size ratio f]
(let [g (modular-scale base-font-size ratio)]
(fn [i]
{:pre [(integer? i)]}
(f (g i))))))
(def mspx
(modular-scale 14 1.125 garden.units/px))
[(mspx -1)
(mspx 0)
(mspx 1)]
;; =>
[#garden.units.Unit{:magnitude 12.444444444444445, :measurement :px}
<#C0FQERS0H|garden>.units.Unit{:magnitude 14, :measurement :px}
<#C0FQERS0H|garden>.units.Unit{:magnitude 29.75, :measurement :px}]
it’d be interesting to see an implementation of something equivalent to sassline.
@noprompt: I've seriously been looking forward to this, thanks for putting all this work in. I'm going to be starting to replace all of my existing SASS and CSS with Garden and get everything styled consistently over the next month or 2, so I should be able to spend a good amount of time with the new version soon. I used garden for all the styles in my Conj talk and it made some of the last minute changes and fixes a lot less stressful, so you get double thanks 🙂
@shaun-mahood nice! i think the only thing that’s keeping it from being the primary branch at this point is integrating the selectors
namespace with parse
, a tweak to garden.core/vdom-style
, and bug fix for keyframes rendering.
do have a look at the Changelog though. the selector syntax for rules has changed slightly but it’s slight enough to incompatible with the v1 selector syntax.
@noprompt cool, thanks for that