Clojurians Log v2

ha ha yes we are here to solve crud

Given this docstring:

hyperfiddle.rcf/tap
  
Function to push value to async queue, e.g. `(tap 42)`. RCF redefines this var in tests context. For REPL
convenience, defaults to println outside of tests context.

have you tried with rcf/tap?

Good thought, just tried it though with no dice.

Gist updated with namespace block and explicit rcf/tap

https://nextjournal.com/a/NTjCrqnd9e4PwVMkTNXwqG?token=TDCPrryU5DGgSUWu6kirHe

The docstring is misleading. rcf/tap is rebound in the context of tests, but not as a clojure dynamic binding. Here is a workaround:

(def ^:dynamic *tap* (constantly nil))

(defn client-connect []
  (m/observe
    (fn [!]
      (*tap* [:connecting])
      (! :a)
      (*tap* [:connected])
      (fn []))))

(tests
  (binding [*tap* rcf/tap]
    (let [cancel
          ((m/reduce {} nil (client-connect))
           {} {})]
      % := [:connecting]
      % := [:connected]
      (cancel))))

Got it. Should I open an issue? Or is this working as intended?

I think the behavior can be justified. The docstring could def be improved. Up to you if you want to open an issue.

Cool, makes sense. Thanks for the workaround, I think I'm unblocked. It gets a little messy when threads are thrown into the mix – I've updated the nextjournal to demonstrate.

you'd have the same issues with clojure.test/is

if you really need to you can pass it lexically

(defn client-connect [tap] ... (tap [:connecting]))
(tests ... (client-connect tap))

For internal tools that just need to look “good enough” I’ve used https://bulma.io/ It’s CSS only (no JS) so easy to use with Electric without any special wiring

At Itonomi we're building an Electric component system based on the Norwegian government's design system https://designsystemet.no. https://github.com/itonomi/komponentkassen

I've also done some experiments with writing very high-level components. For example a full-stack log in / sign up page as one higher-order Electric function. iirc it had a form something like (e/fn Authentication [LogIn SignUp] ...) so that you only provide the callbacks to hook into your auth system and the rest was handled by the Electric component. There's definitely a lot to explore in this area, I think 🤓

Got it, thanks @post972! Will check this out.

Cheers

I should say this is very much work in progress, but I'm very interested in feedback and discussion 😄

Several teams, including us internally, are building component systems - ideally headless so you can BYO markup. We have one that we use on projects but it's sophisticated and in motion so consulting projects only at this point

I would not say this is necessarily a one size fits all situation either, there are dozens of different React ecosystem choices