This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-29
Channels
- # babashka (168)
- # beginners (60)
- # calva (21)
- # cider (44)
- # clj-kondo (27)
- # cljs-dev (4)
- # cljsrn (2)
- # clojure (157)
- # clojure-australia (27)
- # clojure-bay-area (7)
- # clojure-czech (1)
- # clojure-europe (94)
- # clojure-nl (2)
- # clojure-spec (3)
- # clojure-sweden (11)
- # clojure-uk (35)
- # clojurescript (19)
- # cursive (12)
- # events (1)
- # figwheel-main (1)
- # fulcro (28)
- # honeysql (7)
- # jackdaw (9)
- # kaocha (4)
- # keechma (1)
- # malli (7)
- # midje (1)
- # missionary (1)
- # music (1)
- # off-topic (45)
- # pathom (18)
- # polylith (6)
- # practicalli (4)
- # random (1)
- # reagent (3)
- # reitit (3)
- # shadow-cljs (74)
- # sql (9)
https://github.com/fulcrologic/fulcro/blob/feature/fulcro-3.5/src/main/com/fulcrologic/fulcro/react/hooks.cljc#L336
It actually removes the statemachine from app-state, not just unmount. I guess I can use use-component
instead of use-uism
, since in my case it doesn't initialize/ is long lived.
That API is not finalized, and should be richer. Of course you should be able to use an existing state machine. You should also be able to supply the actors on initialization. The current API is just a draft to scope out the general shape
yes, I understood it's very much in flux still. it was just an fyi. I'm experimenting myself now with a small macro to step through a "spec" with events on the various state machines in my app. It's really nice!
is there a way to always nilify-not-found
, other than explicitly handling in pre-merge? if it's even a good idea
could you please explain a little more what you mean? set to nil in the client db when not found in Pathom?
But sweep-merge
does that already, no?
or do you want, instead of removing the data from the client db set them to nil? If so, why? The common clojure best practice is to omit the keys instead of using nil values.
not sure what you mean by removing. what I mean is, when you have :query [{:foo [:bar]}]
, when you load that component, if pathom returns nil for :bar
, :bar
will have the value of ::merge/not-found in app state, unless you nilify it in explicitly pre-merge
> will have the value of ::merge/not-found in app state
by app state, do you mean Fulcro client DB? sweep-merge
called by merge-tree
and merge-mutation-joins
, which are both called by merge*
, does remove such data from the client DB.
From your question I guess your problem is that Fulcro marks as not-found and thus removes some data you do not want removed and you are trying to prevent that by getting rid of those not-found?
From the previous discussion:
> marking fields as ::merge/not-found even though they are being queried for
that is the whole point, if you query for a prop and Pathom has no data for it then Fulcro will mark it as not-found via mark-missing
Ah, I see
> the server is responding with those keys in the map, but their value is nil.
What is the bigger problem you are trying to solve? What do you want? You want the server to return nil
and Fulcro then to store nil
into the client DB? Why would that be different from simply removing the corresponding prop from the client DB? Since (= (get {:k nil} :k) (get {} :k))
?
still not sure what you mean by remove. I'm loading data, e.g. bar
, and I might like to use bar in render like (map fn bar)
, and that blows up if bar is a keyword but works if it's nil
at no point am I thinking about deleting data from the client db; I just want to use the data I loaded without any surprises
that being said, there actually is a use case I have for nil value vs no key: caching
e.g. don't load keys that have already been loaded. if nil is never merged, then I don't know that that key has already been loaded
Remember how Fulcro works. Loads puts data into the client DB (and it can also remove data, ie entities and their props from there). Then Fulcro gives your component props based on the client DB. Are you saying that you see :not-found in the props of the component?
That is weird. And you say that doing what you did in pre merge prevents it? But pre merge only influences what data comes into the client DB and props come from there. So what is the diff in client DB in the two cases (with and without pre merge nillify)?
yes, nilify-not-found in pre-merge (what @dvingo posted in the later log I linked above) will result in the nil returns having values of nil
in the client db/props, instead of ::not-found.
not sure what you mean by "only" influences the client db data. is there a larger scope you're thinking of?
It's been a while, but I think I was passing the data in pre-merge
to an entity construction function that had guardrails annotations and the ::not-found values were causing the instrument check to throw.
I used this helper to remove them:
https://github.com/dvingo/my-clj-utils/blob/master/src/main/dv/fulcro_util_common.cljc#L169
I suppose you could try incorporating this helper in the :global-eql-transform of the fulcro app to get this as default behavior.
I mean that load and pre-merge have in a way nothing to do with the props your component sees. They only affect what data ends up in the client DB. Then, when you render, Fulcro reads from the client DB to construct the props for the component. So if you are saying there is a difference then there must be a difference in the data and the client DB. What is it?