Clojurians Log v2

you want to e/watch the datomic connection, not directly but rather you need to implement the tx-listener API - search history here and in missionary for some snippets

determining which queries to maintain is "your problem" (choose a streaming database if you want realtime queries everywhere) BUT missionary and electric give you the concurrency power you need to build an adhoc solution

Same problem here: cookie gets set, but I don't seem to get logged. The rest of this conversation is way above my head for now 🙂

action required, entrypoint fix is in userland (starterapp entrypoint) not electric itself, see https://clojurians.slack.com/archives/C7Q9GSHFV/p1738591790727399

Ran into the same problem when trying to inject variables into the request via middleware for consumption by my Electric code.

we're fixing, sorry

if you need an immediate workaround you can inject by global side effect

No worries. Yeah—that's what I'm doing. Running into other issues getting streaming working with Datomic. Reading Missionary docs and poking at the Datomic browser code.

I prefer the blocking APIs, e/Task and ex/Offload-latch give you primitives to move work to a thread and await

you can of course be macho and integrate the streaming APIs

(d/datoms db :aevt :db/txInstant) seq-consumer (m/reduce conj ()) e/Task is hitting an async datomic API but immediately just waiting for it to finish before handing off to the UI

What I'm building right now is fairly basic CRUD. But I would like to see entities I create in the REPL flow straight through to the view in the browser.

looks like e/http-request is always nil

same issue on https://electric.hyperfiddle.net/tutorial/chat_monitor

yeah thanks we can repro

In Electric v3 let statements do not execute the right hand side of a binding unless you use its value somewhere else

So this will print:

(let [x (println 42)] x)

(let [x (println 42)])

If I remember correctly, then the reason is to avoid accidentally data transfer between client and server.

(e/server (let [x (e/client 42)] (e/client (println x))))

There were issues, that destructuring in let bindings caused accidentally data transfer. I am not sure, if these have been solved or if the advice is to avoid destructuring if let spans client/server boundaries.

(let [x (prn 1)] x ...) will sample the prn, see https://electric.hyperfiddle.net/tutorial/fizzbuzz

with respect to destructuring, you just have to be aware of which site is doing the destructuring. Broadly speaking, the goal of Electric is not to forget about client/server, but to give you tools with surgical precision that allow you to reason about client/server topologies with fine structure (and thereby avoiding the whole ORM situation, which attempts to magic over IO and of course fails)

for example, v3 is now rigorous enough in its transfer semantics that we turned on "throw exception on unserializable reference transfer" and none of our apps broke

@dustingetz Is it ok, if I create a PR for the electric-starter-app?

Hi, just read the link. Are you sure this is a good idea?

Re the electric3-starter-app, it currently does not have any NPM deps, and we generally prefer to keep it as simple as possible because users already complain that it contains too much code

it would mimic the default behaviour of shadow-cljs cli tool. However, I understand that you want to keep the repo as lean as possible.

Maybe what we should try is - we will add these two lines and comment them out, and internally we can try running with these lines on for a bit and see if there are any issues

a couple other things we have to avoid: • users see package.json and think electric has js dependencies, which it does not • users see react.js in packjage.json (for like, an integration demo) and assume we depend on react.js - yes, we really do get this question, people don't read stuff • increasing our support surface area when it doesn't work - users start using us as front line support for their clojurescript problems, which causes all sorts of social problems

• users thinking electric is slow because they had to wait for npm

These are valid reasons. I guess that it is best to not include the npm lines to not confuse users. I’ll update my libs readme and document the diverging shadow-cljs behaviour there.

hmm, i dont understand what you need to document, given that electric3 doesn't have a package.json

does your library include the package.json?

I must be missing something

in my mind i imagine your library having a demo repo, and that demo repo includes a deps.edn and a package.json and a readme. Your repo can also provide the custom shadow configuration

does your library include the package.json?

in my mind i imagine your library having a demo repo, and that demo repo includes a deps.edn and a package.json and a readme. Your repo can also provide the custom shadow configuration

oh, shadow has implemented transitive deps across clojure jar files

Yes, you can fork electric*3*-starter-app, we rarely change it, i recommend adding it as an upstream git remote so you can see changes

There it is 🙂 https://github.com/HendrikLevering/electric3-threejs-demo