hyperfiddle 2023-12-15 | Slack Archive

Ive got a spinner. The entry point for it looks like this:

(e/defn MountSpinnerAs
  [id]
  (e/client
    (let [set-loading-state! (second loading-state)]
      (ops/when-repl (timbre/info "Mounting spinner for" id))
      (set-loading-state! #(conj % id))
      (e/on-unmount (fn []
                      (js/setTimeout
                        (fn []
                          (ops/when-repl (timbre/info "Unmounting spinner for" id))
                          (set-loading-state! #(disj % id)))
                        60))))))

I’m calling it here:

(e/defn BindAccount
  [Next]
  (e/server
    (let [{:keys      [logout-url]
           :user/keys [account]
           :as        user-info}
          (try (session/Authenticate.)
            (catch Pending _ nil))]
      (if-not account
        (MountSpinnerAs. :BindAccount)

This generates the following error:

TypeError: Cannot set properties of undefined (setting '3')
    at Object.hyperfiddle$electric$impl$runtime$input_change [as input_change] (runtime.cljc:373:15)
    at hyperfiddle$electric$impl$runtime$eval_change_inst (runtime.cljc:819:6)
    at eval (core.cljs:7387:25)
    at Object.cljs$core$inode_kv_reduce [as inode_kv_reduce] (core.cljs:7391:28)
    at Object.eval [as kv_reduce] (core.cljs:7633:6)
    at Object.eval [as cljs$core$IKVReduce$_kv_reduce$arity$3] (core.cljs:8197:50)
    at Object.cljs$core$_kv_reduce [as _kv_reduce] (core.cljs:719:16)
    at Object.cljs$core$reduce_kv [as reduce_kv] (core.cljs:2628:8)
    at hyperfiddle$electric$impl$runtime$parse_event (runtime.cljc:836:11)
    at eval (core.cljs:5750:36)

This is fixed by adding e/client:

(e/defn BindAccount
  [Next]
  (e/server
    (let [{:keys      [logout-url]
           :user/keys [account]
           :as        user-info}
          (try (session/Authenticate.)
            (catch Pending _ nil))]
      (if-not account
        (e/client (MountSpinnerAs. :BindAccount)) ;; <--

Why? (This is IC)

Dustin Getz17:12:34

To follow up – we have no idea, if you're up for reducing to a minimal repro we will prioritize it

👍 1

grounded_sage10:12:56

I tried migrating to IC last night and noticed a bunch of code now requiring e/client that didn’t before. Ultimately didn’t manage to port my code and going to revisit it later. Seems like IC requires being more explicit.

henrik10:12:24

It does require more coloring, specifically at the top-level of each function (as you can see above). I see it as kind of an improvement, as you don’t have to browse around to understand which context the code is executing in. So we kind of had this down as a practice before IC.

grounded_sage10:12:50

Yea I also agree that it is good to have this. I also have some hacks it is not happy with which is just a nice time to refactor.

henrik10:12:58

Yeah, IC seems a bit more temperamental in some cases. There are specifically two places in our code where the error, and the solution, makes no sense to me. I found the solutions just by blindly trying things.

henrik10:12:15

I plan to ask about them at some point.

joshcho11:12:48

Having the option to not specify would be nice. For some functions the context is very obvious

joshcho11:12:15

Forcing a style seems very not clojure-like

henrik12:12:29

If you want code that runs on client or server depending on where you insert it, you can always write a macro.

oh true

good pt

:saluting_face:

coloring is only required when platform specific forms are used, like (js/console.log …). Otherwise the form will be compiled for both sites. If it is not the case please report a bug

❤️ 1

grounded_sage17:12:07

With my code I wasn’t coloring a component when it was used in a parent component e/client form.

2023-12-15

Channels