Clojurians Log v2

:req nil? ?

Good to hear. I personally like knowing how things work, so they’re fun to make from that point of view. A lot of the little minutiae are really mostly useful for super-advanced use-cases (e.g. I’ve never made a custom factory in any of my apps, but I could see the need to at some point….I honestly forgot about props middleware until I saw it while making the video yesterday, etc.).

No. Make latest when you insert the data in your client DB. How else could it be inserted to a unique place?

Part 5 of G.F. is uploading now.

Looks like 30 mins…

The videos are simply awesome! Thanks so much Tony for taking the time to teach us and help us to really grok Fulcro. P.S. it seems Part 5 is not yet added to the G.F. playlist.

(defsc ShirtList
  [this {:keys [shirt-list/shirt-names]}]
  {:query [{:shirt-list/shirt-names (fcomps/get-query ShirtName)}]
   :ident (fn [] [:shirt-list/color shirt-color])
   :route-segment ["shirts" :shirt-color]
   :initial-state {:shirt-list/shirt-names []}
   :will-enter
   (fn [app {:keys [shirt-color]}]
     (dr/route-deferred [:shirt-list/color shirt-color]
       #(load! app :shirt-list/shirts ShirtName
          {:fallback `errors-mutations/check-response
           :params {:shirt/color (keyword "shirt.color" shirt-color)}
           :target [:shirt-list/color shirt-color :shirt-list/shirt-names]
           :post-mutation `dr/target-ready
           :post-mutation-params {:target [:shirt-list/color shirt-color]}})))}
  (dom/div
    (map #(ui-shirt-name %) shirt-names)))

Hey, I think I may have figured it out! Like you said, return a unique id in the pathom query. Took me a while to see how that would work :man-facepalming: The example component above is what I've been working with (incorrectly), but now I understand your earlier suggestion. Thanks!

OK, this is probably super obvious to the point that I cannot figure it out. Looking at https://github.com/fulcrologic/fulcro-rad-demo/blob/develop/src/shared/com/example/model/authorization.clj, there is a function that has an env as a parameter. If I wanted to run the login! function in REPL, assuming the Fulcro RAD demo server has been started, what would I use for env parameter?

I was confused because the component already knows about the shirt color because it's a part of the route params. It wasn't obvious to me that the solution was to have the resolver echo it back. I thought the component should just be able to make use of it

Right. The code above looks fine - you get the color from the route params and use it for the target-ready and to store the data in the right place of the client db. But as you point out, the data stored also need to include the color so either the resolver has to "echo it back" or you need :pre-merge or some post-mutation/action to add it in. (Though perhaps pre-merge cannot "see" it...)

If you can think of any way to make the documentation clearer on this point, please suggest it!

> I was confused because the component already knows about the shirt color Yes, the component inside will-enter "knows" it but we also still need to make sure that it will be included in its props because ID always needs to be there. And Fulcro will not magically add it for you even though it could, in theory.

Thanks again for your help @holyjak

my pleasure 🙂 FYI I to those interested enough, I offer pair-programming help. The first hour is free without any obligation to continue after that. So if you run into some hairy issues, you can consider that 🙂

Awesome! I will definitely keep that in mind

ooops

The env is built by the plugins of the pathom parser. So, typically you’d write a login mutation, which would then be auto-passed an env when invoked through pathom. Otherwise, env is just a map, and you largely define what is in it. If the function in question doesn’t use much (or anything) from the env, then just make a map that has what it needs.

In this case, it expects env to have the Ring request which it expects has a session {:ring/request {:session {…}}.

(`get-login-info`, I think, uses the database connections out of env as well)

Under https://blog.jakubholy.net/2020/troubleshooting-fulcro/#_backend_pathom look at 1.d

Whoops. I have correct the example and the result is the same.

The second explain results. It is as if guardrails is generating some data as a kv-pair when it should be generating it as a map (of course, this is only a guess)

https://github.com/holyjak/fulcro-troubleshooting has been updated to check also idents are correct and that you are not missing data for joins (ie. your children) - typically because you loaded data into the wrong place or forgot initial state for a comp. that has only link queries. Please see the docs and give it a try! 🙏

Ok, this does shed the light on things. Probably quick and easy prototyping is to compose a map and feed it to the fn.

@hadilsabbagh18 https://clojurians.slack.com/archives/C68M60S4F/p1614110142063000 would have showed you the ident mistake. Though I guess I need to replace dom/div and p with something else for native... Any suggestions?

Hi @holyjak. I am not thrown off by regular React. My biggest problems seem to be grokking the root component of my UI tree. I just don't know how to connect it to my load!

I just missed it into your Fulcro Troubleshooting Decision Tree, that's all. I've been reading carefully.

Side effects: I’m following the Login example from the fulcro template and so far everything makes sense. I’m still getting used to a lot of the framework indirection: eg. calling uism/trigger-remote-mutation understanding m/returning will send data to the component you specify and you’ll handle that in pre-merge is a little gnarly for me. Anyways, I’m using a token based flow, and I’d like to save the token to local storage so I can load it (or the refresh token), when the app starts up again. What would be the idiomatic way to achieve that? My current solution is to sneak in a (token-store/save-token token) call in the pre-merge call of the m/returning component, but I’m not sure about the lifecycle and implications of this

(defsc Auth
  "Auth representation. Used primarily for server queries. 
   On-screen representation happens in Login component."
  [_ _]
  {;; The fields we're querying in our local database
   :query         [:user/id :token]
   :ident         (fn [] [:component/id :auth])
   :pre-merge     (fn [{:keys [data-tree]}]
                    ;; Save the token if provided
                    (when (some? (:token data-tree))
                      (token-store/save-token (:token data-tree)))
                    (merge {:user/id ""}
                      data-tree))
   ;; Default initial state
   :initial-state {}})

Just to clarify : m/returning will not "send data to the component you specify". It tells Fulcro that the mutation returns a data and what data that is (described by the given component, because, remember, components describe your data model) so that it knows where to put it (based on the ident). Normally I would do storing of the token in ok-action of a mutation or in another mutation this triggers. But I haven't looked at your example so I might be off the mark here. Pre-merge certainly feels as the wrong place for side-effects. Those belong in mutations.

Thank you for the pointer. Digging for the event-data right now. Another thing: Is there a way to load app state side band? I’m asking because I need to add the token to my api request. Right now i’m loading it from an atom, but I’m thinking it might make more sense to load it from the client db where it’s saved anyways:

(defn wrap-with-token [req]
;; Could I load the token from the Auth 
;; component instead?
  (if-let [token @token-store]
    (assoc-in req [:headers "Authorization"] token)
    req))

I personally do not use pre-merge a lot, and that particular use of pre-merge is not great. I’d prefer that side-effect be in the UISM. Here’s what I’d probably do (in a UISM): On UISM start (which is app start, I’m guessing), I’d pull the token from localstorage (if present) and put it in app state. I’d use an alias for the Auth’s field that represents that token, so it is just an assoc-alias call. On the state that tries to log in you can tell it what events to fire as a result of a mutation. So, you’d trigger the remote mutation to do the login, with a returning of Auth…but you don’t need pre-merge because you already have the alias to where the token is in state, it’s just the aliased value. So, the event handler in UISM can just look to see if it got a valid token. Some other alias might track where you store your login error, etc.

on your second question: your middleware wrapper could use the app to pull state:

(defn wrap-token [app] (fn [req] ...))

That typically creates a circ ref, so this is where an app atom could be handy to break the cycle (app uses remote uses middleware uses app)

ohhh… Interesting… I’ll try that out @tony.kay. The aliased way. For pulling out of env I created this helper:

(defn env->mutation-result
  [env mutation]
  (get-in env [::uism/event-data ::uism/mutation-result :body mutation]))

yeah, don’t do that….it’s going into state already

I do have an app atom. Which function would allow me to pull it from the app atom? (The good thing about the book is that it contains almost everything I need. The bad thing is finding out where it is can be a little tricky)