Thanks for the feedback. The autocomplete kinds of cases are definitely the ones where I see the clearest improvements. Other cases might make as much mess as they clean up, but this use-case seems pretty much just a win.

of course you should do that. Save middleware is where you put that logic. RAD cannot write that for you because it does not know anything about your security concerns (how you model permissions/ownership) nor do I personally plan to write a general system for everyone. If you model an ownership system where each entity can be easily checked (e.g. a field on every entity that points to the owner), then a simple permission check in the save middleware is basically this: For each ident in the form diff (each entity to save): Pull the ownership field and check against session. If any fail, deny the save.

make a virtual attribute that represents the label (and can resolve it with input of the row id -> ::pc/resolve on the back-end). Then just add that virtual attribute as a column on the table.

https://gist.github.com/holyjak/207ed33c9ee7e003b9a779fa47c32d91#displaying-to-one-ref-attributes

We updated Fulcro to try to improve the error messages it gives. Does that one give you a stack trace? If not, you can set a source breakpoint on the components:874 in js tools in Chrome.

It is possible that the error is mis-detecting something that is OK, and could therefore be a bug in the new error checking. (The errors should not affect behavior…if it was working, it should still work. they are informational)

I’d love to know which it is: problem with your code, or problem with the error check.

https://github.com/holyjak/tmp-fulcro-errors/blob/master/appendix-fulcro-errors-and-warnings.adoc#user-content-err-comp-props-not-a-map

I likely says "of the type function" because to JavaScript, all cljs data structures look like a function. This is the code:

(when-not ((fnil map? {}) (gobj/get props "fulcro$value"))
                    (log/error "Props passed to" (component-name class) "are of the type"
                      (type (gobj/get props "fulcro$value"))
                      "instead of a map. Perhaps you meant to `map` the component over the props?"))

Yes, there is a stacktrace. I've copied it to https://gist.github.com/carrete/f5f2bff186118f408825cfa16f6b8123 It's triggered by the onClick event below:

(defonce ^:private history
  (pushy/pushy
    (fn [path]
      (dr/change-route! app path))
    identity))

(defn route-to!
  [path]
  (pushy/set-token! history path))

:onClick #(route-to! (dr/path-to DrawingUpload))

From https://github.com/holyjak/tmp-fulcro-errors/blob/master/appendix-fulcro-errors-and-warnings.adoc#user-content-err-comp-props-not-a-map, The props definitely shouldn't be a list, but I'll look. Thanks

Add to which I'm not calling the factory of the component. I'm not sure where that happens when something is routed to

In the body of the problematic component, can you log the props to see what type it has?

The "function" has a root and a tail and a count so it looks like a list / vector?

The props is the component's ident, [:componet/id :drawings-upload]. The component is a singleton, but this seems wrong, right?

Here's the top part of the component:

(defsc DrawingUpload
  [this {:keys [drawing/kind
                ui/attachment]
         :as props}]
  {:query [:drawing/kind
           :ui/attachment
           form-state/form-config-join]
   :ident (fn [] [:component/id :drawings-upload])
   :initial-state (fn [_]
                    (form-state/add-form-config DrawingUpload
                                                {:drawing/kind nil
                                                 :ui/attachment nil}))
   :route-segment ["drawings" "upload"]
   :form-fields #{:drawing/kind :ui/attachment}}
  (println props)
  ...)

I also see WARN [com.fulcrologic.fulcro.routing.dynamic-routing:263] - More than one route target matches ("drawings" "upload") which seems impossible. There are only a few components with route segments. All of them unique

As well as ERROR [com.fulcrologic.fulcro.algorithms.form-state:554] - FORM NOT NORMALIZED: [:component/id :drawings-upload] I'm not sure if these are related. The two errors above about props not being a map and duplicate route targets happen when the onClick event is triggered. This error is triggered when form values are changed and set-value! is called

Oh this is bonkers. TGIF! I formatted some things which triggered a rebuild and now props is correct. The duplicate routes and not normalized form errors remain though :face_with_symbols_on_mouth:

Hold on. It's back after a shift+reload in the browser

I don't see the component's ident in :com.fulcrologic.fulcro.algorithms.form-state/forms-by-ident

Nor do I see the component in the denormalized db. However, I do see other singleton's under :component/id

Remember that initial state is a composition to root for the first animation frame drawn on your entire app. If D.U. isn’t composed to root initial state, then you won’t get that form config, and the props for it will start out nil. If you’ve then done other operations to make the thing sorta work, then it is likely you forgot to actually add the form config (because you thought you already had).

Worry less about the details of the warning, and try following the data graph in the DB (e.g. via DB Explorer, where you can click on idents to follow the data tree). If you cannot follow the path from root UI through db to the leaf, then your state is just wrong, and initial state is probably the error.

Thanks @U0CKQ19AQ. I understand completely. I do understand it's an indication of a serious problem that I can't navigate to the component in the db explorer in the inspector. I am however at a loss to know where to look next. The onClick event and component, minus its dom output, are above and they seem correct to me. Previously form config state was added in the pre-merge hook, but I don't see that being used in the documentation or templates any more. I saw an example of that being added in the initial-state hook so that's where it is now. It's quite possible that I need to make another similar change. There is no factory for this component. It's listed in the site's router and is rendered when it's routed to via the onClick event. This is where my understanding of fulcro goes into hand wavy magical black box territory. Currently my only guides are the error messages above. When I look at how the initial state is setup, my understanding of fulcro isn't deep enough such that the error is obvious. If things look like what's in the documentation or a template then it looks correct to me, even if it isn't. I'll keep digging though. I'll try to create a smaller, reproduction of the problem. That's helped me before when I was in a similar situation. Thanks again

welcome. The magical black box feeling is something you should address first. Get a clear understanding of how Fulcro works…to do any less is to waste a ton of your time. I’d recommend the new grokking Fulcro series if you have already been using it for a while….particularly the state stuff around episode 3a: https://www.youtube.com/watch?v=r1bMQxTr2QA&list=PLVi9lDx-4C_TBRiHfjnjXaK2J3BIUDPnf&index=3&ab_channel=TonyKay

Fulcro is very very simple, but if you make assumptions about how it works and just try to follow examples without understanding the specifics it will be much much harder than other things you’ve used. If you take the opposite approach you’ll benefit a lot more, and I hope you’ll find the understanding it (in a deep way) is very much easier than other systems.

Thanks. I haven’t seen the new video series, yet. I have watched the original series on youtube, read the book, looked through the templates, and lurked on this channel. I’ll review these things as well as watch the new video series. I had forgotten about it. Thanks for the reminder

Yeah, I continue to try to find ways to get across the core bits. There’s a forest vs. tree thing going on that is much worse than I expected.

@U0P7ZBZCK after this https://github.com/fulcrologic/fulcro/pull/472 you hopefully get a better error msg

I don't really follow. m/returning is about what the mutation returns while params are about the (extra) inputs it gets?

m/with-params

but that changes the params of the mutation…

that’s an interesting use-case. It’s just AST manipulation…so you could rewrite the returning bit to include params

I was trying that, but my env -> query-params were still showing up as empty... I also tried pulling it from env -> ast -> params but no luck... will try again later today (on phone at the moment)

(I tried m/with-params) to be specific Was thinking about a custom ast manipulation, can look into that

so, on the server-side the query params in the env are extracted by a plugin I think, right? Not normal pathom logic.

so, you might have to tweak both sides, since the returning logic is a post-parse from the mutation processing

but as far as adding params to the query itself, I think that should work…give me a sec

Try SHA 2b5dff2e9f34ff6f47a5f1bcc36bc088a14c552d

I added a returning that supports an extra arg for query params, which it will then put on the returning query. You’ll still need to look for them (they’ll be on the first prop of the query AST on the server)…to get them into the env would require a bit more work I think

Thanks Tony, will try it out when home!

@U0CKQ19AQ having trouble testing it.. getting:

Syntax error compiling at (com/fulcrologic/fulcro_i18n/i18n.cljc:102:22).
No such var: comp/*shared*

com.fulcrologic/fulcro-i18n            {:mvn/version "0.0.5-alpha"}

com.fulcrologic.rad.picker-options

i think i may just have to update i18n to use rc/*shared* — can try that EDIT: compiling now — testing

bah…I moved that var

that’s a pain

no worries, got it working! Heres the query-params logic:

(def query-params-to-env-plugin
  "Adds top-level load params to env, so nested parsing layers can see them."
  {::p/wrap-parser
   (fn [parser]
     (fn [env tx]
       (let [children     (-> tx eql/query->ast :children)
             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)]
         (parser env tx))))})

Try this commit for the shared fix: 50f7c0d6dce72d7f55634db84b9acabda1ed5df5

be interested in knowing that that fixes your compile error. I do not intend for 3.5 to break projects

@U0CKQ19AQ that fixed it, thanks!

after releasing 3.5 i can submit a PR for i18n to update to rc/*shared* if thats still the strategy

no, I moved it back

there was no need to move it after all, which is good

:thumbsup:

if you have thoughts on if adding the query-params from the mutations load to the env in query-params-to-env-plugin is something you’d like merged in, happy to make a PR or work on a better approach — definitely understand if you dont have time to think about it though.

It would be nice to have it. The load primitive of Fulcro always has a single top-level key, so for single loads that plugin is fine (at the parser level), but mutations (as you noted) are not so clear-cut, since more than one can be sent, and as a result each could have its own query params. So, the general solution would have to change the env value based on which mutation was running…but env is immutable, so some possible solutions are: • Merge all of the query params together into one map. Key collision is then possible and undesirable. • Figure out how to rewrite the env after a mutation. I don’t know if @U066U8JQJ has any fancy tricks built-in, but you could use wrap-parser to put an atom in the top-level env like :alternate-env (atom nil) and then add a wrap-read and wrap-mutate that pass that as env when it is non-nil. That way a return on a mutation that needs to change query params could do so by resetting the alt env. • Others???