Fork me on GitHub

that is the best way in re-frame to to fetch data asynchronously (HTTP GET) from multiple resources, wait until everything fetched, transform all responses into one and then render it?


is there a way to hook into and listen to re-frame’s router in order to test if the correct dispatches were fired off in the following function:


@dd what would you be testing?


that the router correctly dispatches :A :B :C


as side effects


and not some other 😄


it’s just a function call? If function calls are failing then you’ve got big problems on your hands simple_smile


not smiley face


but “:D"


There are some cases where I have dispatch functions that will dispatch other dispatch functions depending on the input and logic


Just curious if you guys knew if there was a way to test if the router correctly calls the right functions


@danielcompton: btw thanks for the prompt response!


this function will go into the register-handler fun




@dd if you use core.async from handlers you would prevent any events processed by re-frame until all resources are fetched and processed


what I did was render a loading screen


call another fn that did the multi requests and then when it was finished dispatch another function with the payload


@dragoncube: nothing will be prevented from being processed, you will be running your core.async code in a go block, and the handler will have exited (remember to return a value for db!)


@danielcompton: and dispatch another event with result at the end of go block?


So we have something like

    [db [event-k]]
    (go (let [v1 (returns a channel)
              v2 (returns a channel)]
          (do something with both channels)
          (dispatch [:result value])))


@dragoncube: > if you use core.async from handlers you would prevent any events processed by re-frame until all resources are fetched and processed No, it won't block. The event handler will return (returning an unchanged db). Other events can then be processed, as necessary. At some point in the future that go block will itself dispatch the combined result of both HTTP requests, and that will be appropriately handled. (I'm looking above at Daniel's code as I write this)


@danielcompton: Currently APIs for simple/dynamic subscriptions are different as I understand - you have to pass dynamic sub arguments separately. Didn't you think to unify API somehow so caller could decide whether the subscription is dynamic or not? I guess it has some implementation difficulties.


@nidu: there’s a few reasons: 1. Implementation difficulties - It's probably doable, but would be more complicated 2. Performance - There are two reactions created for every dynamic subscription, and one for a normal subscription. It’s not a big deal, but nice to avoid if you don’t need it 3. Error handling - If we unified the v and dynv in subscriptions, then we wouldn’t be able to check if the user accidentally passed a static value when they meant to pass a dynamic value 4. API design - I think it should be immediately obvious to a reader when you’re using a dynamic subscription vs. a standard subscription. Unifying them would stop this. I guess I see dynamic subscriptions as the icing on a cake of standard subscriptions. They’re good to have, and you need them sometimes, but you don’t want a cake that is all icing If you did want to combine the two, you could register a subscription function with two arities to allow you to call subscribe with both static and dynamic values.


@danielcompton: good points, thanks for explanation


@dragoncube i use promesa with cats alet (aka applicative-do) for the async fetch graph problem. it's awesome


@mccraigmccraig: can you please elaborate a little? I am just thinking about something better, that I have now (cascade of dispatches)


@pepe: have a look at ... alet will work out the dependencies between intermediate results and do operations in "parallel" where possible - the disadvantage is that you don't get to see the intermediate results in your app-db


@mccraigmccraig: thank you, I will


@mccraigmccraig: promises doesn’t sound like FRP which is re-frame is for so mixing these two seems strange


@dragoncube: you are probably already going to use something like a promise or a promise-channel to get a response from an API... composing those is not entirely unnatural


i agree that it's kinda opaque, and that it would be nice to have some principled method of resolving the dependency graph in the app-db


i've only got one place in my app where i use this technique, which is during initialisation where if i don't get a few basic pieces of info from the api everything breaks - the alet technique saved me tearing out what little of my hair remains over specifying and managing the state-machine manually simple_smile


@mccraigmccraig: for me it is all across the whole app, in different kinds and variations, so I want to have cleaner approach


@mccraigmccraig: it is actually good you mentioned composability, it is one of the problems with cascade of dispatches - very bad composability and reusability. @danielcompton @mikethompson any thoughts on this? BTW, is it right observation that with re-frame it is all clean and clear while you writing custom handlers to to the things but once you start generalize things it starts looking like imperative style with global vars due to events like [:set-value :db-value-path actual-value]?


@nidu: yes, I read this wiki, it looks more or less like what I need but not sure if there are any caveats of doing it this way


Not quite sure what the question is @dragoncube


My guess is that Reuters used re-frame to build this:


Well re-frame can be found in sources


Strings like "re-frame: expected a vector event, but got: "


Sounds cool anyway!


so, don’t do event dispatches in a ubiquitous enrich middleware….


all operations on the db should be available as pure functions AND then if necessary registered as handlers…