Fork me on GitHub

@tony.kay What would you consider best practices in the current version of fulcro (also including the fulcro-incubator) ? In my older projects I used df/load & m/set-value! extensively. But now considering not using them at all and just keeping all that logic in mutations (df/load-action, etc...) Seems like everything is implemented using transact! and as far as I can tell load-action can do everything df/load can, and it would keep my project a bit more consistent & easier to debug


@claudiu Everything exists for a reason. The set-* and load functions exist because there are cases where you’re donig *just* that (e.g. toggle a checkbox) and it would be annoying and overkill to write a mutation, or you’re loading something in a context where, again, a mutation would be overkill…but any combination of things probably belong in a combined mutation, especially if they have a full-stack sense, because that gives you a conceptual wrapper around the operation, and doesn’t expose the details to the UI.


The most common mistake I see is ppl thinking that they have to do routing at the UI layer with a raw UI route mutation. Those exist in the Fulcro routing system because sometimes routing is all you need to do, but more often you want to combine the UI change with other things, like loads and such. Composing those groups of things into new mutations is the correct approach, IMO.


Is it expected behavior if I transact on the reconciler with no follow-on-reads for the UI to reflect the changes ?


I'm doing something like :

(defmutation set-value [params]
  (action [{:keys [state] :as env}]
     (swap! state assoc-in [:PAGE/libraries :singleton :libraries] [])))

(dom/button {:onClick (fn []
                             (prim/transact! (prim/get-reconciler this) `[(set-value {})]))}


If it is, is there any way to turn it off ? :)


does the mutation have a refresh section @claudiu?


I guess not


so, you’re seeing changes but you don’t want to?


I thought they were not supposed to happen with reconciler


rendering has gone through a lot of changes lately, but if memory serves correctly the reconcile when nothing is queued for refresh should be a no-op


I’m sorta waiting on React 17's async stuff to drop before I polish those internals back up


they are a bit too slow and unrefined at the moment…“they work”, but they are a bit underspecified


Currently the component is mounted with set-query will try on the template. Got as far as the parser tracking everything down 😅


will normalization ever cease to be my enemy and become my friend? 😞


I haven't had problems in a while thanks to fulcro-inspect . Are you doing some more advanced stuff ?


No. When I flow tutorials/do a TODO, it works When I try with other names, do not work I'm sure that somewhere in Fulcro code there is a (if (= ident :todo/id) (work!) (dont!)) somewhere 😆 😢


Ahh might be :thinking_face: But if you're working on projects for learning and having trouble could push the code to a repo and share.


The're usually just a few gotchas that are easy to spot/debug after a while.


I'm trying to setup a new project and then share/explain how fulcro works to the rest of my team


(fp/defsc User [this {:keys [users]}]
  {:query         [:user/id :user/name]
   :ident         [:user/by-id :user/id]
   :initial-state (fn [_] {:user/id "aa" :user/name "bb"})}
(fp/defsc ListUser [this {:keys [users]}]
  {:query         [{:users (fp/get-query User)}]
   ;; no ident
   :initial-state (fn [_] {:users [(fp/get-initial-state User {})]})}
(fp/defsc Root [this {:keys [app-users]}]
  {:query         [{:app-users (fp/get-query ListUser)}]
   ;; no ident
   :initial-state (fn [_] {:app-users (fp/get-initial-state ListUser {})})}
Is it looking good?


yep 🙂 or at least can't spot it 🙂


@U2J4FRT2T why does list-user not have any ident ? 🙂


I'm listing all users in the app. How can I create a ident for it?


ahh right. :ident (fn [] [:PAGE/libraries :singleton])


can put something :ident (fn [] [:listings/by-id :users])


if you search in the for :singleton there are a few examples. Or you can have :ident [:listings/by-id :listing-type] and add listing type to the intial state as {:listing-type :all-users}

claudiu18:11:17 like the PersonList but you only have :friends (giving it another name like singleton or something that makes sense in your context)


Just asking dont really mind, was just a idea for a speed bump since I have a set of mutations & pmutations and trigger the screen change at the end.