Fork me on GitHub
#fulcro
<
2018-09-22
>
pvillegas1201:09:35

What are the semantics surrounding prim/transact!? If I pass a list of mutations and one of them throws an error how does the transaction behave? Are they rolled back?

pvillegas1212:09:15

Why would I prefer multiple prim/transact statements over a prim/transact this '[ … multiple mutations] then?

pvillegas1212:09:33

Are they equivalent?

wilkerlucio12:09:28

its a shorter loop, but not much difference unless you are using ptransact!, which can ensure order in a list of transactions (it will run the tx, then the remote, and next tx only when the previous one return)

pvillegas1212:09:55

Ah, so I’m not guaranteed calling order with prim/transact! then?

claudiu15:09:16

the ones in ptransact are "chained", the second one will not start until the network request from the first one has finished. The the normal transact just loops and executes each one of the mutations.

👍 4
eoliphant16:09:57

quick question on what folks are doing for code organization. I've taken to following the template example and putting client/server mutations under api, but was back and forth about where to put stuff that's purely ui related. For now, I've been generally putting them 'close' to UI components that use them, in the same or a sibling namespace.

wilkerlucio19:09:00

I like to keep my mutations close to UI too most of the time

wilkerlucio19:09:22

the exception is when I want more of a generic mutation, those usually into some "helpers" or get their own ns depending on the scope

4
eoliphant21:09:17

cool.. Obrigadao!

😄 4
currentoor17:09:29

i prefer to keep most of my mutations in subdirectories in the api/ directory, especially mutations that will have a server side part

4
currentoor17:09:30

some mutations i co-locate with components, for example i have a BaseModal component and mutations for open/close of this modal i co-located

4
eoliphant14:09:24

yeah that's what I'd been doing as well. semantically, for me at least the first thing was to keep 'mutations' together. But I don't think that's actually the key organizing principle. there's "api stuff" and "ui stuff", with some overlap lol, and mutations are the implementation mechanism.

eoliphant22:09:59

I just ran into an error, but I'm unclear on why it made fulcro unhappy. I have the following component

(defsc FFRSummaryPage [this {:keys [ffr/side-nav]}]
  {:initial-state (fn [x] {:router/page  :PAGE/summary-page
                           :ffr/side-nav (prim/get-initial-state comp/FFRSideNav {})})
   :query         [:router/page
                   {:ffr/side-nav (prim/get-query comp/FFRSideNav)}
                   ;:ffr/side-nav (prim/get-query comp/FFRSideNav)
                   ]}
...
originally i had the literal map for the initia-state, and had mistyped the query, the commented out bit for :ffr/side-nav. When I fixed the query, I got this error > Illegal parameters to :initial-state (prim/get-initial-state comp/FFRSideNav {}). Use a lambda if you want to write code for initial state.... I fixed it by wrapping the initial state in a function in the snipped, But I'm not sure per the error, why it complained

currentoor17:09:43

that’s expected, map literal is template mode and fulcro tries to treat it as such

currentoor17:09:29

you probably want to change :PAGE/summary-page to (:summary-page params)

currentoor17:09:58

if you’re going to have the join for side-nav and parse the summary page out of the params

eoliphant14:09:32

ok thx, i'm still figuring out the differences