Fork me on GitHub
#shadow-cljs
<
2018-09-08
>
grounded_sage14:09:18

How can I do a binding with shadow cljs?

thheller14:09:20

same way it is done there

thheller14:09:04

(defn foo [] (binding [x y] (shadow.cljs.devtools.api/compile :the-build))

thheller14:09:13

might have to disable caching though

grounded_sage14:09:04

Ok. I was avoiding clj-run and leveraging build hooks.

grounded_sage14:09:26

Could I wrap the build-state of a build hook with it?

grounded_sage14:09:56

hmm yea just took another look and realised

grounded_sage14:09:53

So the dynamic variable binding should be avoided to keep it to build hooks and keep caching then?

thheller14:09:38

no idea. i don't know what cljss does

thheller14:09:48

it looks like it doing a bunch of side effects in macros

thheller14:09:07

and that seriously breaks with caching enabled

grounded_sage14:09:22

Yea this is the SSR implementation being worked on.

grounded_sage14:09:51

I'm looking to leverage it in shadow-jam and just figuring out how I can leverage that SSR.

grounded_sage14:09:59

I probably need to have a closer look at the caching situation then as well because I perform image manipulation and generate multiple image files in macros.

thheller14:09:28

don't do such things in macros

grounded_sage14:09:01

There isn't really any other way for me to perform it from what I can tell.

thheller14:09:34

there are plenty of ways. they just might not be documented too well

grounded_sage14:09:29

Allows defining a source image and other details which it then uses to grab image, collect certain metadata, use that metadata to figure out data required for the html markup and generates corresponding assets.

thheller14:09:10

so the basic misconception I see it that you think everything has to happen in the macro

thheller14:09:21

it doesn't have to happen in a macro at all

thheller14:09:48

thats the fallacy with starting with a macro in the first place

thheller14:09:02

so lets imagine this without a macro at all

thheller14:09:46

you have want to achieve [:picture [:img {:src "some.jpg"}]]

grounded_sage14:09:51

I thought it through and discussed with others and apparently macro was only way. I try and avoid macros as I know the objective is data > fn > macro

thheller14:09:06

where the PATH to the image is "replaced"

thheller14:09:31

so you instead call [:picture [:img {:src (your.lib/get-path "some.jpg")}]]

thheller14:09:06

you then of course want responsive versions

thheller14:09:56

[:picture [:source {:srcset (your.lib/get-path "some.jpg" :small) :media "..."}]] [:img {:src (your.lib/get-path "some.jpg")}]]

thheller14:09:11

so then the question becomes what get-path looks like

thheller14:09:15

its a function

thheller14:09:26

so it can take data from everywhere

thheller14:09:50

so lets suppose there is a global "myImages" variable

thheller14:09:26

(defn get-path [img-name img-variant] (goog.object/get js/myImages img-name (name img-variant)))

thheller14:09:46

now the question is how do you get the info you need for myImages

thheller14:09:58

a) generate it statically since you know which images you have and then append it to the final build output

grounded_sage14:09:24

It's actually

[:picture [:source "various responsive sizes"] [:source "the same thing again but fallback image format"] [:img "the image again which contains more metadata and fallback"]]

thheller14:09:42

thats what I just posted above

grounded_sage14:09:55

Ah yes slow typing. Apologies.

thheller14:09:29

the other option is to actually employ a macro but only store which images where accessed and which variants

thheller14:09:44

so you can extract that in a build hook

thheller14:09:02

so basically the concept is to use a helper function that can return data that was not part of the CLJS compilation at all

thheller14:09:44

and then append it to the final build output instead

thheller14:09:05

or pass it to the build by any other means

thheller14:09:19

in my experience image processing too much is actually a problem in the long rum

thheller14:09:29

sometime you don't just want to use the same image in different sizes

thheller14:09:58

sometimes you want a big one and a small cropped one (instead of the whole area)

thheller14:09:16

sometimes the smaller one is completely different

thheller14:09:45

building a system that can generate all the images you want into a macro is just gonna be painful to use for everyone

grounded_sage14:09:09

I kind of see what you mean with the helper functions. For me right now the macro seems easier to grok. I'm just working to bring this up to a gatsby like experience (through stealing ideas) then hopefully people with more dev chops can chime in and help me polish it lol.

thheller14:09:24

so then steal how they deal with images

thheller14:09:31

they don't have macros either

grounded_sage15:09:31

I've print screened your explanations. Brain a bit foggy as is late here now.

thheller15:09:02

I'm a bit too busy with other stuff but hooking image processing and scss into shadow-cljs is on my list

thheller15:09:16

just won't be part of normal compilation and a plugin of sorts instead

thheller15:09:35

probably not going to touch ssr though

grounded_sage15:09:54

I'm interested to see your image processing implementation when done and see how much more I have to learn 😛

thheller15:09:26

well I'm just going to take whatever tools already exist

thheller15:09:36

make them generate some edn/json data

thheller15:09:44

and then concat that into the build

thheller15:09:59

right now my image processing is a .sh file with a bunch of convert img.jpg other-image.jpg