twitter thread with video: https://x.com/nathanmarz/status/1694046536861368594?s=61&t=lI9nNO9bkbL1YKFrdIw_Tg

Video only: https://www.youtube.com/watch?v=jcvxGvzjLHg

Hopefully they’ll relent and give access to the Clojure API, because building a bespoke Clojure API around a Java API around a Clojure API is silly.

I'm new to following this stuff. Can anyone tell me how Rama relates to electric? Is it another take on the idea of combining front and backend, or somehow complimentary?

It looks like it's a paradigm similar to differential dataflow?

it is complimentary, rama data tier to electric UI tier is a native fit

in theory at least

Am i right that its a framework for streaming incremental updates to data similar to differential dataflow then?

i don’t know if rama “subindexing” is actually differential dataflow or not (i doubt it and i think that’s probably a mistake). I can say that the next major version of Electric is indeed differential dataflow

certainly rama is similar to and competitive w DD

It is no coincident that when you see the Paths in the demo that they look like Specter, because they are both supported by the team. I would think this could mean that a RAMA Clojure implementation could be on the cards.

Rama is written in Clojure, so it already exists. The “native” API isn’t exposed though.

I was just looking at the video where it is all Java, seeing the groovy examples, immediately makes you want to usea Clojure variant as it would be much simpler.

Like, they call $$… “vars”. Probably because they are vars in the Clojure API language.

The code that is written in their examples, is really hard to understand as you are using one language to write another, I would image that macros, could be created to make it simpler to create the code more directly. Having worked in solutions where you are generating code from code, you find the debugging the emitted code is complex as you don't have the support of IDE etc.

@dustingetz Do you imagine subindexing being DD or not would surface in the API, or more of a mistake regarding the efficiency of the internals?

The examples certainly do some contortions due to (I’m guessing) the limitations of Java. Variables being strings beginning with */`$$`, and if you want a literal string with those prefixes you must wrap them in Constant comes to mind.

From #rama: https://github.com/dundalek/rama-clj-playground

I stumbled on a line where they mentioned the importance of ordering, which is a prerequisite for timely dataflow

the differential dataflow end user programming model, as I understand it and as we are implementing it in Electric, is FRP like and DAG based (in Electric you build your app out of lambdas and closures). As opposed to the Rama end user programming model where you program with structs and you have to plan out the data structures. My initial impression is Rama feels like intrusive data structures in C as opposed to generic data structures in Java. Faster but lower level, used in operating systems and games. https://stackoverflow.com/questions/5004162/what-does-it-mean-for-a-data-structure-to-be-intrusive

DD exists at a different abstraction level, too. It's about sets (signals? maybe), not about a specific value or a specific time

can you be more specific?

When syncing text data from server to client, we need to keep track of whether the server’s data is outdated by comparing versions. If the incoming data is outdated, then the client state won’t be updated. To prevent a function from being updated in electric context , we need to calculate the previous value. Is there a recommended way to achieve this ?

Say we have:

(e/defn my-func [a b] (+ a b) )

(e/defn my-func [a b] (if block-condition previous-value (+ a b) )

> When syncing text data from server to client, we need to keep track of whether the server’s data is outdated by comparing versions How does this situation arise? Electric doesn't produce out-of-order data. Is your server sending old data to the UI?

to also answer the broader question (how to act on previous values), it is typical to introduce state here (an atom)

(let [!v (atom 0)]
  (when condition (reset! !v (+ a b)))
  (e/watch !v))

> How does this situation arise? Electric doesn’t produce out-of-order data. Is your server sending old data to the UI? The outdatedness is defined in our application domain, not in system level. We try to implement an offline-first model where there are n+1 copies of data. And we annotate different copies by version and event-time to resolve conflict.

> to also answer the broader question (how to act on previous values), it is typical to introduce state here (an atom) Ah I see. Thanks for showing this method.

note that state and recursion are deeply related and/or the same thing. Consider a Java for loop with mutable accumulator vs reduce

So, I hope next year we can eliminate the need for an atom here, but it is not a priority, and i don't find the atom to be problematic for this reason

Okay, I see your point

I did see that in deps.edn, we have an older version:

:dev
  {:extra-paths ["src-dev"] ; fix uberjar java.lang.NoClassDefFoundError: clojure/tools/logging/impl/LoggerFactory
   :extra-deps
   {...
    thheller/shadow-cljs {:mvn/version "2.22.10"}}

We saw this. We suspect a corrupted .shadow-cljs cache. We are not yet clear on the root cause. You can try to • stop the shadow process (not just the build, stop the JVM) • rm -rf .shadow-cljs • restart the shadow build It’s worth noting we only saw this behavior with watch, never with compile or release

Hey, thanks for answering: • ✅ remove the cache .shadow-cljs • ✅ stopped everything • 🔴 clj -A:dev -X user/main

failure again, same error

I see WARN app.server: Port 8080 was not available, retrying with 8081, could there be a second shadow process running ?

no, that's an nginx, I can try without it

from something else

I can reproduce the issue with a clean repo clone. Looking into it

thank you. My use case of using electric is very much dependent on datomic so I thought I could start from this example

I do not recommend starting here, we haven't touched it in ages

I did host it this week, and am working on unifying how builds work in our dozen or so repos this week

but your first day using electric should be the starter app

Though now that Datomic is free, I'll make the starter app use Datomic

If you want the contributor badge lmk and you can send a PR if you like

We have a minimal repro for the shadow build issue. We’ll address it. Thank you for the report 👍

running into the same issue

as is this user https://clojurians.slack.com/archives/C6N245JGG/p1691177869837179

FWIW, I’m getting this with v2-alpha-422-g96e5c0a5 as well.

We clear .shadow-cljs on every start, so that’s not a viable workaround, it seems.

I pushed a new commit which fixed this on my end, can someone from this thread double check on their end? The git coords to use are

io.github.hyperfiddle/electric {:git/sha "22937f751db7258ac0be0337833c036dbc4879f2"}

fixed it for me

new maven coordinates are out

since an e/fn has the same structure as a clojure fn it should be doable. I'm not sure how malli checks functions and how much effort it would be though. Are you familiar with malli's internals?

I am not unfortunately; I'm just now trying to integrate it. I may resort to just using instrumented validation inside the functions for arguments, as many of the other feature of function schemas likely aren't applicable to Electric. (Generative testing, generation functions, etc.)

Most of the function schema/instrumentation functionality likely won't work, as Malli expects to work with plain functions which it can wrap in another fn. (Which then wouldn't have the Electric metadata)

Or varargs for that matter

varargs are actually just released yesterday to clojars i haven’t announced it yet, see change log

Oh, nice 🙂

condition. maps- no, i’ll add a ticket. Our compat maturity is currently adhoc we implement what we need. When we come up for air (after differential electric, incremental builds, optimistic ui) we will perhaps make a compatibility matrix and ratchet it down

👌 Makes sense; thank you 🙂

v2-422 (about to announce) has several compat impeovements

This feels like a reasonable usage for Malli validation of function inputs

(e/defn Button [& args]
  (let [schema      [:catn [:x string?]]
        {:keys [x]} (m/coerce schema args)]
    (dom/button
      (dom/text (str "Click me! " x)))))

I can come up with a minimal reproduction if it's not immediately clear what might've changed about this behavior.

we will take a look, might not be until tomorrow sorry 😕

from a quick glance - that's a lazy seq, does making it strict fix the issue?

i dont see how that could actually be something that changed

The bindings? I don't think they have anything to do with it.

Ok, I'll verify that it's the version change that caused it.

Oh, i believe that it could be a breaking change in v2-422

Hmm, this does appear to work in isolation, so it may not be the initial problem I thought it was.

(def start-reactor
  (let [node (js/document.createElement "div")]
    (.appendChild js/document.body node)
    (e/boot
     (binding [dom/node node]
        (core/App.)))))

I'm not sure why the dom/node binding isn't working as expected in the full example though. :thinking_face:

is there react/reagent interop?

No, nothing like that

Adding a breakpoint here, is it expected that a child text type would be called first before the parent button?

parent is undefined for both calls 😕

parent should not be undefined

i dont seem to be looking at the same code as you because core/App is not defined

https://github.com/garrett-hopper/ElectricStorybookExamples/blob/main/src/app/core.cljc

I'm sorry. I think I was just being dumb and had a component being mounted inside dom/text. :man-facepalming:

where

Not in the macro I sent you, but where I'm using it, at some point I'd tried to test something and apparently ended up with

(defbook Button
  (dom/text (Button. 5)))

So when Button when to mount, it obviously didn't have a parent since it's in a text node

and you're saying this worked in v2-349?

No, I don't believe so. I think it was around the same time that I had upgraded that I was also doing the :pre/:post testing and instead of Button, I had an electric function that actually returned a string rather than trying to mount child components. Entirely user error; I apologize 😕

ok