How to use daiquiri.core/html ?

[xlisp]

Can not find this function :

@tonsky

[xlisp]

In the rum version "0.12.10".

[tonsky]

rum/src/daiquiri/core.clj

Lines 9 to 13 in 72c9535

	(defmacro html
	"Compile the Hiccup `form`. Always produces code that evaluates to
	React elements."
	[form]
	(compiler/compile-html form &env))

[xlisp]

Can this function only be required by the backend and then used?
Why does my front-end cljs require daiquiri.core, but the daiquiri.core/html function cannot be found.
@tonsky
I want to use a function similar to reagent as-element in rum: https://github.com/reagent-project/reagent/blob/master/doc/InteropWithReact.md

[tonsky]

I don’t know. @roman01la do you know this on the top of your head?

[xlisp]

I am quoting in the wrong way, because this is a macro, so I have to use require-macro😂, I searched the github code, and found that there is no project using daiquiri.core, I thought this thing can not be used, so I asked you.
@tonsky

(:require-macros
   [daiquiri.core :refer [html]])

[xlisp]

Another problem is that if I use rum and datascript as the front end, if I need to update the datascript data, I will update the rum component responsively:
The first way is to use (rum/react datascript-conn), like this code:
https://github.com/tonsky/datascript-chat/blob/gh-pages/src/datascript_chat/ui.cljs#L134 .
The second way is to use d/listen, and any data change will execute the rum update component.
I'm worried about performance issues with the first approach. Do you have any good recommended method? If there are a lot of datascript responsive update components. @tonsky Thanks ❤️

[tonsky]

Yes, I was thinking about fine-grained reactivity for DataScript, but nothing was implemented. Maybe one day :)

[xlisp]

@tonsky

For partial update components, there are actually some solutions, which I have tried. A specific datascript data can be updated to achieve partial real-time update. Like this project:
https://github.com/mpdairy/posh/blob/master/src/posh/plugin_base.cljc#L47

(defn posh! [dcfg & conns]
  (let [posh-atom (atom {})]
    (reset! posh-atom
            (loop [n 0
                   conns conns
                   posh-tree (-> (p/empty-tree dcfg [:results])
                                 (assoc :ratoms {}
                                        :reactions {}))]
              (if (empty? conns)
                posh-tree
                (recur (inc n)
                       (rest conns)
                       (let [db-id (keyword (str "conn" n))]
                         (p/add-db posh-tree
                                   db-id
                                   (set-conn-listener! dcfg posh-atom (first conns) db-id)
                                   (:schema @(first conns))))))))))

It uses a large posh-atom (reagent) and posh-tree as a proxy, puts datascript data into their memory, and then listens to the modified data of datascript through d/listen!, and modifies it through posh-tree posh-atom, so as to realize the partial effect of responsive update.

[xlisp]

But I think the implementation of the posh project is okay with fewer nodes. If there are too many nodes, there will be performance problems. Because all datascript data will be placed in reagent posh-atom, resulting in too much memory usage. This is a very rough way. Although it can look more elegant to use.
But if you don't do this, you need to write a lot of d/listen! Listening to different data changes and then updating the corresponding components is not so elegant for users.
I think the advantages of rum can be combined with datascript to better solve the partial update problem, or provide such other libraries.

@tonsky what do you think? ;-P