Fork me on GitHub
#fulcro
<
2018-02-15
>
souenzzo01:02:04

Is possible make a mutation/query like this? [(user/add {:db/id "tmp" :user/name "foo"}) {[:db/id "tmp"] [:user/id]}] (create an entity with tempid and ask for it, by it's tempid) I cant find in env the fulcroids->realids map 😕

tony.kay01:02:44

@souenzzo transact is for writes only, and load is for reads only; however, you can run the transact! and load in the same execution unit (e.g. while you have the thread) and it will work as you want…in other words tempid rewrite from the write will update the query in the load queue

tony.kay01:02:00

so, yes, that is something you can definitely do

souenzzo01:02:20

There is a working example?

tony.kay01:02:41

I’ve written so much stuff I can’t say 😜

tony.kay01:02:01

but all you have to do is:

(let [id (prim/tempid)]
  (transact! this `[(user/add {:db/id ~id …})])
  (load this [:user/by-id id] User))

tony.kay01:02:25

assuming you have the correct classes and ident set to match up

tony.kay01:02:46

writes are always guaranteed to go before reads when scheduled together, so you could even flip the order and it would still work right.

tony.kay01:02:10

and tempid remaps affect state and the load queue

souenzzo01:02:13

Oh, I'm on server parser* (not sure if make difference)

tony.kay01:02:28

that makes no sense

tony.kay01:02:45

there is no such transaction on the client, so how would you even get to the server?

souenzzo01:02:54

So, when the client need to create a entity and query it, the client will do 2 requests: one request with the mutation, and get tempids back, resolve tempids, and then the second asking for the entity.

tony.kay01:02:47

Normally, the client would have already done an optimistic update and would have had the entity already…there is no need to read it.

tony.kay01:02:02

the tempid is really the only thing it needs, and that is automatic when you remap from the mutation

tony.kay01:02:00

The pattern you’re describing is used when you want a non-optimistic update (e.g. don’t put it in app state at all until it exists on the server). And in that case, load targeting and probably even a post mutation are interesting because you’re probably trying to detect an error?

tony.kay01:02:21

normal Fulcro apps do not re-read the entity…they already have it, because they created it.

souenzzo01:02:06

I'm implementing fulcro in an existing application. And starting from the server parser. But that's other application problem: when you put one item in your bag, only the server will know the price of it (due something like "price balance"), so yes, my app will need to always fetch after create (or maybe some websocket stuff).

souenzzo01:02:06

I think that websocket callback may be more elegant solution. Do the optimistic creation of item with no price, then receive the price as a "update"

tony.kay01:02:06

I don’t think I’d jump to websockets…unless you already know the deployment overhead and characteristics of doing that. Suddenly having a bunch of persistent connections is not something you should do lightly

tony.kay01:02:19

In your case, the read after write will work perfectly

wilkerlucio21:02:58

@jasonjckn the official repo for the fulcro inspect is this: https://github.com/fulcrologic/fulcro-inspect 🙂