Aha, compose the query with functions. I’ll have a whack at it, thanks! (Sorry, I’ll await your example 🙂)

no worries, I think this is it:

(defn some-component-query [n-results]
  [{'(:zd/articles_selection_2
       {:filter_expr
        {:should [{:must [{:terminal_exprs {:matches_text "water"}}]}]}})
    [{(cond-> :zd.ArticlesSelection/articles_sel_top_subject_categories_distribution
        n-results (p/update-attribute-param assoc :n_results n-results))
      [:zd.FrequencyCell/frequency_cell_key
       :zd.FrequencyCell/frequency_cell_n]}
     {(cond-> :zd.ArticlesSelection/articles_sel_top_journals_distributions
        n-results (p/update-attribute-param assoc :n_results n-results))
      [:zd.JournalFrequencyCell/frequency_cell_n
       {:zd.JournalFrequencyCell/journal_fc_journal
        [:zd.Journal/journal_issns :zd.Journal/journal_title]}]}
     {(cond-> :zd.ArticlesSelection/articles_sel_top_crossref_article_types_distribution
        n-results (p/update-attribute-param assoc :n_results n-results))
      [:zd.FrequencyCell/frequency_cell_key
       :zd.FrequencyCell/frequency_cell_n]}
     {(cond-> :zd.ArticlesSelection/articles_sel_top_publisher_name_distribution
        n-results (p/update-attribute-param assoc :n_results n-results))
      :zd.ArticlesSelection/articles_sel_top_publisher_name_distribution
      [:zd.FrequencyCell/frequency_cell_key
       :zd.FrequencyCell/frequency_cell_n]}]}])

(defsc Filters
  [this {:zd.ArticlesSelection/keys [articles_sel_top_publisher_name_distribution]}]
  {:query (some-component-query nil)})

; later on:

(df/load! component ident Filters {:update-query #(with-meta (some-component-query) {:component Filters})})

one tip, I see that when you are doing joins with params, you are putting the list around the join, as: ({:join-key [:sub-query]} {:params "here"})

this is totally valid, but there is another option that I think is more readable, that is putting the params around the join key:

{(:join-key {:params "here"}) [:sub-query]}

both are valid, but the later gets the params closer to the keys that will respond for it

Ah, I see. That’s basically what I picked up from the EQL docs, I guess I didn’t spot the alternative syntax.

Ah, sorry, no, I think I have been using the latter syntax. The “params at the end” version seems to be what load! does when it sends it to the server.

So, basically here I’m declaring the entire query in the top-level component, rather than using get-query and composing it from the subcomponent querues. I guess that’s a tradeoff when you need to deal with parameterized subqueries?

Or could I perhaps run get-query in the function in order to get rid of the duplication?

To answer my own question, something like

(defn filters-query
  ([]
   (filters-query 10))
  ([n-results]
   [(p/update-attribute-param (get-query FilterGroupCategories)
       assoc :n_results n-results)
    (p/update-attribute-param (get-query FilterGroupPublisher)
        assoc :n_results n-results)
    (p/update-attribute-param (get-query FilterGroupArticleType)
        assoc :n_results n-results)
    (p/update-attribute-param (get-query FilterGroupJournals)
        assoc :n_results n-results)]))

Seems to work fine, with (fn [] (filters-query)) as the :query in Filters

(With

:query [:filter-bar/id
        {:zd/articles_selection_2 (get-query Filters)}]

This hits a GraphQL API in the end, so I guess that is up to that API. In the end, though, I need two levels of params regardless:

[{(:zd/articles_selection_2
   …params)
  [(:zd.ArticlesSelection/articles_sel_top_subject_categories_distribution
    …params)]}]]

ah, I see

The second one always happens in context of the first one.

Yeah, makes it awkward to compose with it. I think it’s details from the underlying ElasticSearch interface slipping through.

I never use it this way, but dynamic queries can also be a way to mess with that…i.e. set-query!

there could be some bugs when using that way, since I think no one is currently doing it, but I think it should work

Yeah, it’s starting to feel a bit awkward. I’m contemplating whether I should wrap the GraphQL API in higher-level resolvers on the backend, rather than expose it directly. The benefit of having it flow through is that changes in the GraphQL API automatically flow through to the frontend, and are directly visible in the Fulcro Inspector without me having to enumerate them.

Then I get into the business of basically reproducing the GraphQL API as resolvers, and become responsible making sure that the resolvers enumerate the possibilities present in the GraphQL API. Either way is not excellent.

In a way, it’s nice to “force” compliance in the components by aligning them to the API. Takes care of impedance mismatch. On the other hand, there are complexities in it that are hard to express in the components.