Hi Dan This would work, and I think from memory this is one of the approaches we have tried in the past (a little bit different as the subscription was returning the reduction over a RethinkDB changefeed query). The main issue is that sooner or later you want that data to be available to you in your app-db to do things with it in your event handlers. You can pass it through the view into your event handler, but that can start to get unwieldy.
> If you start with the attitude that the external service is functional - i.e. it gives the same answer every time given the same parameter The service may be functional, but it is still a stateful action. Give it a go, if it works for you then that's great, but it doesn't quite fit with the re-frame philosophy of all your data being in app-db, and you may run into issues down the track. I'd be interested to hear your experience more either way though. On Fri, Sep 21, 2018 at 9:44 AM <daniel.r.bar...@gmail.com> wrote: > From reading the doc at > > https://github.com/Day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md > it looks like the two "normal" patterns for getting data from external > sources are > > (1) a subscription handler to trigger the request and return a path in the > app state, coupled with a callback that dispatches an event > to populate that path when the external service responds > > (2) an event to trigger the request and another event that dispatches when > its callback runs, to save the response somewhere in app state > > and then there's some sternly worded advice against putting this stuff > into view functions, with which I concur absolutely > > My question is: why put the results into app-db at all? If you start with > the attitude that the external service is functional - i.e. it gives the > same answer every time given the same parameter, then what if you had a > subscription handler that returned a reaction with the results of the > external service call? I'm thinking something like this: > > (defn get-search-results-from-server [term handler] > (ajax-request > {:method :get > :uri "/search" > :timeout 5000 > :params {:q term :limit 25} > :format (ajax/url-request-format) > :response-format (ajax/json-response-format {:keywords? true}) > :handler handler})) > > > (rf/reg-sub-raw > :search-result > (fn [db _] > (let [out (reagent/atom [])] > (ratom/run! > (let [term (rf/subscribe [:search-term])] > (when-not (str/blank? term) > (reset! out []) > (get-search-results-from-server > term > (fn [[ok? new-value]] (and ok? (reset! out new-value))))))) > (reaction out)))) > > > - i.e. it's just another subscription handler that sits somewhere in the > middle of the signal graph and computes things, albeit that it computes > them very slowly. > > > It seems to work in my app (see > https://github.com/telent/epsilon/blob/master/src/epsilon/client.cljs#L217) > but my understanding of ratoms and reactions right now is very superficial, > so it's not beyond the bounds of possibility that it only works by > accident. > > Thanks, by the way, for a very lovely bit of software and some exceedingly > good documentation around it > > -dan > > -- > You received this message because you are subscribed to the Google Groups > "Reagent-Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to reagent-project+unsubscr...@googlegroups.com. > To post to this group, send email to reagent-project@googlegroups.com. > Visit this group at https://groups.google.com/group/reagent-project. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Reagent-Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to reagent-project+unsubscr...@googlegroups.com. To post to this group, send email to reagent-project@googlegroups.com. Visit this group at https://groups.google.com/group/reagent-project. For more options, visit https://groups.google.com/d/optout.
