Welcome @mfm

Welcome @yalu

thanks! @mynomoto

waves

howdy

so Alan and I had this case, where old = [1, 2, 3, 4] and new = [0, 1, 2, 3, 4] // and we were wondering if there was a way to do this using just 1 node-insert instead of 4 node-updates + 1 node-insert

We ended up considering this from the perspective of edit distances (as in gene sequence laignment); and stopped there.

ran across brenton ashworth's clj diff thing

along the way

this is a thing you need to manage in react a lot

they make it associative so you can diff efficiently

you add a primary key to each item

then it can compute the reshuffling

why did hoplon decide against a 'primary key' ?

well there used to be a :reverse true option

with the -tpl

that lets you insert from the other end

oooh i forgot about that

nobody ever used it lol

yeah one idea i had was to reverse in css

definitely crazytown tho

iirc, primary key != :reverse true -- since isn't it the programmer's job to specify the primary key ?

computing edit distange etc is NP problem i think

yeah the :reverse true solution is nicer in cases where it works

it's not NP problem

it's O(MN) worst, case and O(N d) if you know the edit didstanc eis at most d

if two sequecnes are of length M and N, it's O (M * N) via dynamic programming

if you know ahead of time the two strings differe by at most d diffs, it's O ( N * d) via dynamic programming

[I implemented one of these a few nights ago 🙂 ]

isn't that the complexity of the current naive way too?

I only know of one way, so it's probably the "naive way"

i mean in your example

M new nodes + N edits

O(MN)

there are also more subtle issues i guess

because this is the interface between mutable and immutable

// no, since in the second case, the two strings are of length N, (N-d to N+d), but the running time is not O ( N N), but O(N d), which is better when we know before hand that only 2 or 3 items changed //

so if N = 100, and d=2 (other string is ofo elgnth 98, 99, 100, 101, or 102), this is O(100 100) vs O(100 2)

strings are way easier than the dom

well than components

but either way, I do think having . a'priary key' is better

since components may be stateful

'edit distance' don't require strings; they can take any vector

like if you're typing in a input box, you want that dom object instance to stay associated with the thing you're wanting to type in

that is to say, replacing the input element with another one with the same contents is not good enough

because there is focus, etc

so you can't just rearrange things to minimize dom interactions

that's why hoplon doesn't try to do anyhting like that

the current setup is very simple to reason about

well as simple as we could make it anyway

in hoplon, if I createda list of textboxs, typed in one of them (but state not recorded in a ny cell), then I inserted a textbox at the top of the list; ... does hoplon preserve the browser input ?

sure

ah wait

you would need the reversey one in that case i think

I see; I guess, either case, this is not something that currently fits well in hoplon

the primary key approach could be doable i think

it would be like kv-tpl or something

i wonder if we could somehow protocolize the strategy

https://github.com/hoplon/hoplon/search?utf8=%E2%9C%93&amp;q=kv-tpl <-- where is kv-tpl ?

it doesn't exist (yet) 🙂

but some things to think about are like

(for-tpl [[i thing] (cell= (map-indexed list things))]
  ...

kv-tpl would basically be like react's primary key, and would solve all of my complaints 🙂

anyone here managed to use https://github.com/Day8/re-com hoplon? I like hoplon's frp model, but I also like re-com 's library

@qqq that's pretty much incompatible with hoplon. To use that you would need to mount the react root on some place in the dom that could be created by hoplon but I think that's pretty much it.

@mynomoto : now that you put it taht way, I don't see how this can work either

Well that is not composable with hoplon, but re-com create react elements, so you can mount that like any react thing. You create the dom node with hoplon then use something like (reagent/render-component react-component target-element)

I don't think that is a good idea, but it would work.