The UI controls do this on purpose, otherwise a concurrent update (e.g. from another user) could flow in as you're typing and make a mess

I see. Is there a way to resolve this problem? This is a core feature in my app

if the strategy bundled in ui controls doesn't work for you you can roll your own with dom/input

ah right right

what is that fps monitor?

what if you weren't streaming logs but something mutable?

fps display is chrome

what is the mutable thing you have in mind to stream?

like if you're watching files instead of tailing logs, does differential have any impact on how you'd do it?

you’ll need to snapshot right? values over network

say you knew the memory layout of the robot, to read the state you map the memory into a struct, and then how does it go over to electric? have to write your own diffing protocol still (to do it efficiently) or does electric have an opinion on that

in this case a crane connector is translating the hardware structs and appending to a log; the structs arrive over a socket, the crane firmware is responsible for snapshotting the proper memory offset and writing to socket

so in your case you start with a discrete flow (socket), pre-diffed? what if you started with a continuous flow (file) too large to send over the network, does differential do/prefer anything special?

i'm guessing you'd still have to manually partition the flow into smaller flows for more efficient reactivity, differential doesn't help with that?

yes, you'll need to at least inject a diffing keyfn, i.e. imagine e/diff-by (i.e. the first stage of e/for-by)

if you are ingesting a batch data source like a file or sql resultset you probably just want e/for-by , which under Differential does the same thing as it did before just fancier internals

is this dev or prod? perf is very different local vs with network latency

this app runs on a LAN, but to your broader question, there aren’t any round trips so if network adds delay i don’t expect we would have a way to notice

makes sense

would it be more efficient to render all dom nodes at once as react tends to do?

I don’t know if every dom node corresponds to a network event or not, and whether they are logically a sequence, but if there are 8000 network events, the network latency kind of only applies to the first one. The first event to arrive will be delayed by 10/20/40/whatever ms, but after that they would arrive in roughly the same frequency as they were sent. Network latency is more of an “offset” than anything, when talking about bursts of events. Given a relatively stable internet connection. This changes if each requires an ack, which isn’t the case here.

Can't wait

@U06B8J0AJ good point!

if the payload is streamed

which is being explored here https://github.com/hyperfiddle/electric/blob/master/src/hyperfiddle/incseq.cljc

this demo is implemented with incseq actually, incseq is the work horse of electric v3, the rest is mostly just syntax and upgrading the electric runtime to use incseq operators everywhere instead of vanilla missionary

very exciting!