Fork me on GitHub

Hey Tony! would you be open to a PR that allows the user to set a pattern for ui keys that would match inside is-ui-query-fragment??


I know it would also have to match the current pattern as well


The current one should match as long as the ns part contains a ui fragment I thought


it requires that the ui fragment start the pattern with ^


we could work with matching any .ui. fragment in the ns


For a little motivation, we like to autonamespace our client only component keys as it helps with tracking provenance, and provides a convenient place to document such attributes. We already structure our project namespaces so that ui components are in a ui directory, so if it matched any namespace fragment we’d already be set!


I see... @uwo, the problem is that other's are very likely to have ui in their nses, and this could be a breaking change for them


it would be super-suprising for my queries to suddenly stop sending things I used :: on in a ns that happened to be in a ui package path


absolutely, which is why I was thinking it would need to be user customizable.


the “easiest” way to change the code would be to allow the user to set a dynamic variable ui-query-fragment-pattern, or some such


Wilker recently added a transform query hook :update-query to load. This allows you to plug a custom function into loads that xform the query before sending it.


So, you could "wrap" load to get your behavior


Oh, I want to make it something dyamic that defaults to the current


right defaulting to current. additionally any user provided pattern would have to also match :ui (current) because it’s used internally to fuclro, which I get


Yeah, I am resistant to more solutions for "how do I modify the query that load sends?"...the :update-query flag was intended to be the "catch all" for these kinds of customizations. All you have to do is write your own load that calls the existing one and composes into that option. I agree that the UI auto-remove feature is a commonly handy one, and I see your desire to have that be extensible. What do you think of the load wrapper approach?


It’d be nice to handle it where it’s already happening, but I can totally work with that. In om-next apps we do end up writing our own strip ui-patterned keys logic; Do I understand correctly that you’re suggesting something like a prewalk+strip-keys prior to calling load?


@uwo I'm suggesting you write a load function that calls df/load with a :update-query option that simply does a filter on the query to strip the ui elements.

👍 4

(defn our-load [this prop component params] (df/load this prop component (merge params {:update-query (fn [q] (vec (filter ...)))})))


@uwo you can totally use :update-query to do that on top of the current one

metal 4

yeah, just like Tony said, and I can give you some example code for the filter, I have done it before


the processing of the query can be a bit more involved than it seems at start


in Pathom I have a fn that helps with this:


using that your update query can look like this:


(defn remove-custom-ui [query]
  (->> (p/query->ast query)
       (p/transduce-children (remove (comp #{:remove-me :remove.ui/too} :key)))


Fulcro 2.6.4 is on clojars. It incorporates some changes by @thheller that shave off over 100kb of code in advanced optimized builds.

metal 32

I currently have

(defsc DbIdent [this {:keys [db/ident]}]
  {:query [:db/id :db/ident]
   :ident [:ident/by-name :db/ident]}
   (let [ident-str (-> ident (split #"/") last capitalize)]
     (dom/span ident-str)))
To get my idents from datomic. However, I have various of these in a form and I’m trying to make a select component to choose between these idents. I’m currently facing some challenges designing this: I have a model which points to a db-ident as
[:fulcro.ui.form-state/forms-by-ident [{...}]
:integration/name ""
:integration/origin [:ident/by-name :software-vendor/one]
:integration/target []
The current limitation I’m hitting is that (fs/mark-complete* [:integration/by-id (:db/id form)] is not firing validations on the db-idents automatically.


Looks like this setup generates subforms, (fs/mark-complete* [:integration/by-id (:db/id form)] does not work by itself, but everything rerenders correctly if I do

(fs/mark-complete* [:integration/by-id (:db/id form)] :integration/name]
(fs/mark-complete* [:integration/by-id (:db/id form)] :integration/origin]
(fs/mark-complete* [:integration/by-id (:db/id form)] :integration/target]


Figured it out, as I am using idents, not truly creating nested forms, I changed the query on the form component to not be a join query 🙂