Fork me on GitHub
#fulcro
<
2018-01-15
>
levitanong08:01:07

the documentation for post-mutations States that they’re for local transforms only. Is this a best practice thing, or is there really something stopping you from triggering a remote from a post-mutation?

claudiu08:01:04

@levitanong it's more of an enforced thing. Triggering remotes from post-mutations will not work as far as I know. 🙂

claudiu08:01:41

ptransact was added for use-cases where you need that pattern 🙂

levitanong08:01:57

@claudiu ah, that makes sense. Thanks!

levitanong08:01:58

@claudiu How would you get around this though: “Use caution when using mutations with conditional remote behavior. ptransact! detects which mutations are remote by pre-running them (they are side-effect free) against the app state as it is at the beginning of the transaction. If you have a mutation in the middle that relies on the state modifications of a prior mutation in the same transaction in order to decide if it is remote then it will be mis-detected.”

claudiu08:01:05

did not come across this issue so far. Do you have a certain scenario in mind ?

levitanong09:01:11

@claudiu A user can enter an origin and a destination. For either, I can search the google autocomplete API to retrieve a list of matches. Each of these matches will have its own ID. Google’s API makes it so that I have to make a separate API call to actually get the latlng of that Place. Only when I have both LatLngs do I want to make a third API call to a separate endpoint to calculate public transit routes between the origin and destination.

levitanong09:01:10

previously, I had been relying on componentDidUpdate to automatically trigger that third API call, but it has proven difficult to manage. What I’m trying to do now is whenever the user selects a Place, it triggers a ptransact that will run the google Places API to get the Latlng, and then *if* both origin and destination have latlngs, proceed with getting itineraries from the third API.

levitanong09:01:04

but it appears ptransact! precomputes the conditional to run the remote, which means it never runs

claudiu09:01:07

ahh interesting. But can't you move this logic on the server ?

levitanong09:01:21

@claudiu no because before the last one, the servers are Google. :p

claudiu09:01:30

yep. was just thiking instead of calling the google-api, just call a local endpoint, and on the server add that logic, and call google-apis 🙂

levitanong10:01:13

@claudiu Haha, that might be a bit too roundabout for my tastes. I’d treat that as a last resort. 😛

tony.kay18:01:35

@mandor2017 strange…when I put your UI in a devcard it works fine, but when I run your project it is hosed

tony.kay18:01:26

@levitanong what do you mean it pre-computes the conditional?…the elements in your transaction can use app state the whole way

levitanong03:01:43

My understanding of how ptransact! works is that given (ptransact! this [(A) (B)])`, B will be receiving the state at the time ptransact! is called. I had assumed this was indeed the case since the state I was getting from B didn’t include the new data that A got.

levitanong04:01:10

All these computations were happening in the action because I was using load-action

tony.kay18:01:47

The warning is about how ptransact detects which ones should be deferred…they all get run

tony.kay18:01:56

but if you write this:

(defmutation x [p]
   (remote [env]
       (when some-condition true)))
and that condition is not true when you first run ptransact, then it won’t defer the following one because it doesn’t think that one is remote.

tony.kay18:01:30

Technically the model for interacting with remotes is meant for talking to your own servers through EDN. When you start talking to other APIs that have different requirements you may choose to add this kind of logic at the network layer using XHR yourself (i.e. implement your own networking for a remote that talks to google APIs called :google)

tony.kay18:01:07

then hide the asynchrony mess at that layer, where it belongs.

tony.kay18:01:58

If you were just trying to issue the equivalent of loads through those mutations, it is fine to “trigger” remote behavior where you’ve not actually added anything to the load queue. It will just find it empty and do nothing.

tony.kay19:01:01

But aren’t you writing a remote networking layer if you’re talking to google APIs?

levitanong04:01:12

Definitely what i’ve done. It’s in its own remote.

tony.kay19:01:43

definitely encapsulate it there…don’t raise the three calls all the way to your UI…just make it one abstraction and hide the details in the networking

tony.kay19:01:02

@mandor2017 it seems to be a real bug. It works fine in a devcard, but fails in a regular app. I’ll dig in further and see what I can find.

edward.scott20:01:58

@tony.kay The project was created with lein new. Apart from the code the only other change is adding the bootstrap css into index.html.

levitanong03:01:43

My understanding of how ptransact! works is that given (ptransact! this [(A) (B)])`, B will be receiving the state at the time ptransact! is called. I had assumed this was indeed the case since the state I was getting from B didn’t include the new data that A got.

levitanong04:01:10

All these computations were happening in the action because I was using load-action

levitanong04:01:12

Definitely what i’ve done. It’s in its own remote.