Fork me on GitHub
#fulcro
<
2020-10-23
>
dvingo00:10:43

When handling a remote error I have a use case where I want to reset the app state to before the action. I noticed there is no state-before-action in the env map passed to error-action - it is only available in the remote section - I am passing it to the error-action by swapping it into the fulcro app runtime atom. Is this just an oversight, that the state-before-action is not available in the error-action handler?

tony.kay02:10:56

@danvingo just an oversight…the logic for that is in the http://book.fulcrologic.com/#_result_action default result action. Just look at the code, it is very simple once you read that part of the book. I’d accept a PR, and you can also just override the built-in one with one patched to your needs.

dvingo14:10:53

Thanks Tony. I'll look into making a PR.

Mr. Savy05:10:02

I don't know if this is a bug or not, but I've been trying to get past an issue for a while now to no avail. If I have a defrouter set up to point to some component test I run into an issue. test's initial state has one component that it grabs initial state from, X. test grabs the initial state of X twice with two different sets of static data. call the sets S1 and S1. In test's body, if I call the factory ui-xon S1and S2then S2's result is copied into S1. to be more specific, whatever data I passed into X for S1is essentially overridden and instead of test's body displaying S1and S2it just displays S2 twice. (the maps passed into the body look identical). I have found that the issues goes away if I switch the :query from [... {:test/S1 (comp/get-query X)...} to [... :test/S1 ...]. I will write up an example gist tomorrow, but if anyone recognizes a potential cause in the meantime help would be appreciated.

Tyler Nisonoff18:10:24

I’m running into an issue with pessimistic transactions — I’m calling (comp/transact! this [(a) (b)] {:optimistic? false}) But b never gets called … I added debug logging at the end of a on the server, and in its ok-action / error-action but my logging at the beginning of b is never triggered.. If i re-order them, both get called — anyone run into anything similar before?

tony.kay03:10:15

I really recommend not using those, but I'm not aware of any bugs

Tyler Nisonoff03:10:07

Sorry, not using which aspects? Optimistic: false?

tony.kay03:10:28

That is a legacy feature. You should instead just do logic in action handlers of a

Tyler Nisonoff03:10:56

👍 makes sense, thanks!

👍 3