Clojurians Log v2

https://github.com/orestis/reseda/blob/master/src/reseda/demo/nasa_apod.cljs

Here’s finally my working version of useMutableSource - flavored state in global atom.

Essentially: put your state in an atom, subscribe to changes via functions, your component rerenders.

Concurrent Mode friendly, but there is a stable flavor of the api too.

I still need to test that it works with the currently stable React, but I’m pretty certain it does with the few code changes.

Baby woke up just as I pushed so need to delay any further exploration 👶:skin-tone-2:

looks neat!

do you feel the protocol indirection adds a lot of value yet?

compared to e.g. a hook that wraps an atom with useMutableSource directly?

Is there a way to get a list of all the watchers of an atom?

But mainly I want a protocol so I can do things like support custom equality functions per subscription, tooling, and so forth.

Am I correct in understanding that reagent does not pre-compile hiccup templates at all? couldn’t find indication in docs/code that it did. The reason I ask is cause declaring components as vectors of data (versus function calls) has grown on me now that I’m more familiar with Clojure. Could similar performance as Helix not be achieved by pre-compiling hiccup too? @lilactown I guess this would be more inline with your experiments with Thump, though it seems like data readers aren’t fully supported*, nor recommended, in shadow-cljs. but same could be done with one initial macro call. here’s what i’m experimenting with now

(r/h [rn/View {:style []} 
        [rn/Text "Foo"]
        [rn/Text "Bar"]])

($ rn/View {:style []}
     ($ rn/Text "Foo")
     ($ rn/Text "Foo"))

yeah. reagent doesn’t do anything at compile-time

you could create a macro to do it, but yeah it gets a little unwieldly when it’s not just a static thing

(r/h [rn/View
      (if something?
        (r/h [rn/Text "Foo"])
        (r/h [rn/Text "Bar"]))])

you also have to handle compiling all the same props stuff as helix’s macros

if you want, you could re-use helix.impl.props/native-props and helix.impl.props/props

would almost be same in Helix though, no?

($ rn/View
   (if something?
     ($ rn/Text "Foo")
     ($ rn/Text "Bar")))

yeah, helix is sort of a “lowest common denominator” you always have to call the macro

like users might be inclined to do

(r/h [rn/View
      (if something?
        [rn/Text "Foo"]
        [rn/Text "Bar"])])

which will throw a runtime error because you’re handing a vector to react

@alidcastano take a look at hicada which achieves this pretty well

Actually, I have an example of using it with hx

https://git.sr.ht/~severeoverfl0w/hxadapound

@dominicm thanks will take a look @lilactown my thinking is hiccup could provide better alternative for composing than just function calls, so exploring ways of overcoming drawbacks. from research yesterday discovered clojurescript’s inferred-type and saw that helix also uses it. maybe that could be used to guard/prevent those runtime errors

you might be able to but it relies on CLJS type inference which is a black box to me

my current feeling is that if I change from using $ to something, it will be using factory function

so

(rn/view
  (if something?
    (rn/text "foo")
    (rn/text "bar")))

but that’s only for primitive components

you can do it for anything

oh with a factory function yeah. but that’s more boilerplate

(defnc MyComponent [props]
  ,,,)

(def my-component (helix.core/cljs-factory MyComponent))

i really liked the idea of using reader literals because they made the conversion really transparent, and makes using #js less awkward for me

wish they had more support in shadow-cljs

does thump not work in shadow-cljs?

i tried following the way you setup it up in thump but couldn’t get it working

and found an issue with @thheller saying he doesn’t recommend them

because of build caching and that you can just use macro call

i remember there being some tricky stuff with the namespace dependency graph

there should be a way to write something like thump which doesn’t get hurt too badly by that

cool thing about reader literals is that they’d make other conversions really transparent, like in React Native converting styles had something like this in mind

#r/h [rn/View 
        [rn/Text #js {:style #r/sh [:ai-c :flx-1]}]]

yeah, I like the aesthetics of reader literals for things like react elements, I think they map well to JSX. but right now I feel good just using $ everywhere so not something I’m going to invest a lot of time into personally

happy to provide any advice if you want to fix up thump / create a lib that better supports your use-cases w/ helix

thanks, will let you know 🙂

this is actually similar to what I was trying to do… except I was writing it myself without helix and hicada 😅 thanks for the reference

What's the story for using react with shadow dom? Or web components?

I'm finding I'm struggling a bit with how to best manage css

@didibus I would either use postcss or https://emotion.sh/docs/introduction

shadow dom and web components shouldn't have much to do with CSS though, they are orthogonal