Actually, I either need to wrap it in another e/server call

(e/server
 (e/client
  (let [!res (atom nil)]
    (js/chrome.tabs.sendMessage js/chrome.devtools.inspectedWindow.tabId
                                (clj->js {:action "do-sth"})
                                #(reset! !res (js->clj %)))
    (when-let [new-res (e/watch !res)]
      (e/server (println "!res changed" new-res))))))

(e/client
 (e/server (println "sth"))
 (let [!res (atom nil)]
   (js/chrome.tabs.sendMessage js/chrome.devtools.inspectedWindow.tabId
                               (clj->js {:action "do-sth"})
                               #(reset! !res (js->clj %)))
   (when-let [new-res (e/watch !res)]
     (e/server (println "!res changed" new-res)))))

answering from mobile - this is a common q, try searching the history

The upcoming next version which will internally work on differential data.

Wdym by differential data?

Diffs. E.g. instead of sending a collection you send "update 5th element to x"

differential electric is natively streaming, it works on streaming event sources (like LLM completions) natively. It fixes several implementation issues as well that were preventing Electric e/for from achieving optimal network IO and introducing unexpected latency

differential electric is a strong enough foundation to build ultradynamic responsive UIs like say microsoft word. By operating on flows of diffs instead of flows of values it basically means UI code never has to fullscan a collection, even large lists can be rendered without fullscan. Unlike e/for-by today which traverses the full list everytime any element changes

It is probably also a strong enough foundation to build reactive databases like Rama and Materialized in a small amount of LOC, though this is not our mission. Such a database could have an electric client/server split right through the middle of the query engine and indexes, potentially solving the local-first problem once and for all. In this worldview basically the DB and UI are unified and interwoven in the same way that client/server are in electric

so to the end user, extremely responsive and fast ui, and the programming model doesn't need to worry about how big our collection is? are there other benefits for the user?

ah so this will be huge for streaming with llms. i thought some parts of electric were already differential

e/for is, but the differential version will fix some issues it has

Will differential also be an option for strings, e.g. streaming building up a string? Workaround is trivial but

can you describe the use case?

llm streaming, building up a string via str

but a workaround is easy with a list of string tokens instead

if the string is rendered as text only you can just collect them and dom/text them in. If it's parsed and a DOM structure is built differential electric will help with that. No snippets to share on that yet though 🙂

Yes arbitrary differential collections including accumulating collections of strings (i.e, for rendering a table view based on a stream of strings)

@U09FL65DK I dont understand your statement

which part? Also, the question was "streaming building up a string", not accumulating collections of strings