Fork me on GitHub
#fulcro
<
2024-05-08
>
janezj08:05:41

I would like to use report to present data in an atom on client (like shopping cart). All my existing reports are using remote sources. Where to start or is this too far from report design?

tony.kay14:05:50

The state machine on reports is completely pluggable. Just copy the provided one and modify the bits around loading.

đź‘Ť 1
Quentin Le Guennec08:05:17

Hello, is there a summary of the reasons why fulcro generally prefers to fetch data before entering a route rather than within that new route?

tony.kay14:05:44

Where do you get this idea? There is code to support doing so, but it is not required. You can do whatever you like.

Quentin Le Guennec07:05:04

I recall reading that in the docs but it might be a false memory

norman18:05:04

I fetch data after entering a route. It does work, but I feel like it's definitely not the path of least resistance.

Mark Wardle13:05:40

Hi. I think I'm hitting the issue raised https://github.com/wilkerlucio/pathom/issues/93 with regard to missing parameters in the AST. I need to add a hint to my ident as I have a resolver so rather than [:form/id xxx] I want [:form/id xxx {:type :form_ess}] As per that issue, I now understand why the parameters aren't passed into my resolver. It's not clear how I set a new ident resolver to my pathom environment - is there any example someone could share? As I wasn't sure how to solve, I instead thought I'd use :update-query in my df/load! to modify the query on the fly:

(df/load! app [:form/id form-id] EditFormEdss
                                   {:update-query (fn [q]
                                                    (let [q' (update q 0 (fn [_] (list :form/id {:form-entity-name "form_edss"})))]
                                                      (println "query " q')
                                                      q'))
                                    :post-mutation        `dr/target-ready
                                    :post-mutation-params {:target [:form/id form-id]}})
But while I can see the parameters being added to the generated query, my resolver is still not getting the parameters.

Mark Wardle13:05:34

Perhaps I should post on #C87NB2CFN instead, because it feels as if this is more of an issue with parameters in pathom on idents - which from https://edn-query-language.org/eql/1.0.0/specification.html#_parameters the documentation, should be supported on idents? It's then an issue of how to get those parameters into an attribute resolver - perhaps they should end up accessible via (pco/ident-params env) as an equivalent to (pco/params)?

Mark Wardle13:05:00

PS. I did manage to get the parameters through using :update-query - just needed to add the params to an attribute that wasn't the same as the original ident attribute.

tony.kay14:05:38

Why aren’t you using load’s :params option?

tony.kay14:05:36

Each element of a query can have params, and generally you only need params on the top for a load, which it will do. Then you can add a plugin to pahtom to pull those out into the env

tony.kay14:05:53

and there is no “3rd element of an ident is params” support in EQL…not sure where you’re getting that

tony.kay14:05:08

A proper EQL query on an ident, with params, looks like [{([:thing/id 1] {:x 1}) [:subquery]}]

tony.kay14:05:55

but again you’re better off using the :params option on load and the plugin for pathom

đź‘Ť 1
Mark Wardle14:05:19

Thanks @U0CKQ19AQ - yes I copied it across incorrectly. I had also tried using :params but they weren't brought in because I hadn't worked out how to add the plugin into pathom - but I'll copy it from fulcro rad - thank you!

Mark Wardle08:05:12

For any future readers, for pathom3, one registers a plugin for wrap-process-ast in order to process the AST and take any parameters and make them available to all your resolvers via the environment:

(-> env
      (assoc ::p.error/lenient-mode? true
             :com.wsscode.pathom3.format.eql/map-select-include #{:tempids}) ;; always include request for tempids
      (pci/register ops)
      (p.plugin/register
       {::p.plugin/id `query-params->env
        ::p.eql/wrap-process-ast
        (fn [process]
          (fn [env ast]
            (let [children     (:children ast)
                  query-params (reduce
                                (fn [qps {:keys [type params] :as x}]
                                  (cond-> qps
                                    (and (not= :call type) (seq params)) (merge params)))
                                {}
                                children)
                  env          (assoc env :query-params query-params)]
              (process env ast))))}))

🙏 1
Matt18:05:22

Hey, I'm getting back into learning fulcro recently. I have a very basic question about load! Can load! not fetch data from an EQL query below the level of an entire identity resolver? For example, you can retrieve a player name like this with an EQL query [{[:player/id 1] [:player/name]}]. However, I can not figure out how to only update :player/name with load! I can easily reload the entire player entity, but not any of its individual attributes in isolation. There has to be a way to do this type of load targeting or is there a reason why this is not easy to do?

tony.kay21:05:26

How can EQL possibly know “which player’s name” without an ident?

tony.kay21:05:49

Likes like me asking “favorite color?” in a crowded room with my eyes closed…who should answer?

tony.kay21:05:17

If you use load-field! within a component, then it will automatically write the ident join for you, if that’s what you mean, but of course it uses “this”’s ident, which would need to be a specific person in your case

tony.kay21:05:53

Load also supports things like focus query and query transforms, but load itself is primarily concerned with loading entire entities. load-field! is the special case of pulling a single thing (which may have a subquery)

Matt16:07:06

Yes load-field! is exactly what I was looking for. Thanks!

Eric Dvorsak19:05:18

Trying out the statechart library for the first time, I'm rewriting a "modal wizard" (a modal window with multiple steps and different path). I'm quite liking how it allows to lay down the "map" of the wizard and quickly see the different branches, what can happen in each of them and at each steps. Previously I had tons of :ui/ attributes being queried, one of them being the :ui/step , the wizard component would be a giant case on ui/step matching to the corresponding subcomponent Atm I am assigning the UI component in :step as local-data when entering a step eg:

(entry-fn [_ _]
                                    [(ops/assign :step vocabulary-copy-paste-ui)])
It feels a bit wrong, I am thinking of simply having a big cond and rely on the statechart config (the set of active states) to determine the right UI component Am curious how others are doing this kind of things? It also feels like I don't need a query at all? the statechart can manage the whole wizard state and pass it down as props? In that case should the config be passed as props or computed-props? should it be part of the query of each subcomponent, at least the part they use? In the book example :blink-mode? is used, not part of the query but also used from the same component as the statechart there's no subcomponent

tony.kay21:05:25

In order for rendering to know what to refresh, you do have to query the statechart itself (e.g. the ident of the statechart in question), then yes, you can use the statechart configuration, and every time it changes the component will render.

tony.kay21:05:41

The chart configuration is definitely a thing to use in the UI. One other note: You can do a link query on jst the “table” name of statecharts in general. That’s fast to query on, though the componentShouldUpdate check will be a little slower then.

Eric Dvorsak22:05:52

And if I use the configuration then what's the best way to display the right ui component? A giant cond expression?