This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-04
Channels
- # beginners (8)
- # boot (20)
- # cider (8)
- # cljs-dev (263)
- # cljsjs (8)
- # cljsrn (20)
- # clojure (151)
- # clojure-argentina (1)
- # clojure-belgium (7)
- # clojure-dev (18)
- # clojure-italy (25)
- # clojure-spec (34)
- # clojure-uk (15)
- # clojurescript (89)
- # component (45)
- # core-async (27)
- # cursive (16)
- # datomic (53)
- # emacs (40)
- # figwheel (3)
- # hoplon (62)
- # jobs (1)
- # jobs-discuss (7)
- # luminus (8)
- # lumo (60)
- # off-topic (3)
- # parinfer (1)
- # precept (1)
- # protorepl (15)
- # re-frame (37)
- # reagent (7)
- # ring (3)
- # ring-swagger (73)
- # slack-help (1)
- # specter (19)
- # sql (4)
- # test-check (10)
- # uncomplicate (2)
- # unrepl (14)
- # untangled (52)
- # vim (5)
- # yada (42)
@thedavidmeister am I understanding correctly that you are sorting input fields?
based on what the user types into the input field
or clicks, actually in my app it is number fields
so they can click up and down in the widget
Iām not sure I understand, you want to sort the form fields as you type into them?
it can be on blur, same bug happens
the exact event that updates the backing data isn't important based on my testing
@thedavidmeister can you provide a snippet? From your issue description this sounds like correct behaviour
@flyboarder there is a PR with passing/failing tests
you can see from different commits the issue
@flyboarder see https://travis-ci.org/hoplon/hoplon/builds/249609600?utm_source=github_status&utm_medium=notification
@thedavidmeister ok so I just did a bunch of reading of the old issue and the new one you opened, from what I can tell you are looking for lenses
i don't think so?
since 2-way data binding isnt allowed in hoplon/javelin, the correct way to manage the state would be to use an intermittent cell
can you give an example of how i should set this up?
@thedavidmeister do you have a snippet of your element?
yes, in the PR
+(deftest ??sorting-elements
+ (async done
+ (let [data (j/cell {:a 1 :b 1 :c 2})
+ sorted-data (j/cell= (sort-by (fn [[k v]] [v k]) data))
+ el (h/div
+ (h/for-tpl [[k v] sorted-data]
+ (h/input
+ :data-k k
+ :value [(j/cell= (get data k)) sorted-data]
+ :input #(swap! data assoc @k (int @%)))))
+ read-vals (fn [el]
+ (map
+ #(-> % js/jQuery .val)
+ (-> el js/jQuery (.find "input") array-seq)))
+ read-ks (fn [el]
+ (map
+ #(-> % js/jQuery (.attr "data-k"))
+ (-> el js/jQuery (.find "input") array-seq)))]
+ (-> js/document .-body (.appendChild el))
+
+ (h/with-dom el
+ (is (= ["1" "1" "2"] (read-vals el)))
+ (is (= [":a" ":b" ":c"] (read-ks el)))
+
+ (-> el js/jQuery (.find "input") .first (.val 3) (.trigger "input"))
+ (is (= {:a 3 :b 1 :c 2} @data)) ; passes
+ (is (= [":b" ":c" ":a"] (read-ks el))) ; passes
+ (is (= ["1" "2" "3"] (read-vals el))) ; fails with ["3" "2" "3"]!
+ (done)))))
soz, that's an old commit
(deftest ??sorting-elements
+ (async done
+ (let [data (j/cell {:a 1 :b 1 :c 2})
+ sorted-data (j/cell= (sort-by (fn [[k v]] [v k]) data))
+ el (h/div
+ (h/for-tpl [[k v] sorted-data]
+ (h/input
+ :data-k k
+ ; :value [v data]
+ :value v
+ :input #(swap! data assoc @k (int @%)))))
+ read-vals (fn [el]
+ (map
+ #(-> % js/jQuery .val)
+ (-> el js/jQuery (.find "input") array-seq)))
+ read-ks (fn [el]
+ (map
+ #(-> % js/jQuery (.attr "data-k"))
+ (-> el js/jQuery (.find "input") array-seq)))]
+ (-> js/document .-body (.appendChild el))
+
+ (h/with-dom el
+ (is (= ["1" "1" "2"] (read-vals el)))
+ (is (= [":a" ":b" ":c"] (read-ks el)))
+
+ (-> el js/jQuery (.find "input") .first (.val 3) (.trigger "input"))
+ (is (= {:a 3 :b 1 :c 2} @data)) ; passes
+ (is (= [":b" ":c" ":a"] (read-ks el))) ; passes
+ (is (= ["1" "2" "3"] (read-vals el))) ; fails with ["3" "2" "3"]!
+ (done)))))
@flyboarder the problem is that the final sorted data looks like [1 2 3]
but the UI shows [3 2 3]
because the cell containing 1
for b
does not change so it does not trigger do!
even though it "moves" somewhere else in the DOM
at least i think that is what is going on
i don't have a good understanding of the nitty gritty going on under the hood, just that if v
doesn't change then do!
is not triggered and so you see a "stale" DOM element somewhere
i'm totally willing to accept this as the "correct" behaviour if i get an example showing how i "should" be handling this situation š
@thedavidmeister right so your second state should be outside your loop-tpl, any state which changes while in a tpl should be inside the cell it tracks
what do you mean?
the issue is you are tracking two sets of state, which is a no no
can you please provide a code example?
yeah im trying to come up with something XD
this is how I like to remember -tpl macros, the cell they track is a collection of element states
the data you want to sort is actually an attribute value of the element state
but isn't it common to want to sort a collection based on the attributes of the things in the collection?
actually, i'm not aware of any other way to sort a collection š
Sort seems to be a thing we should be able to generalize, I'll throw together a pattern and do a snippet, I think there are a few cells/attributes we can provide to simplify this.
@flyboarder happy to explore ideas
ultimately i think that if there are things in the DOM that are read/write, there will continue to be edge cases where you need to to be able to trigger do!
based on more context than just "does this one cell change?"
i think "generalising sort" is just kicking the can down the road
but it might help us get a better grasp on the details of the problem and what our options are
unless you make it so rearranging cells actually rearranges DOM elements, rather than simply mutating attributes in place to simulate position changes
(defn path-cell [c path]
(cell= (get-in c path) (partial swap! c assoc-in path)))
(def page (path-cell app-state [:page]))
and then I'm deref-ing page as an argument to an ajax-request function to get me paginated responses from backend
question is, why doesn't it automatically trigger a rerender when I click on a different page and swap! page (:page query-params) ?
it is my understanding that it should automatically request a new response from backend
you can do like (cell= (pr :updating app-state))
to see when the lens is triggering a change
if i understand your setup correctly, i think i'd have the update fn in the path-cell lens call the remote endpoint
like the XHR could populate a different cell or a different place in the app state with info about any errors if it fails