https://github.com/holyjak/fulcro-troubleshooting reached a new milestone - it does not report any unexpected errors/warnings for the fulcro-rad-demo. (Only when you edit an account will it warn about missing data for :account/files
but that is one of the examples where you have to manually tell the library that there is nothing to worry about in this case.)
Please give it a try and tell me how it is working for you! Does it help you to avoid mistakes / discover problems earlier? 🙏
In workspaces, since the app is configured through ::ct.fulcro/app
instead of (app/fulcro-app)
, how do we refer to the app or get the current-state in a workspace? Thank you!
Thanks Tony for the pointer!
If I am not mistaken, I found the defs in the nubank.workspaces.data
namespace. Through @data/active-cards*
, I can see the data tree directly inside the large map output. However, when I try to get-in the map with the card-id, there is an undeclared Var error, probably due to the defcard
macro not being recognized... While I'd like to find a way to use fdn/db->tree
, I wonder if I am heading the right direction or I should settle with using @data/active-cards*
?
Just realized that this was indeed a non-issue... Since, we never use Fulcro in a headless way in workspaces, Fulcro Inspect is the way to go if we ever need to look at the data. Really enjoy learning Fulcro. It is challenging yet simple, simply beautiful. Thanks so much Tony for sharing it with us.
Normally, I use the :started-callback
option in ::ct.fulcro/app
to access the app.
However, I am looking for a way to access the app or current-state in a workspace so I can, for example, send fdn/db->tree
to REPL from a comment block to take a look at the data tree.
I’m trying to figure out how to parse and work with errors on my client (I want to log the user out on a 401).
But I can’t seem to see the errors on the client. They seem to be omitted from the response.
When I call the parser directly in my nrepl, I see the :com.wsscode.pathom.core/errors
key in the response as expected. However, when the parser is called and handled by the fulcro handle-api-request
the error key disappears.
I can share more code and context, but I just wanted to check if there’s something obvious I’ve missed
hmm, seems to be on the client. Just logged the response from “handle-api-request”:
The result: {:status 200, :body {:entries nil, :com.wsscode.pathom.core/errors {[:entries] {:errors {:message "Unauthorized.", :data {:type :unauthorized, :payload {}}}}}}}
But if I log the body in remote-error?
the :com.wsscode.pathom.core/errors
doesn’t show up
@aleksander990 Have you seen @holyjak’s article about 3 approaches to error handling? https://blog.jakubholy.net/2020/error-handling-in-fulcro/ It’s about server-side errors but it might give you some insights.
@alex-eberts this was exactly the article I was going through (Great content, that adds to the docs in the book.) I got stuck though, since I’m not getting the error object on my client. It gets weirder still:
If I trigger the query through my client code (either the nrepl or through the interface. I get the first.) No errors in the response. If I, however, send the exact same thing through the fulcro-inspect query tab, I get the expected result: The last screenshot shows the requests as they’re logged on the server. The transaction is identical
The response that’s sent from the backend is identical
I wonder if a pathom parser plugin in filtering errors for some reason?
Wouldn’t that be done before this step?
(defn wrap-api [handler
{:keys [uri
parser]}]
(fn [request]
(cond
;; Let's return a health check if params aren't provided
(nil? (:transit-params request)) {:status 200
:headers {"Content-Type" "text/plain"}
:body "OK"}
(= uri (:uri request)) (let [res (handle-api-request (:transit-params request)
(fn [tx] (parser {:ring/request request} tx)))]
(log/info "The res: " res)
res)
:else (handler request))))
In the fulcro-template it’s in app.server-components.pathom.clj
Look at the brlrowser dev tools (not Fulcro dev tools) Network tab and decode the transit. Do request / response look the same in both cases?
What I mean by this step:
I’m logging the result of calling handle-api-request
to check that the output of pathom is correct.
It’s identical in both cases (triggered by df/load!
and triggered by fulcro-inspect
Also notice you will not get the errors unless your query is asking for them (or something adds them to it for you)
@holyjak how would you do that using df/load!
Do I have to add :com.wsscode.pathom.code/errors
somewhere in my code? (I don’t see that being done anywhere in the example article)
This is the result of running the df/load!
Notice how the “res: ” part prints exactly what’s returned from the handle-api-request
call:
The response is identical when I do it through fulcro inspect
But the errors show up then
As I said, when you look at the Network tab of the browser, are the req and responses identical in thw two cases or do they differ? How?
I cannot find it by I think I remember that the Fulcro client code did not "see" the errors even if they were in the response unless I asked for it. Could be due to some pre- transformation... Let me find it.
Yes, sentence 1 right under https://blog.jakubholy.net/2020/error-handling-in-fulcro/#_detect_errors
(I’ll try getting the network tab working for React Native in the meantime. All I know is that what’s hitting the server and leaving the server is identical)
that sounds like it
Ah, I see, you have RN, then I understand it is more complicated 🙂
Thank you @holyjak, I’ll try that
my pleasure. Good luck! Improvement suggestions for the article always welcome 🙂
I must admit to having scanned it. I, rather foolishly, assumed that fulcro would receive it if it was in the output
More of a fulcro improvement:
I’m copy pasting the logic for the global-eql-transform right now, but it’s rather verbose. I don’t think I would have figured it out without the pointer in your article. And as a result, would have struggled to find out how to handle errors in Fulcro at all.
It might just be me, but I find error handling and understanding how to do it to be central to working with any framework.
Could it make sense to include what’s in your article in the Fulcro Book, and/or provide a default global-eql-transform
in the main fulcro libary?
The error handling in my article goes contrary to the approach that Tony prefers and which works just fine in most cases, ie returning errors as data. Not sure what would be best for Fulcro in the longer term. Perhaps best to wait and see what people do/use before committing to anything :)
On a second thought, I think Fulcro should request the pathom errors by default. As you said, it is non-trivial to figure out.
If I remember right that app generator generates defs behind the scenes
vague memory…check out the source
copilot question: is there a way to reserve a spot for the copilot closed alpha, when that starts? 🙂
@meditans Actually Copilot is stalled right now. We’ve got a working version that has limitations, and a design for the next phase that gets past those limitations, but no manpower to work on it. Another of our ventures is going well and is consuming all manpower, and Copilot is considered a riskier venture (will developers actually pay for it? etc.). Ultimately we have to do what pays the bills. I’m considering finding a new partner that would be willing/able to finish the project, but it is unlikely to advance further until that happens.
yep
I see, thank you very much for the update, and of course I understand that decision! (as a data point though - I'd probably pay for it). What would you suggest to read (papers, books, ...) should I have an interest in the space?
@tony.kay and, if I may ask, when you say partner
are you envisioning more something like a developer or an external firm?
Sorry for all the questions, but it's an extremely interesting project for me, coming from the Haskell world and learning the Clojure way 🙂
no worries. Partner = Someone willing to take a share of ownership in the project (i.e. profit sharing on sales) in exchange for work. Someone that is willing to take risk and work for equity.