Fork me on GitHub
#untangled
<
2016-09-14
>
anmonteiro15:09:50

@stephenway wasn’t aware of that

stephen15:09:31

It never became a standard language, but has some awesome ideas around it!

stephen15:09:49

like inherited values

anmonteiro15:09:02

that project uses garden to generate the styles

anmonteiro15:09:40

the rationale behind it is that if we’re colocating queries, why not styles too 🙂

stephen15:09:06

yea, makes sense

stephen15:09:50

are media queries handled in an external stylesheet?

anmonteiro15:09:42

didn’t think about that (yet)

anmonteiro15:09:50

can’t we do it in garden?

stephen15:09:11

I’ve never tried garden

shaun-mahood15:09:19

I believe there is going to be a new alpha release of Garden with a bunch of changes in the next few weeks - might be some useful ideas to look at there as well

stephen15:09:54

@shaun-mahood Do you know where I can find that? Can’t find a branch or tag on github.

shaun-mahood15:09:00

Not out yet, you could check with @noprompt when he is planning a release

stephen15:09:54

ahh ok, I was just curious if that release would have collocated styles

tony.kay15:09:33

@anmonteiro I'm noticing a trend of people overriding defui. It occurs to me that this approach does not compose. The next challenge, perhaps?

anmonteiro15:09:50

@tony.kay yes! That’s one thing I regret

tony.kay15:09:31

we're wanting to instrument it to add in debugging capabilities in the browser during dev, and lots of libs seem to want to do things like your css lib

anmonteiro15:09:46

one of the hard requirements of that project though is that we generate a CSS file in the end

anmonteiro15:09:54

this has to be done on the JVM side, of course

tony.kay15:09:26

I understand. Same problem for the debugging tools. The hack has to take place at the react level

anmonteiro15:09:57

well the thing is it needs to be a macro

tony.kay15:09:26

Do you leverage the real defui inside of your macro?

anmonteiro15:09:30

it probably doesn’t need to be colocated in the sense that it’s a protocol to implement in defui

anmonteiro15:09:10

maybe some other macro like defcss that can be colocated above the defui macro, like core.typed annotations are

anmonteiro15:09:25

I have to think about that. feel free to open issues if you wanna discuss that

tony.kay15:09:59

in the meantime I'm going to play with it for sure

noprompt16:09:36

@anmonteiro my expectation is to have an alpha available in the next couple of weeks. the next version of garden is addressing specific pain points of issues that are difficult to close with the current implementation. the most significant improvements will be support for parsing/manipulating "raw" CSS and a dramatically cleaner, clearer, and more extensible compiler.

tony.kay16:09:39

@anmonteiro how about, instead of a defui override, a function that can be called in the body of render? E.g. (render [this] (apply-css (dom/div #js {:class :root} ...)))

tony.kay16:09:26

I guess that adds some runtime overhead

anmonteiro16:09:00

@tony.kay where would you define the actual styles?

tony.kay16:09:20

same way you were...oh, I missed passing this as a parameter

tony.kay16:09:56

Actually, if you passed the class name as a parameter, it could probably be a macro

tony.kay16:09:18

ultimately, for render you just need to know the name munging, right?

tony.kay16:09:13

Also, does :class accept a seq as well? Might want multiple classes on an element

anmonteiro16:09:35

"<= use a vector [:one :two] to add multiple classes to an element"

tony.kay16:09:38

ah, missed that

anmonteiro16:09:51

and yeah, for render I just need to know the munging

tony.kay16:09:07

so that would eliminate the need for an override of defui

anmonteiro16:09:19

what I meant earlier by the defcss was that it could take the class

anmonteiro16:09:25

somewhat akin to clojure.spec/fdef

tony.kay16:09:31

Yeah, and then that would be reusable

anmonteiro16:09:45

but we’d lose colocation actually inside defui

anmonteiro16:09:59

which might actually not be that important

tony.kay16:09:15

you could still just use a static protocol, but yeah, probably less important

anmonteiro16:09:37

couldn’t use a static protocol without overriding the defui macro

anmonteiro16:09:58

because I do static analysis on the defined styles

anmonteiro16:09:03

and evaluate them on the Clojure side

anmonteiro16:09:09

to generate the CSS file

anmonteiro16:09:36

which is also the reason why variables must be defined in a .cljc file https://github.com/ladderlife/om-css#user-defined-variables-in-colocated-styles

tony.kay16:09:38

oh right, you'd have to be running cljs to do it otherwise

tony.kay16:09:02

node integration? 😄

anmonteiro16:09:04

btw, the current CSS spitting works great with e.g. Figwheel development

anmonteiro16:09:11

we’d lose that if Node

tony.kay16:09:22

that is a really nice feature

tony.kay16:09:17

Yeah, I'm liking the defcss idea. avoids the defui composition problem, but gets all of the good results.

tony.kay16:09:39

Is this being used at LFin?

anmonteiro16:09:09

not currently I think

tony.kay16:09:19

I just saw the ©️

tony.kay16:09:38

hard to change a lib that much once adopted

anmonteiro16:09:41

it was but they’ve replaced it with something very similar

anmonteiro16:09:03

so definitely up for the churn

anmonteiro16:09:26

problem with defcss is then we’d need to wrap the render function too

tony.kay16:09:55

that can be a pro as well, though, because it opens the door to further composition and reuse

anmonteiro16:09:00

which you mentioned above with apply-css

tony.kay16:09:09

(apply-css [Style1 Style2] ...)

anmonteiro16:09:23

Oh we’re thinking different things

anmonteiro16:09:35

and your idea is probably better

anmonteiro16:09:56

I was thinking:

(defcss Foo ..)
(defui Foo ..)

tony.kay16:09:09

I see, yeah I was thinking more general

anmonteiro16:09:11

and the Foo styles would only be applied to Foo

anmonteiro16:09:29

probably harder to do your idea because of prefixing

anmonteiro16:09:43

actually maybe not

tony.kay16:09:46

not really, only conflict resolution

tony.kay16:09:58

if you use the same name twice, it would be ambiguous in the component

tony.kay16:09:26

but that's easy enough to throw a warning on and resolve by hand