Fork me on GitHub

not so much 🙂 ... i'm still struggling to conceive of a way to structure reliable api queries in a way which doesn't use subs to determine which queries are still active (and thus should be retried when network comes back)


I'm trying to use a react component that expects a callback that eventually returns some data, but it seems to me that in general with reframe we dont actually ever return data with our dispatched events- is there a way I can force data to come back from these callbacks instead of just affecting the app db? My nouns may be completely wrong here. previously all the callbacks (onclick etc) that I've had to do worked completely fine with how I'm using reframe since generally it kicks off an event, some things happen, and then change in data causes subscriptions to change how things look, but this component specifically seems to want a callback that has some data coming back directly ( loadOptions) Anyone have any advice?


That's a fun one. You could: 1. Run a reagent.ratom/run! block on the sub 2. Within the loadOptions, dispatch the event and store the callback in a regular atom (not a Reagent one - we don't need to re-render anything when it changes) 3. In that run! block, call the callback stored in the atom with the new data. This assumes that the callback passed to loadOptions can be called multiple times.


@U2FRKM4TW Ahh thank you! I'll try this stuff too


@shanelester55 I’m not sure I understand what you’re trying to do. is there a reason you want to use the async version of react-select, rather than the sync one?


AFAICT the async version is to handle some of the data fetching / loading / completion logic for you, but that’s exactly what re-frame is for, so the best thing would be to choose to use the async select (and eschew re-frame in this case), or use the sync version and handle the data fetching / loading / completion in re-frame and reagent


Can't say anything about this particular library, but sometimes it's desirable because the component can mark itself as "fetching in progress". The sync version would just sit there pretty.


right, you’d have to handle re-rendering the component yourself


Not only just the re-rendering, but also styling and potentially some behavior. Anything goes. :)


you can also turn a reaction into a promise, but it’s going to be finnicky


@lilactown I have successfully used the non-async select and it seems to not like being used in an asynchronous way. Seems to drop my input sometimes which is frustrating, and I thought the async version might work out better, but now that you point that out I think you might be right. I'll mess around with the base version and see if I'm doing anything stupid before I try the async anymore


if it’s dropping input or losing cursor, it might be because you are trying to use it as a controlled component. reagent sometimes has issues with controlling 3rd party text inputs


hard to say without seeing your code + the exact behavior


hmmm. good thing to look out for


Thanks for your comments 🙂


I'll bang my head against it a bit more and maybe I'll have a more intelligent question. My initial statement was a bit rambling, apologies