Fork me on GitHub
#fulcro
<
2019-12-13
>
daniel.spaniel17:12:28

What is the fulcro way to add filtering parameters to a query? Want to issue a query with filter params like date range, etc.

tony.kay17:12:42

(df/load … {:params {:start a :end b}}), then add a pathom plugin that puts the entry point prams into env so all resolvers can see them

tony.kay17:12:58

that is a “wrap parser plugin” that will merge all top-level params into :query-params and put it in env

tony.kay17:12:31

namespace your keywords if you think you might have multiple queries merged into one network request that have competing params

daniel.spaniel17:12:47

got it @tony.kay <> will give this a go .. thanks for tip

thosmos17:12:19

@dansudol I’m currently doing this inside my resolvers that take params

(let [params (-> env :ast :params)] ,,,)
but the plugin sounds like a good way to go too

daniel.spaniel17:12:36

sounds good @thosmos .. will try both

tony.kay17:12:36

The plugin makes it so you can see them all the way through the graph of resolvers, and not just the entry point one

tony.kay17:12:52

often you want to control something a layer or two down, but params only attach to the entry-point node

daniel.spaniel18:12:36

makes sense .. got it

tony.kay18:12:45

3.0.13 breaks mutation returns that rewrite the AST (i.e. UISM remote mutation return values). Please stay with .12 until I fix that (shortly)

eoliphant19:12:48

quick question, with the new ‘mutations everywere’ capability, just wanted a sanity check on something. in 2.x we had the initialization callbacks to init time stuff which is where I was handling things like seeing if the user had a valid Auth0 session. I’ve done this in some 3.0 code by just adding my check-session call to the end of the example init call. It calls the auth0 api, then either sets the session info or clears it via a mutation. Is this ‘ok’ at that place in the code?

(defn ^:export init []
...
(ui.r/init!)
(app/mount! SPA root/Root "app" {:initialize-state? false})
(auth/check-session SPA)
...
)

mdhaney19:12:20

In F3, during loads it automatically elides all :ui namespaces keys and the form state stuff, which is great. I was wondering - why not elide the dynamic router keys? Was there a particular reason?

tony.kay19:12:05

3.0.14-SNAPSHOT is on clojars…doing more rigorous testing now

tony.kay19:12:26

@mdhaney no, that feature just wasn’t made “wide” enough

tony.kay19:12:09

it is configurable, and F2 only removed :ui . It should really remove form config joins, ui, routing keys.

mdhaney19:12:15

If I added it, would you take a PR? I’m in a situation where it would be pretty useful.

tony.kay19:12:50

I would take a PR that covered all of the ones that are missing, but that would require you to review all current std features and see what to include

mdhaney19:12:55

Wait, where is it configurable? I was looking for it in the docs last night but couldn’t find it.

tony.kay19:12:15

fulcro-app The :global-eql-transform

mdhaney19:12:06

Ah, great. I’ll look into that. I knew I saw you say it was configurable before, but couldn’t find it in the docs.

tony.kay19:12:12

That affects the query just before network transmission, but leaves the query alone through the rest of the stack

tony.kay19:12:27

that’s part of what we’re fixing with 3.0.13+….it wasn’t quite at the right spot before

mdhaney19:12:47

Does it work for mutation joins as well?

tony.kay19:12:30

it is at the networking layer, so yes, it should

mdhaney19:12:48

That’s what I thought. Thanks!

mdhaney19:12:29

And what are you fixing in 3.0.13? Sorry, I’ve been out of the loop for the past week.

tony.kay19:12:55

The fix to the eql transform stuff didn’t thread things through quite well enough

tony.kay19:12:05

so .13 uses the wrong tx for merge IF you returned an alt AST from a mutation (which things like load and uism/trigger-remote-mutation! do)

mdhaney19:12:39

Ah, ok. So I should use the 3.0.14 snapshot if I’m going to try this, I suppose.

tony.kay19:12:15

but the fact that things weren’t mapped quite right caused things like pre-merge to misbehave

tony.kay19:12:29

it’s kind of a stack of issues when the middle tx processing isn’t perfect 😜

mdhaney19:12:47

Domino effect. Gotcha.

tony.kay19:12:04

I’m concerned that I’m going to break mark/sweep next 😞

fjolne22:12:36

Is there a deep reason why simple props with nil values are marked missing in mark-missing fn? That’s kinda a philosophical question of nil punning, but this way I can’t initialize incoming data-tree in pre-merge with nils. Could go with a custom keyword, of course, but that would require more ui-related work.

fjolne22:12:54

Also, I wonder what was the reason to check actually missing fields in fs/no-spec-or-valid?. This way all the user fields specs conforms against nils, which seem to complect the properties of the field itself with the :req semantics of its parent spec.

fjolne22:12:22

It’s ok for me to monkey-patch, I’m just sure there’re good reasons for such decisions, so insights would be of great value.

tony.kay23:12:54

OK, I think I got it. Version 3.0.15 of Fulcro on clojars. This should fix standing issues in Fulcro 3.x with pre-merge, eql-transforms, etc. 3.0.13 didn’t quite go far enough

tony.kay23:12:42

@fjolne.yngling mark missing was a very early add to Fulcro…very early..like 3 years ago. The central idea is only that “if you ask for something and don’t get it, you should remove it”. I don’t remember if/how/when we might have discussed nil punning.

tony.kay23:12:06

On form state: Not sure I understand your question…why would you ever want it to try to validate the spec if the spec isn’t in the registry? That would just throw an exception.

tony.kay23:12:44

oh…I think I see your question: your asking why are nils checked in form state spec validator? Because they may or may not be valid values according to your spec? Perhaps you’re seeing something I am not.

tony.kay23:12:59

Oh, I see…you mean for nested forms? I just didn’t consider that when writing it however long ago that was. I honestly don’t use specs in form validation…I wrote that code more as a demo of how you could do it.

tony.kay23:12:51

One more note: The internal logic for dealing with how merge works is pluggable. You can override default-result-action and internal-load with your own versions (that can be simple customizations of the built-in ones). No need to monkey-patch.

tony.kay23:12:08

That will affect loads and mutations system wide.

tony.kay23:12:02

The book needs more detail on that…it is mentioned in this section: http://book.fulcrologic.com/#_pessimistic_operation

tony.kay23:12:12

but if you use the source, it is quite easy