Fork me on GitHub
#cljsrn
<
2021-06-09
>
Stefan09:06:13

Hi! I’m looking for some opinions from y’all. We have a quite outdated react native app, that desparately needs to be modernized. I’m wondering whether to go the Krell route, or use shadow-cljs (possibly combined with helix). Can I get some pro’s and cons from you? Things that are important to me is integration with Calva, developer experience in general, easy upgradability, and easy use of community packages, both those for RN and generic npm. Really looking forward to your insights!

pez09:06:59

Is Expo an option? If that you should have that in the mix of options as well. 😃

dotemacs09:06:17

I suspect that your choices are more going to be based on your preference rather than some technical issue.

Stefan09:06:46

@U0ETXRFEW Nope, Expo is not an option.

Stefan09:06:59

@U3SG7RX7A So what’s yours, and why? 🙂

dotemacs09:06:37

I like shadow-cljs because it just works. Sticking to it because you can use it for plain cljs projects.

🙏 2
dotemacs09:06:24

Nothing wrong with Krell either, but I was using shadow-cljs before Krell came out. So I guess you can say that familiarity with it sways me.

Stefan09:06:46

Yeah that makes sense.

pez09:06:40

Since you are a Calva user you already reveal that the purity of each tool doing just one thing is not your primary selection criteria. 😃

pez09:06:52

The shadow-cljs inspector is totally wonderful. I tap> like crazy these days.

❤️ 4
Stefan09:06:48

I guess I’m pretty pragmatic in that respect 🙂 And indeed, shadow-cljs’s tap inspector is very convenient. Also head about djblue/portal today by the way, will have to check that out as well, sounds interesting.

pez09:06:30

One thing I missed from figwheel was that it reports which files are being reloaded. Thomas Heller helped me figuring out a build hook for that:

(defn print-compiled-files
  {:shadow.build/stages #{:flush}}
  [{:keys [build-sources] :as build-state}]
  (let [compiled
        (get-in build-state
                [:shadow.build/build-info
                 :compiled])
        output
        (->> rc
             :resource-name
             (for [src-id build-sources
                   :when (contains? compiled src-id)
                   :let [rc (get-in build-state
                                    [:sources src-id])]])
             (sort)
             (into [:compiled]))]
    (binding [clojure.pprint/*print-right-margin* 20]
      (clojure.pprint/pprint output)))
  build-state)

👍 3
Stefan09:06:52

Did you really mean “figwheel” just now, or shadow-cljs? @U0ETXRFEW

pez09:06:20

I meant that figwheel does this, but shadow doesn’t, out of the box.

Stefan09:06:31

Ah right 👍

pez09:06:33

Regarding helix, there was some discussion in #clojure-europe yesterday regarding frontend frameworks. Some good arguments for Reagent where posted.

kennytilton10:06:04

Reagent suffers from glitches, FWIW.

Stefan10:06:49

@U0PUGPSFR What kind of glitches are you referring to?

kennytilton10:06:52

If you set up the subscriptions a certain way, we see a single initial state change propagate twice to some final subscription. This is the classic "glitch" in reactive programming, where the final dependency has two paths thru the dependency graph to some original node. https://en.wikipedia.org/wiki/Reactive_programming#Glitches

👍 2
kennytilton10:06:08

re-frame de-dups the dependency graph so it avoids glitches, or at least I was unable to force one. I ran into glitches in my own Cells/Matrix code when implementing a RoboCup client, which was a brutal use case because all dataflow ran from a single node in which a new game update was received. It totally broke the app.

👍 2
kennytilton10:06:56

ps. Yes, I was able to force a glitchy behavior in Reagent. Reported it in that channel ages ago.

pez11:06:15

For other reasons I would still be building using re-frame if I use Reagent.