unrelated question to the above but still trying to clarify how validation in a form works. I have form fields declared in my component, the same form fields are reflected in the query/initial state. my component has an ident as well. for whatever reason, calling (fs/get-spec-validity props) returns :valid despite none of the fields being marked as complete.

any idea why that could be happening?

@mss I use the form state stuff regularly. It works. Are you remembering to add form config?

Are you following the book, or just doc strings? There are tons of examples with full source in the book.

I’m following the book. I was under the impression I was doing it correctly but clearly something is off. have the form-config-join added to my query

per the examples and book if something isn’t complete, it should be :unchecked. somehow getting a :valid result for my component’s props despite not calling mark-complete

the answer to my question: have you added the form config to your instance?

Looking in inspect, do you have a valid ident pointing from the instance’s form join to a real form config in state?

the functions cannot work properly if the config isn’t present. Could use better console error messages around that, if you’re not getting any

unfortunately working in an electron app and haven’t gotten the inspector to work with it

by “adding the form config to your instance” you mean :query [fs/form-config-join]

correct?

nope

add-form-config and add-form-config*

which MUST be run to initialized the form config on any instance that acts as a form (via a mutation, e.g.)

one is usable in initial state, the other inside of mutations

ah I was under the impression that add-form-config was only used when you wanted to integrate a newly generated ident whether on the client/server

nope, it records the “pristine” state, marks things as incomplete, etc.

that “state” has to go somewhere 🙂

gotcha, that def makes sense. so a call in the containing component would look like: :my-form-data (fp/get-initial-state (fs/add-form-config MyForm [:forms/by-id :my-form) {})?

wrapping the component before initial state is pulled?

no get-initial-state, and you’ll have to use the lambda form of initial state

I always do it in mutations…but I think that function returns the tree for the component with the tree added…so it would be:

(defsc X [_ _]
  {:initial-state (fn [params] (add-form-config X [:x/by-id 22] {:id 22 :x/name "boo" ...})

I’ve not build an electron app…is there any way to just build stuff in workspaces, and then combine the bits into the electron app? That would make life a lot better.

I mean, it isn’t native

and I build all my web stuff that way

ehh for bits and pieces yes but for certain things it’s basically impossible to work on sans an electron app. the fulcro-inspect has some code related to remote inspection and a client side script to start a server and broadcast changes. when I get some time I should take a crack at extending that and getting it working, would sidestep the whole issue

what pieces are electron-specific???

I mean: forms are pretty generic

(and I agree, Electron support in Inspect would be nice)

sandboxed webviews for third party content. the implementation is a little different on electron vs just an iframe

I should just pull these other bits out and work on them in an actual browser, you’re absolutely right 😝

@tony.kay Hello 🙂 I have a very specific question on error handling with Fulcro. I am trying to catch API requests that respond with 401 and, when it happens, redirect to some route. I read through the Fulcro book and it seems like the simplest way to do this would be to set a :network-error-callback. I did so, but it doesn’t seem to be triggered. Here’s my code:

(defn error-handler [state status-code error]
  (log/warn "Global callback:" error " with status code: " status-code))

(defn ^:export init []
  (reset! SPA (fc/new-fulcro-client
               :network-error-callback error-handler
...

Any idea why this could be? I cleared the shadow cache

@hmaurer not off the top of my head. The networking is involved (e.g. the remote you’ve configured)…if you used custom networking I think that might be able to break it.

Ah. I didn’t make any changes to the networking from the lein template:

(defn ^:export init []
  (reset! SPA (fc/new-fulcro-client
               :network-error-callback error-handler
               :started-callback (fn [elogic-beyond]
                                   (df/load elogic-beyond :all-users root/User))
                ;; This ensures your client can talk to a CSRF-protected server.
                ;; See middleware.clj to see how the token is embedded into the HTML
               :networking {:remote (net/fulcro-http-remote
                                     {:url                "/api"
                                      :request-middleware secured-request-middleware})}))
  (start))

says right in the doc string “Only works if you choose to use the default built-in networking (ignored if you also specify :networking).”

so, sorry…I didn’t think of that abt template

Ah, I see, sorry! I thought I was using the built-in networking and missed the “ignored if you specify :networking”

that explains it

So, you could just add to the middleware

and put your hook there

the networking layer is the only place that code is visible

💯, thank you

@tony.kay unrelated but while working with the new lein template I stumbled upon a bug with Hiccup 1.0.5 when you use dot classes in conjunction with dynamic classes, i.e. [:div.foo {:class (if error "has-error)}]. I asked weavejester and the bug has been fixed in Hiccup 2 alpha 2 (although I found another bug in that version for which I have yet to file an issue). Would you accept a PR on the lein template to upgrade to Hiccup 2 alpha 2?

or would you rather keep it on a non-alpha version?

I think hold off until a release, thanks

Quick q: what is the syntax/approach with Fulcro to “combine” queries of components? i.e. if a component renders two sub-components that each need to display “person” data, can I compose the queries of the two sub-components into the parent component?

And likewise, when using df/load, can I merge the queries of more than one component?

(if that makes sense)

short answer is “no”

normalization requires that queries by properly annotated with component metadata, which get-query does

so the long answer is “maybe”

but in general you just issue multiple loads…they get combined into one network request if they are submitted together

and yes, you can of course compose them into a parent (under unique keys)…not sure what you mean there @hmaurer

(defsc Parent [this props]
  {:query [{:spouse (prim/get-query Person) :children (prim/get-query Person)}]}

is fine

BUT this is definitely *NOT*:

(defsc BadParent [this props]
  ;; NEVER do this
  {:query (fn [] (into (prim/get-query A) (prim/get-query B)))})

yep, I think Pathom’s author mentioned metadata being associated to queries in his conj 2018 talk… which is why I was wondering how it could be done (since simply using into wouldn’t work)

ah, I see, ok

each get-query returns an annotated query

which is how normalization works

thus you cannot “steal or borrow” a query either

(defsc X [_ _]
  {:query (fn [] (prim/get-query Y))} ;; BAD idea

but this is fine:

(def shared-props [:x :y])

(defsc A [_ _]
  {:query (fn [] (into shared-props [:z]))})

(defsc B [_ _]
  {:query (fn [] (into shared-props [:b]))})

which is very different from before, because the earlier one was losing the distinction (and normalization info) between A/B as normalized components

so another one that is perfectly fine:

(defsc X [_ _]
  {:query (fn [] (into [:a :b] (zipmap [:spouse :children :best-friend :work-buddies] (repeat (prim/get-query Person)))))})

(assuming I didn’t make a typo)

this is fine because it’s just another way of writing a legal query: [:a :b {:spouse (prim/get-query Person)} ...]

FYI, get-query essentially returns (with-meta [:x] {:component X}) for a component X with query [:x]…nothing that special

it’s just recursive

Oh, that’s good to know. Also I was being silly, I think I just realised what I am asking might be the :>foo feature Pathom’s author talked about at conj. I am not sure what the name is

well, you write it that way, with your composition 🙂

placeholder is what Wilker calls them

but if I recall correctly it stays within the same resolution “context” but allows nesting, so you can fetch data for multiple components

ah yes, placeholders

right…you can “spread” person across the graph

very cool feature

not sure what term I prefer…“virtual edge” “self-reference”…

so am I correct in thinking that’s basically the solution to the “merging” issue? You can’t “merge” queries of child components because of the issues you described above, but you can use placeholders to achieve a similar result

but “placeholder” is good

“virtual edge” is a nice one

yep, and pathom just makes the magic happen

[:person/name {:>address [:person/street :person/city]}]

“invent-a-join” 😄

where the outer query would be on Person, and the inner on Address

yup, neat 🙂

thanks

Channel: So, I’ve been thinking that once a week I might be able to do something like a “group Q/A” via some kind of screen sharing service (YouTube? Twitch? Not sure what option would be best). This would be a paid attendance sort of thing, but the ideal would be for it to be like a coding dojo where we could share code/tips/etc. on Fulcro. Any interest?