are there any UI/UX guys in here by chance?

@meeli ^^

@flyboarder hello

i am a ui/ux lady 😉

@meeli even better 😁

@flyboarder got some results

(deftest ??sorting-more
 (async done
  (let [data (j/cell ["a" "a" "b"])
        sdata (j/cell= (sort data))
        idata (j/cell= (into {} (map-indexed vector sdata)))
        rdata (j/cell= idata #(reset! data (vals %)))
        el (h/div
            (h/for-tpl [[k v] rdata]
             (h/input :change #(swap! rdata assoc @k @%) :value v)))
        read-vals (fn [el]
                   (map
                    #(-> % js/jQuery .val)
                    (-> el js/jQuery (.find "input") array-seq)))]

   (-> js/document .-body (.appendChild el))

   (h/with-dom el
    (is (= @sdata (read-vals el) ["a" "a" "b"]))

    (-> el js/jQuery (.find "input") .first (.val "c") (.trigger "change"))
    (is (= @sdata (read-vals el) ["a" "b" "c"]))
    (done)))))

FAIL in (??sorting-more) (:)
expected: (= (clojure.core/deref sdata) (read-vals el) ["a" "b" "c"])
  actual: (not (= ("a" "b" "c") ("c" "b" "c") ["a" "b" "c"]))

but

changing to

(h/input :change #(swap! rdata assoc @k @%) :value [v sdata])))

with my proposed fix = passing tests

pretty sure the problem is in the v cell in the first input

initially it is "a"

then you change the input to "c", which after sorting the underlying data cell changes the third v cell from "b" to "c"

after sorting the underlying data cell for the second input changes from "a" to "b"

after sorting the underlying data cell for the first input doesn't change at all, it is still "a"

however, the HTML element for the first input still has a "c" in it, because that's what the user typed

what we need is for the first input v to trigger a do! and overwrite the "c" that came from the user to match the state of that v cell after sorting, but the v cell can never do this on its own because its value never changes away from "a"

my proposal is to allow a change in sdata to re-trigger do! for all the v cells, whether or not those v cells have a new value

this is the relevant build on travis https://travis-ci.org/hoplon/hoplon/builds/251674451?utm_source=github_status&utm_medium=notification

atm i'm just noodling around with the do! mechanism itself, but i could also imagine it being handled as a special case within javelin itself - "propagate the value of cell X whenever any of cells Y or Z change, even if the value of X hasn't changed"

@thedavidmeister I still see that as the correct behavior, your example you don't ever want the value to change unless the user types something new, it should only reorder the elements

Attributes are a 1:1, their do! Should only trigger when the data changes

Since you want to force it to update based on another bit of state, that would suggest the state isn't being tracked the way you are imagining it

The order and the value should both be in the same cell that your -tpl macro is tracking