This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-15
Channels
- # beginners (6)
- # cider (13)
- # cljs-dev (45)
- # cljsrn (1)
- # clojure (11)
- # clojure-france (1)
- # clojurescript (13)
- # cursive (19)
- # data-science (10)
- # datascript (1)
- # datomic (2)
- # docs (8)
- # fulcro (26)
- # graphql (1)
- # hoplon (2)
- # jobs (1)
- # off-topic (5)
- # parinfer (21)
- # re-frame (2)
- # reagent (22)
- # shadow-cljs (3)
- # spacemacs (8)
- # unrepl (1)
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 😕
@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
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))
writes are always guaranteed to go before reads when scheduled together, so you could even flip the order and it would still work right.
there is no such transaction on the client, so how would you even get to the server?
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.
Normally, the client would have already done an optimistic update and would have had the entity already…there is no need to read it.
the tempid is really the only thing it needs, and that is automatic when you remap from the mutation
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?
normal Fulcro apps do not re-read the entity…they already have it, because they created it.
You might want to read http://book.fulcrologic.com/#FullStackErrorHandling
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).
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"
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
@jasonjckn the official repo for the fulcro inspect is this: https://github.com/fulcrologic/fulcro-inspect 🙂