This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-13
Channels
- # announcements (1)
- # babashka (12)
- # beginners (10)
- # biff (9)
- # calva (2)
- # cherry (21)
- # cider (14)
- # clj-commons (76)
- # clj-kondo (8)
- # clj-on-windows (34)
- # cljs-dev (5)
- # clojure (48)
- # clojure-austin (7)
- # clojure-europe (97)
- # clojure-nl (1)
- # clojure-norway (14)
- # clojure-uk (22)
- # clojurescript (137)
- # conjure (33)
- # cursive (4)
- # datalevin (1)
- # deps-new (4)
- # devcards (2)
- # duct (3)
- # events (1)
- # fulcro (12)
- # graphql (9)
- # hyperfiddle (16)
- # jobs (8)
- # kaocha (1)
- # leiningen (6)
- # lsp (39)
- # malli (38)
- # membrane (20)
- # nbb (68)
- # observability (7)
- # off-topic (49)
- # pathom (11)
- # polylith (8)
- # portal (22)
- # re-frame (6)
- # releases (1)
- # remote-jobs (2)
- # shadow-cljs (24)
- # spacemacs (2)
- # squint (6)
- # xtdb (7)
In the report's body, I would like to add a link to download csv. How to get env to call report/current-control-parameters?
This is report's body:
(comp/fragment
(when (:ui/detail-dlg? props)
(render-detail this (:status props)))
(report/render-layout this)
(pr-str (report/current-control-parameters env))) ;; <-- env?
Via com.fulcrologic.fulcro.ui-state-machines/state-machine-env
I suppose. But feels ugly to be using these two fns here in a render body. I would consider creating a helper fn that simply takes the report instance and returns the url.
@UQ5QFFX54 that function is meant for internal use with the UISM. If you want the control values in rendering, using control/current-value
instead
@tony.kay What would be a good way to get Pathom 3 errors visible to :remote-error?
? Pathom sends them under :com.wsscode.pathom3.connect.runner/attribute-errors
but I do not actually want to send that over wire because pathom (despite occasionally sending it) will complain that it is an unknown attribute. And if I do not include it in the AST then tx-processing https://github.com/fulcrologic/fulcro/blob/5dfefc0c5ddbf03057b33dff053d26539e44fc35/src/main/com/fulcrologic/fulcro/algorithms/tx_processing.cljc#L125 before any part of my code can see it 😭 So I guess my only realistic options are to add some Pathom plugin to stop Pathom from complaining about not knowing this (eg by removing it from the AST). Thank you!
Some options:
1. Auto-add it to the Fulcro query via global eql transform, then on the server elide it from what you hand to pathom. That will make Fulcro expect it, but will prevent pathom from worrying about seeing it as something you want.
2. Add network middleware on Fulcro to pull the errors out of body
before they are returned to the tx layer, and do something with them there (this would be global error handling). For example the tx options include :ref
if the transact was against a component (the ident of the component). You could merge the errors against the state of that component under a well-known UI key, or pop a toast, etc.
3. Bug Wilker about it on #pathom and tell him he should allow the caller to ask for the errors, since that should actually be a valid thing to do if the client itself plans on wanting them. This is sort of a pedantic opinion on my part: the query processing should never return something you don’t ask for as part of the response. Throwing exceptions would be ok, but returning data that isn’t in the query is just “wrong”. The client should have to ask for the errors as data if they want them that way.
(1) is probably what I’d prefer, since it just lets Fulcro pretend the errors were asked for to begin with.
but (2) works just fine as well, assuming you know what you want to do with the errors.
Thx a lot! I will go with 1 and 3 🙂
Me bugging Wilker here https://github.com/wilkerlucio/pathom3/issues/156
ANN: https://github.com/holyjak/minimalist-fulcro-template - a minimalist template for a fullstack Fulcro app for learning and experimentation - simpler than the official fulcro-template (and, contrary to that one, not intended for production). Based on Pathom 3. It is very early so may have some rough edges in docs and code.