This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-22
Channels
- # 100-days-of-code (1)
- # beginners (51)
- # carry (1)
- # cider (10)
- # clojure (71)
- # clojure-conj (4)
- # clojure-dev (9)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-russia (8)
- # clojure-uk (16)
- # clojurescript (42)
- # cursive (4)
- # datomic (2)
- # emacs (8)
- # figwheel-main (7)
- # fulcro (20)
- # hyperfiddle (5)
- # jobs (2)
- # off-topic (16)
- # om-next (4)
- # onyx (9)
- # powderkeg (1)
- # re-frame (8)
- # reagent (17)
- # reitit (41)
- # robots (6)
- # rum (1)
- # shadow-cljs (54)
- # testing (3)
- # tools-deps (19)
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?
no rollback
Why would I prefer multiple prim/transact
statements over a prim/transact this '[ … multiple mutations]
then?
Are they equivalent?
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)
Ah, so I’m not guaranteed calling order with prim/transact!
then?
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.
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.
I like to keep my mutations close to UI too most of the time
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
i prefer to keep most of my mutations in subdirectories in the api/
directory, especially mutations that will have a server side part
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
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.
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 complainedthat’s expected, map literal is template mode and fulcro tries to treat it as such
you probably want to change :PAGE/summary-page
to (:summary-page params)
if you’re going to have the join for side-nav
and parse the summary page out of the params