This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-28
Channels
- # announcements (1)
- # beginners (205)
- # calva (30)
- # cider (5)
- # cljdoc (25)
- # cljs-dev (2)
- # clojure (119)
- # clojure-brasil (5)
- # clojure-conj (7)
- # clojure-europe (2)
- # clojure-hamburg (7)
- # clojure-italy (14)
- # clojure-nl (2)
- # clojure-russia (13)
- # clojure-spec (79)
- # clojure-uk (58)
- # clojurescript (54)
- # core-logic (2)
- # core-matrix (2)
- # cursive (40)
- # datascript (2)
- # datomic (18)
- # duct (2)
- # emacs (14)
- # figwheel (3)
- # figwheel-main (7)
- # fulcro (30)
- # funcool (1)
- # graphql (10)
- # jobs (1)
- # juxt (13)
- # lumo (1)
- # mount (1)
- # off-topic (56)
- # other-languages (2)
- # pedestal (17)
- # powderkeg (2)
- # protorepl (2)
- # re-frame (10)
- # reagent (1)
- # reitit (7)
- # ring-swagger (10)
- # schema (2)
- # shadow-cljs (70)
- # spacemacs (13)
- # specter (4)
- # sql (9)
- # tools-deps (26)
@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 {})]))}
"abc")
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 😅
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.
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?@U2J4FRT2T why does list-user not have any ident ? 🙂
if you search in the http://book.fulcrologic.com 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}
http://book.fulcrologic.com/#_automatic_normalization like the PersonList but you only have :friends
(giving it another name like singleton or something that makes sense in your context)