Fork me on GitHub

@d4hines mk-session would use clj eval. So it’d need to be running in a JVM process.


The rule data structure are just plain clj data so could be made wherever and sent to mk-session


Also. I don’t know if you are trying to load rules in cljs still hah

Daniel Hines00:06:44

I got a little confused as to which we were doing 😛. If mk-session requires a JVM, that means I would need to compile it down to CLJS like the google thread described, then require that in a <script> tag or similar, right?

Daniel Hines00:06:09

I think my use case is such that I could justify just doing a new build/deploy of the whole frontend every time they needed to update the rules (which isn't at rapid speed or anything), which sounds like it would be much easier and not require any more infrastructure than using Clara with cljs in the first place. Is that a bad way to go?

Daniel Hines00:06:35

Turn it into a CI/CD problem instead of a Clojure problem.


Yeah may be reasonable. I’d have to look more to have any better suggestions there.


I guess Clara compiled rules cannot be returned from like an xhrio call? Hmm.


Yes. It is useful. You can build rules in more dynamic ways when useful.

mikerod02:06:53 A bit older post but related shows interesting things that can be done. I think that Daniel mentioned in an earlier comment today.


I read through it. Instaparse is a bit of gibberish to me right now. I’ll have to look into it more. 🙂


@d4hines it’s not a path anyone’s cleared that I know of. I’d expect it to be challenging no matter the approach you take. Another one depending on what kind of setup you ultimately want could involve figwheel I think. I’ve had some success getting live reload to work by redefining the session var in cljs and manipulating the keys in the cljs compiler env that Clara stores productions in. I only had it working for changes to source code though