Fork me on GitHub

Is there an idiomatic way of formatting data from a resolver before it's updated in a specific instance of a UI element? Say my resolver returns a decimal 0.1, and I want to use this format in one instance of a defsc, but in a different instance of that same defsc I want to format it to be a percentage, say 10%. Is there a reasonable way to this or do I need different components? I could wrap the decimal defsc in a percentage defsc and do the formatting before passing it through. Thoughts?


@stuartrexking I highly recommend that your data model be the real data. If it is a number, keep it a number in the db. Formatting should be in your UI code (i.e. a formatting function, like cl-format ). I see no need for a separate component per-se, unless you ahve some other reason for wrapping a single data point in a component. They seem orthogonal concerns to me. The defsc is about making a component. The query is about pulling raw data. The code in the render body is concerned with visualization.


@tony.kay Thanks for the response. Based on what you are saying, I either need to have logic in the defsc that determines the formatting (showing a % sign or not), or I need to do that on the server in the resolver.


And based on those two options, the former seems more appropriate.


yeah, I would never put formatting in a resolver


I think of attributes as talking about a particular fact in a native data format. For example, I use transit bigdecimals in RAD so that you have full accuracy on front and back end. Formatting is done at ui layer as late as possible. That way the fact is never “aliased”…you always know what you have.


(in RAD I have a decimal ns that makes a numeric type that is implemented with big.js in cljs, so that bigdecimals work isomorphically in front/back-end)…numeric mismatches between front/back are particularly annoying.


Ok great. Thanks.


I started a series of blog posts documenting how I've approached solving different problems when building an SPA with fulcro and pathom. Right now there's just an introductory post and a followup on client-side auth. I'm sharing them here in the hopes that they're helpful to others and not just future me. I haven't blogged before and wouldn't consider myself a fulcro expert; I'm open to any constructive feedback. You can find the posts at

👍 28

Great. Will keep an eye on it.


emacs users using clj-kondo. how you teach it not to freak out with fulcros macros like defmutation?


NOTE: The macro just generates a defmethod. I can’t really change it for compatibility reasons, and it exists to help with navigation and easy use, but there is nothing saying you couldn’t generate a similar macro or just write the defmethod yourself. Each section just becomes and output entry in a map with a key that matches the section name. I’ve thought of various tricks, but Cursive added support for the macro years ago, so it’s always been smooth sailing for those users (like me). You could make a macro that still helps some, but that looks more like a defn returning a map.


I tried looking at kondo's config.edn but found nothing about fulcro


@vinnyataide take a look at the config docs at the clj-kondo repo. You can use :lint-as or configure the :unresolved-symbol linter


@borkdude thanks, I'm looking at it now


I think in this case since fulcro's defmutation has no close candidate to lint as I'll simply put on unresolved


I would like to contribute if it could've possible to make clj-kondo understand fulcro's macros so it could help people catch errors quickly


@vinnyataide Sure. You can make an issue for it first. I could give you some pointers where to start. There is built in support for compojure for example


@borkdude that's great to know


I'll take a look at compojure's


Note that you can also use def-catch-all


thats cool too


it worked better with def-catch-all since all mutation applications were ignored too


I have a key at the root of the database :a. I use initial-state in my root container to set the value of this key to a comp/get-initial-state. I call load! to retrieve the remote data. When the remote data is returned the ident value is passed into the sub component [:a/id 1], not the realised value {:a/id 1 a:/name "Stu} What am I missing here.


If you're seeing the ident in your app state, that is the expected behavior. When you ask for data from that entity in a component's query, fulcro will denormalize that data and pass the entity data (not the ident) to your component.


It's passing the ident though.


What do your component queries and idents look like?


Let me grab it.


(ns ventures.fierce.c19.ui
    [cognitect.transit :as ct]
    [com.fulcrologic.fulcro.components :as comp :refer [defsc]]
    [com.fulcrologic.fulcro.dom :as dom]
    [com.fulcrologic.fulcro.algorithms.react-interop :as interop]
    ["victory" :refer [VictoryChart VictoryAxis VictoryTheme VictoryLine]]))

(defsc SelectContainer [_ {:select-container/keys [label selected values]}]
  {:ident :select-container/id
   :query [:select-container/id
          {:select-container/id       :params/id
           :select-container/label    :params/label
           :select-container/selected :params/selected
           :select-container/values   :params/values}}
           (dom/label label)
                    (dom/div :.selected selected)
                    (dom/div :.dropdown
                               (map #(dom/li {:key %} (dom/a %)) values))))))

(def ui-select-container (comp/factory SelectContainer {:keyfn :select-container/id}))

(defsc Header [_ {:keys [countries]}]
  {:query [:countries (comp/get-query SelectContainer)]
          (fn [_]
            {:countries (comp/get-initial-state SelectContainer {:id 1 :label "Country" :selected "Loading..." :values [""]})})}
    (dom/div :.title
             (dom/h1 "HELLO")
             (dom/h2 (dom/a {:href "#countries"})))         ;selected-country)))
      (println "countries: " countries)
      (ui-select-container countries))))

(def ui-header (comp/factory Header))

(defsc Root [this props]
  :initial-state (fn [_] (comp/get-initial-state Header))
    (ui-header props)))


That's the entire UI.


countries in Header is [:select-container 1]


There is only 1 header but could be multiple select-containers (at the root level)


Your Header query doesn't look quite right. When you want to compose a child component's query, you should use a join like so: [{:countries (comp/get-query SelectContainer)}].

Jakub Holý (HolyJak)17:03:09

BTW you should get an error for this query in the latest Fulcro


Yeah it wouldn't even compile for me. Nice sanity check to have! 🙂


Changing that query makes no difference.


The only other thing I'm doing is calling

(df/load! app :countries ui/SelectContainer)


From my app init function.


Your root component doesn't have initial state; it needs to be in a map like {:initial-state (fn [_] (comp/get-initial-state Header)}. Also, your root component needs a query. Queries and initial state are always composed from the root, so if your root component doesn't have initial state or a query, neither will work for child components. I updated your root component to look like:

(defsc Root [this {:root/keys [header]}]
  {:initial-state {:root/header {}}
   :query [{:root/header (comp/get-query Header)}]}
    (ui-header header)))
(And also your SelectComponent's initial state values should have the namespace param rather than params.) With those two changes I can see application state being initialized as I would expect.


Are you using fulcro inspect? If not, I would highly recommend it.


Makes it much easier to see what's going on with your application state.


I am using it, and it was working fine. I refactored some stuff and seems to have broken everything. I'll add in your suggestions now. I also noticed that my version of Root didn't have :initial-query in a map.


Edited my root component above to be correct; the initial state was messed up.


What's the best way to exclude initial-state values from a load! query? Say I'm setting a label value in my initial-state, I don't want to have to query the server for that label key. I can use :without in load! config. Is that the best way to do it?


Any keywords with the namespace ui (eg. :ui/label) won't be fetched from your remote, as well. That's what I usually do.


@stuartrexking I generally also make a “blacklist” of keys that should never go on the network, and then add a global EQL transform. See this code in the RAD library:

❤️ 4

so, you can invent your own naming pattern and make that easier in some ways, but the blacklist is really easy to update as you go (and see bad things hit the net)


The naming convention of “has a ui namespace” is fine for component-local concerns, but it can also be nice to add a rule like “elide it if it contains .local. in the namespace of the key” or something.


Is it common in Fulcro to pass an ident to a server resolver simply for it to be passed back to ease normalization? Say for example I have a component called SearchResult. It doesn’t really have a natural :ident, so I invent one like [:ui/id :root/search], but now I’m realizing that my load! calls are having trouble normalizing. Perhaps a post mutation would be better here…


More generally, what is the idiomatic way to handle components that don’t have a readily available :ident? I’ve seen examples of passing params into comp/get-initial-state so that the parent can give the component a unique name, and that seems good. I’m struggling to understand how to get that setup working with load!


@cjsauer nothing wrong with using static idents like so

(comp/defsc CurrentOrder [_ _]
  {:ident       :order/id
   :query       [:order/id
                 {:order/line-items (comp/get-query LineItem)}
                 {:order/payments (comp/get-query Payment)}
   :form-fields #{:order/line-items :order/payments}})
(comp/defsc CurrentSale [_ _]
  {:ident (fn [] [:COMPONENT/by-id ::current-sale])
   :query [{:current-order (comp/get-query CurrentOrder)} :payment-in-progress?]})
where CurrentSale is a client only component, and CurrentOrder is the thing that gets loaded from the server


you should never be sending queries to the server that the server isn’t actually supposed to fulfill


so we only call load! with CurrentOrder


now if CurrentOrder has keys that don’t make sense to the server we can remove them in `



@currentoor ty for the reply. Above makes sense, but what if instead of CurrentOrder we’re trying to load something that doesn’t have a natural ident? Say the :ident is computed from initial state parameters. In this case, the load doesn’t have the proper information to denormalize. I’m thinking now that pre-merge might be useful in this case, because I can merge the newly loaded data with the computed ident…otherwise it seems to get clobbered.


yeah that seems reasonable


The only example I can think of right now is something like SearchResult. It doesn’t really have an ID, but “load” feels semantically correct.


i try to avoid that situation but it does come up from time to time


i think tony recently implemented a searchable auto-complete input in RAD


and it had the same problem


Ah interesting. Initially I was trying to :target the load to the proper component, but that leads to clobbering. I wonder if something like (targeting/merge [:component/by-id :search-results]) would be useful?


not sure, been a while since i’ve messed with that, you’d have to read the docs and try it


hmm i can’t find the source for the searchable input @tony.kay built recently, maybe he can chime in when he’s got a moment


check that out


targeting/merge would be something new, I don’t think it exists. Ah cool, I’ll take a look, ty


right, that…but that is a generalized complex component, which may be hard to understand


That one requires the new floating root stuff


The idea with that one is the following: • I have an arbitrary number of form fields on a form, each one is an autocomplete (needs to load/normalize some data for that) • BUT, each form field is stateless, so there is noplace to load the (many) different autocomplete lists


There are several ways to tackle that 1. Make a top-level table, like :autocomplete-options, and assign each autocomplete list some kind of ID, and target that to that table. Then include the table in the form’s query as a link query. I do that with the picker in RAD. In this case the form fields are not stateful defsc with queries…you’re just making a normalized cache in a top-level table. 2. Give each field a lifecycle outside of React…i.e. make a state machine that, when the form comes on-screen, creates in-app IDs and state for each of these “stateful” things, so that each field becomes a stateful component with a query/ident. 3. Do something fancy like the floating roots thing…not sure if I love it yet 😜 Just invented that one two days ago 4. Do something really nasty and run an http get and put the results in component-local state. While ugly, this is the “normal” way in stock js/react. Latest Fulcro releases support hooks, so perhaps you can make it a bit prettier with that 🙂


Aha okay. I see with option 1 you’re using a post-mutation and closing over the id of the autocomplete field. That’s what I was missing.


that’s option 3…which is the complex floating root one


but yes, some kind of ID is going to be needed to track which autocomplete values you want


could be as simple as the keyword name of the field in question


approach (1) is probably the easiest to do:

(defsc AutocompleteOptions [_ _] {:query [:text :value]})

(defsc Form [this props]
  {:query [:local/thing [:autocomplete-table '_]]
  (let [cache-key (something-that-generates-stable-cache-key)]
      (input {:onChange #(df/load! this :some-autocomplete-key AutocompleteOptions {:params {} :target [:autocomplete-table cache-key})})


something like that


Cool, ty. Let me try to wire this up using a post-mutation. Curious tho, would it work to :target the component that has a computed ident, and then use a :pre-merge hook on that component so that the incoming data gets merged rather than clobbered? Not sure if that question makes sense, I’ve never used pre-merge before.


Suppose I can just try it 😛


Got it working! Thank you both for the help 🙏

👍 4