Clojurians Log v2

Thanks for the clarification @christian767! In the browser, does replicant do more? Especially what needs to be updated in the DOM?

Not sure what you mean by does it do more? Replicant takes hiccup and creates matching DOM. It then updates it as efficiently as possible on successive renders.

Is the "efficiently as possible" part by creating diffd to the current DOM?

I should probably go and read some code...

Ah, yeah. It tries to make as few changes to the DOM as possible to match the updated hiccup.

Sorry for being unclear.

Currently the compilation model is very basic: one file at a time without following require stuff, so require just gets translated to an ES import and that's it. Squint has better support for translating symbols to relative string imports in require if you use a squint.edn config file which cherry doesn't yet have. Having said that, you can just do this:

(:require ["./my_other_namespace.mjs" :as o])

and then compile the other namespace and that will work

so if I would like to import replicant, I'd have to go through all the replicant clj(s) files, and adjust the imports, correct?

would something like replicant compile with squint, do you think?

oh sorry, I thought you meant: other CLJS files in your project. Hmm, I don't think many existing CLJS dependencies will work as of yet with cherry to be honest. Since many of them depend on CLJS specifics like goog.* and cljs.compiler etc

not as is

what would be your use case for it?

thanks for the clarifications!

compared to compiling with normal CLJS I mean

I'm a deno-head, so I just so much like the idea of doing stuff without the jvm. But it's just a vain effort

you can use replicant with scittle as of today though

you have too many projects! I thought scittle was for clojure in script tags?

yes, I assumed you wanted to use replicant in the browser

since that's the natural use case for it

I'd like to use it for server side

just to generate some hiccup -> html? don't you think replicant is a bit overkill for that?

as a replacement for reagent

I thought replicant also wrapped all components into web components etc? Also, portfolio would be a nice feature

do you mean the web standard web components? then no

what replicant basically does is turn hiccup into dom nodes (client side)

on the server you can use it to generate HTML if you want to use it for SSR but just as a basic hiccup library, I think it's overkill on the server. the primary use case is client side. we have had this conversation before I believe

maybe I'm just misunderstanding what you're looking for, but wouldn't just a hiccup library satisfy your needs?

I haven't digged into replicant enough, but my hope would be that it provides a higher layer of abstraction over hiccup in the sense that the component wiring and referencing is taken care of when I use it. So I can write something like [:my-component] and convention makes it clear how the custom my-component is generated in the browser (registered as custom component). Also, I was hoping that replicant had support for updating only the parts that changed when client side state changed, so if I push some new state (just the state) to the page, it would update itself

I think you might be confusing replicant with projects like HTMX and datastar which do server -> client diffing. That's not what replicant does. Replicant builds the UI from a state and then diffs the current DOM against the to-be DOM like a virtual dom would.

Registering custom hiccup tags is possible with replicant, but with a normal hiccup library you can just write functions that generate hiccup and call those, no complexity needed.

(defn foo [] [:div "My component"])

(defn bar [] [:div "Another component" (foo)])

(hiccup/html (bar))

I'm not a replicant expert so I might have some details wrong. So let's just summon @christian767 again just in case.

going all in 🙂

@borkdude can't the diffing part be done on the server and then datastar be used to send patch messages to the frontend? so the flow would be "build initial ui"(in backend) ->"send to frontend"->"state changes"(on backend, might be because of datastar actions)->"replicant figures out what needs to change"(this is the part I'm trying not to do manually)->"datastar sends patch sse events to frontend"

"replicant figures out what needs to change" - this is really not the job of replicant on the server, this is what datastar is doing.

you can find a datastar sdk here: https://github.com/starfederation/datastar-clojure it even works in babashka

well I got this wrong I think, datastar itself also doesn't diff on the server. the idea is that you have parts of your UI that gets refreshed. datastar sends HTML only for that UI element. then on the client there is some DOM patching/diffing going on

but both replicant and datastar do not diff on the client SERVER I think

That's right 😊 Replicant on the server is just a hiccup to string library (as of now). It's useful if you have Replicant on the client (same hiccup dialect), otherwise it's probably overkill, like @borkdude said.

As for custom components. Replicant call these aliases. Their benefit over a regular function is to help DOM updates be faster by moving the realization to the latest possible moment, and to be able to serialize custom hiccup without sending functions. https://replicant.fun/alias/

I have some ideas for how Replicant could be more useful as a server side tool, but haven't gotten around to working on them.