This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-16
Channels
- # 100-days-of-code (1)
- # announcements (1)
- # beginners (93)
- # boot (46)
- # cider (40)
- # cljdoc (4)
- # cljs-dev (7)
- # clojure (78)
- # clojure-conj (12)
- # clojure-dev (17)
- # clojure-italy (5)
- # clojure-nl (10)
- # clojure-spec (34)
- # clojure-uk (36)
- # clojurescript (56)
- # code-reviews (6)
- # core-async (31)
- # cursive (12)
- # datascript (9)
- # datomic (19)
- # devops (2)
- # editors (3)
- # emacs (6)
- # events (2)
- # figwheel (1)
- # figwheel-main (11)
- # fulcro (59)
- # graphql (10)
- # hyperfiddle (3)
- # keechma (5)
- # leiningen (26)
- # luminus (1)
- # nrepl (5)
- # re-frame (5)
- # reitit (10)
- # shadow-cljs (64)
- # spacemacs (29)
- # tools-deps (6)
- # uncomplicate (8)
- # vim (2)
- # yada (4)
optimistic update failure…can use fallbacks, or mutations “returning” (e.g. have the server return the final value, like some other gql system), ptransact
to check result and react…some other possibilities too ::)
> The default fulcro networking does not do retries because it isn’t safe without the idempotent guarantee.
@tony.kay if, as you mentioned the other day, making mutations idempotent is potentially as simple as UUID-tagging them and checking those on the server, couldn’t this be implemented in the core?
> . “Can I log in with these credentials?“. Yes or no. This is a query and response, not an error handling interaction. Thus, something like login can be handled with a query (to get the answer) and post-mutation (to update the screen with a message or change the UI route). Do you have an example of this sort of “query, and based on response do a mutation”?
My use case wouldn’t be login but signup; check if email is already in use; if not, proceed to sign up
(defmutation login
"Mutation: Try logging in with the given `email` and `password`."
[{:keys [email password]}]
(action [{:keys [state]}]
(swap! state set-status* :authenticating))
(remote [{:keys [ast state]}]
(-> ast
(m/returning @state session/ServerSession)
(m/with-target [::session/session])))
(refresh [_]
[::session/session]))
this ?The client does something like
(df/load reconciler ::session Session {:post-mutation `check-session})
where check-session
is a post mutation that looks in ::session in state to see if it is a valid user
I am looking at the AST of a query:
dev:cljs.user=> (fulcro.client.primitives/query->ast [:foo])
{:type :root, :children [{:type :prop, :dispatch-key :foo, :key :foo}]}
In which cases can the :key and :dispatch-key differ?😄 perhaps I should phrase my question differently then: what are their respective roles?
:key
can be an ident, but dispatch key will only be the first element of the ident (for multimethod dispatch)
but [{[:table 2] [:x]}]
will have dispath keys :table and :x, but keys [:table 2] and :x (if I remember right)
because you would never want to write a defmethod
to “catch” the dispatch of an unlimited possible number of idents
Just released a new version of Fulcro Incubator with declare-mutation
…a way to get rid of quoting in transact!
and the problems with mutations sometimes wanting circular refs to the UI
Quick question on the approach to full-stack error handling. Am I correct in understanding that any form of server-side validation (check if email unique on signup, or check other invariants that can only be checked on the server) should be handled using a plain-data response from the mutation in question? i.e. have the mutation return Either ValidationFailure SuccessPayload
, store that result in the global state and switch the UI based on that?
@hmaurer that is how I'm doing it. Exceptions go into the global exception handler, there not really for local logic.
If I have a mutation (say "ensure-article-loaded") with a load-action, which has a post-mutation of itself. How do I make sure this is not recursively executed if for some reason it cannot be satisfied. From my research into this I would need to check if :load-request is not already added to the environment. But I feel like this might be common case and is already handled somehow?
@johnny the point of the name is that your mutation should conditionally call load-action
…remote-load is a noop if there are no actions queued.
if you mean “executed twice”, then I would say examine your logic…if, for example, you were running this in a react lifecycle that was on a to-many component I could see how you might be worried…in that case your mutation should put something in the state that indicates each item that is loading (which will be overwritten by the load).
Yeah Iam already calling the load-action conditionally, it's just that it can return with nothing in some cases.
that your component will tolerate as “nothing” or “loading”…then your post-mutation can still fix it up (if necessary)
guess I could technically make the function get-initial-state
not require params…just haven’t 🙂