Fork me on GitHub
#hoplon
<
2017-07-09
>
flyboarder02:07:36

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

meeli04:07:05

i am a ui/ux lady 😉

flyboarder06:07:17

@meeli even better 😁

thedavidmeister09:07:26

(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)))))

thedavidmeister09:07:44

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"]))

thedavidmeister09:07:58

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

thedavidmeister09:07:08

with my proposed fix = passing tests

thedavidmeister09:07:17

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

thedavidmeister09:07:25

initially it is "a"

thedavidmeister09:07:21

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

thedavidmeister09:07:46

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

thedavidmeister09:07:12

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

thedavidmeister09:07:04

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

thedavidmeister09:07:51

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"

thedavidmeister09:07:13

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

thedavidmeister09:07:41

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"

flyboarder18:07:24

@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

flyboarder18:07:56

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

flyboarder18:07:58

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

flyboarder18:07:03

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