I’ve used this stack for a few years now and really enjoy the power and expressiveness • shadow-cljs for build/compile management • Reagent for a great react wrapper • Hiccup for a data-first approach to html • Garden for css • re-frame for a redux-like evented state manager • bidi for SPA routing

Thank you. @U5RFD1733 Should I study in the order you gave me

you're welcome! enjoy!

@U025AG2H55F - Consider doing a server side rendered UI Do check if you really want to do client side UI. Hiccup + htmx + HyperScript allows you to now build brilliant interactive User interfaces with just server side programming. It wouldn't be a good approach for things like 3D browser graphics, but for any standard business dashboard/Crud/Webapp UI it works very well and is performant. It also means that you have one codebase and don't need to build APIs from frontend to backend. Client side rendered UI If you are going to do a ClojreScript UI, then do check out #CNMR41NKB . With just a few hooks you can build very capable UIs and it's also very compatible with the whole react ecosystem (so you can easily use JavaScript react libraries like Ant).

What is HyperScript? the new programming language? What is uix?

• hypercript is a small language for doing simple ui interactions - it can be embedded in html/hiccup. https://hyperscript.org/docs/ • Uix is a popular thin clojurescript wrapper around react - alternative to reagent and reframe. https://github.com/roman01la/uix

Thanks!

Seems that malli instrumentation might not be suited for DCE then. Been experimenting a bit using preloads, and there are issues with reloading. I think that with preloads the instrumentation runs too soon, it needs to run as the first thing in the after-load handler. But this is more of a malli thing, so I should probably bring it over there.

there have been previous discussions about this, so should be findable somewhere

basically your preload ns just needs to require all your application namespaces

that ensures they are loaded before the preload

https://clojureverse.org/t/problem-using-malli-clojurescript-instrumentation-and-shadow-cljs/8612

note that this pos is very old. a lof has happened in this area, not sure what the current state it though

You know what, I think that actually works. Adding a require for app.main in the preload ns and sprinkling a couple of {:dev/always true} around seems to make everything reload as expected. This is awesome and solves a major issue for me, thanks!

There actually is a mention of the preloads technique in https://github.com/metosin/malli/blob/master/docs/clojurescript-function-instrumentation.md. If this proves to work in a stable way for me, I might post a PR to document this properly

I just updated that doc recently for release builds: https://github.com/metosin/malli/blob/master/docs/clojurescript-function-instrumentation.md#releaes-builds I was trying the :preloads technique (calling ! there) but wasn't getting proper recompilation. I wasn't including the app.main ns like you tried though, so yea if you find it's working, PR with an example would be great!

It should be [shadow.css :refer (css)] in :require Also, come to #shadow-grove 🙂

That's the problem! Thank you! It works!! but why? Isn't shadow-grove using shadow-css inside too? I don't get it.😵

No, it's a separate library. (You can see you're including it separately in deps.edn.) shadow-css is not tied to shadow-grove in any way.

Also, you can add new aliases without cloning the entire library.

Thank you zeitstein. I'll go look into it.

How can i do that? You mean i can add tailwind aliases without cloning shadow-css?

Yes. You can modify the https://github.com/thheller/shadow-css#building-css step, something like:

(-> (cb/start)
    (update :aliases merge my-aliases)
    ...)

Oh i got it. Thank you very much!!

there actually is a shadow.grove/css macro. so that should be fine. maybe your local clone of shadow-grove is too old though?

but yes, no need to clone/fork shadow-css to add your own aliases

> there actually is a shadow.grove/css macro Forgot about that.

Thank you for answering me!

You can't. The most common approach is also the most simple and direct one - just refer to those files via URLs in the necessary contexts.

Even with goog.require or foreign-libs?

Static resources aren't libraries. They are just files. You have to either embed them as data or request them from some server. For the former, in the CLJS world you can use a simple macro. For the latter, there's no simple solution. In the JS world, there's an easy solution though, that does a lot under the hood.

Any tips on including a large edn file (~5-10mb) ? I went the macro way and it works great but it slows the re-compile on save by 2-3sec with shadow.

Such large files I would definitely get via a separate request or maybe embed as the very last item in the HTML. Either AJAX or some relevant tag in the HTML. Can be <script> with a custom type if it's not some data that a browser can read.

Could you avec a link tag that point to some edn ?

It’s not for prod, just to dev in the browser without involving some backend

You sure can. But you'll have to parse that edn yourself at run time. The script tag will store it as plain text.

What happens under the hood with the js solution?

I'm only superficially familiar with webpack loaders. Some solutions bundle the data into the relevant JS module and add the data itself, like e.g. CSS styles, to the HTML when that module is loaded. Others do something similar but instead using the data itself, they refer to it via a URL. So e.g. you can have require('/public/css/root.css') somewhere in the code and, given an appropriate configuration that knows about the server routing, during compile time it would be transformed into some code that injects the right <link ...> tag into the HTML.

Move that code outside of the go block. go loses the ^js metadata.

Thanks, but I can’t move it out, the (.-exists snapshot) depends on consuming a Firestore promise:

(go (let [doc (<p! (-> db (.collection "mycoll") (.doc "123") (.get)))]
      (if (.-exists doc)                                    ;; <-- infer error.
        (do-something)
        (or-not))))

You can move it out - just extract it into a function and call that function in go. I didn't mean to not use go at all - I meant just not having nested forms.

The go macro rewrites the code, and that rewriting algorithm is simply not aware of ^js.

(defn my-thing []
  (go (if (async-thing)
         true
         false) ;; how do I get at true or false from caller?

(my-thing) ;; <-- this is channel, so have to:
(go (<! (my-thing))) ;; same problem, no?

From your previous code block:

(defn doc-exists? [^js doc]
  (.-exists doc))

(go (let [doc (<p! (-> db (.collection "mycoll") (.doc "123") (.get)))]
      (if (doc-exists? doc)
        (do-something)
        (or-not))))

Ah, now I understand. By moving the the metadata into a function it won’t get rewritten by the macro. Thanks!

Hmm, I’m still getting inference warnings even if I move the Firestore Node calls to functions.

Well, that's because you didn't tell the compiler that *coll is actually a ^js.

Should be:

(defn doc [^js *coll id]
  (.doc *coll id))

(defn doc [*coll id]
  (.doc ^js *coll id))

Thanks @U2FRKM4TW!

Soo much better without the warnings