pathom 2021-08-25 | Slack Archive

markaddleman23:08:01

I'm wondering the best way to model this use case: The UI needs to display a bunch of tables. The particular columns of each of the table are controlled by the server. The UI receives a data structure that fully describes the table. Something like

{:table/cols [{:table.col/id 1, :table.col/label "Column 1", :table.col/attribute :attr-1},
              {:table.col/id 2, :table.col/label "Column 2", :table.col/attribute :attr-2}]
 :table/rows [{:table.row/id 1, :attr-1 "in col 1", :attr-2 "in col 2"}]}

I figure the UI will query for the table with EQL [{:some/identifier [:table/cols, :table/rows]}] I'm stumbling over how to model the resolvers in the server. The :some/identifier is straightforward:

(pco/defresolver data []
  {::pco/output [:some/identifier]}
  {:some/identifier [{:some.identifier/id     1
                      :some.identifier/attr-1 "in col 1"
                      :some.identifier/attr-2 "in col 2"}]})

The resolver for [:table/rows :table/cols] is not. I'd like to have a single resolver that can take arbitrary input and reformat the data into rows and cols as the client is expecting. I'm getting hung up on the "resolver that can take arbitrary input" - This seems exactly counter to Pathom's philosophy. I thought I could use a wildcard for a resolver input but that does not work. Any thoughts?

markaddleman23:08:36

Maybe this is better handled as a plugin than as a resolver?

2021-08-25

Channels