This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-19
Channels
- # admin-announcements (2)
- # beginners (24)
- # boot (36)
- # business (1)
- # cbus (3)
- # cider (22)
- # cljs-dev (91)
- # clojure (101)
- # clojure-canada (9)
- # clojure-china (3)
- # clojure-czech (21)
- # clojure-nl (3)
- # clojure-russia (131)
- # clojure-sg (5)
- # clojure-uk (9)
- # clojure-ukraine (4)
- # clojure-za (2)
- # clojurebridge (18)
- # clojurescript (333)
- # clojurex (6)
- # devcards (1)
- # events (37)
- # hoplon (15)
- # ldnclj (23)
- # luminus (3)
- # off-topic (41)
- # om (258)
- # onyx (20)
- # re-frame (46)
- # reagent (7)
- # spacemacs (2)
What’s the best way to reset forms with uncontrolled inputs?
i am seeing two events in the logs one after another but the second event app-state is not the result of the first event
@shaym can you show the line after this showing the only after for :generic-get-response
?
@danielcompton: utils.js:6 only after : {:data {:acme123 {:_id "acme123", :name "acme123"}}}
@shaym I’m guessing that it’s an artifact of an empty map being treated as nil by the data diff
@danielcompton: hmm i was suspecting it also , ill try running some tests with a {:content "content" } marker instead of an empty map
yeah, or just print the map before you run the body of :generic-get-response
@danielcompton: is there any issue with dispatching handlers from within a subscription?
You probably shouldn’t be doing that
don’t cross the streams
@danielcompton: how would you suggest implementing it
good question
In the app we’re working on, remote data sources stay as subscriptions, i.e. we subscribe and get data in the subscription, but it doesn’t get put into app-db
But that’s not applicable everywhere
at times it works really nicely , i.e the recation returned by the subscription is initially empty , but then when the ajax call returns , it all updates "automagically"
@danielcompton do you have a code example for that. We currently put everything in app state
@shaym the issue with lazy loading is how you garbage collect it in the end?
otherwise your app-db will just keep growing
@danielcompton: i plan to add garbage clean , but for now im hoping state would not be too huge
@danielcompton: i really like the article http://tonsky.me/blog/the-web-after-tomorrow/ by tonsky
@mitchelkuijpers: I don’t have a clean extractable example for you, but the gist is you make a subscription which returns a blank ratom/reaction. It runs a query asynchronously and when the response comes back it updates the Reaction.
@shaym yeah it’s a good one
A thought off the top of my head would be to setup a bunch of lazy loaded subscriptions in app-db from a handler, then when you subscribe to them they get realised
although that’s mostly a semantic difference. I haven’t looked at how Elm does it, but there’s probably some smart ideas over there
maybe a non UI related handler , that has a subscription on a queue of ids to load , and trigger ajax calls for them
Thnx @danielcompton never realized I could do this
@shaym I think there’s definitely a good case for doing this, I’m just not sure exactly what it is
@shaym actually, I had a thought. When you setup a page, you could run a bunch of handlers to fetch data, that no-op if the data is already present. However that’s still not quite right
@danielcompton: yes that is an option , but it will spread the fetch calls all over the app and make them page specific , having a generic handler makes it a single point of contact
for sure, I think this was why we went down the route of subscriptions for remote data