Fork me on GitHub
#fulcro
<
2021-04-29
>
bbss07:04:33

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.

tony.kay22:04:30

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

bbss12:05:47

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!

nivekuil19:04:31

is there a way to always nilify-not-found, other than explicitly handling in pre-merge? if it's even a good idea

Jakub Holý (HolyJak)07:04:38

could you please explain a little more what you mean? set to nil in the client db when not found in Pathom?

nivekuil07:04:08

yup, doing what you would use merge/nilify-not-found for, but less manually

Jakub Holý (HolyJak)07:04:38

But sweep-merge does that already, no?

Jakub Holý (HolyJak)07:04:36

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.

nivekuil07:04:21

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

nivekuil07:04:19

some prior discussion

Jakub Holý (HolyJak)07:04:26

> 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.

Jakub Holý (HolyJak)08:04:00

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)) ?

nivekuil08:04:57

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

nivekuil08:04:49

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

nivekuil08:04:55

that being said, there actually is a use case I have for nil value vs no key: caching

nivekuil08:04:19

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

Jakub Holý (HolyJak)13:04:50

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?

nivekuil19:04:31

ah, I see now. and yes, ::merge/not-found tries to get rendered

Jakub Holý (HolyJak)08:05:34

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)?

nivekuil08:05:31

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.

nivekuil08:05:24

not sure what you mean by "only" influences the client db data. is there a larger scope you're thinking of?

dvingo14:05:05

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.

Jakub Holý (HolyJak)18:05:23

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?

nivekuil06:05:02

holyjak, the difference is between pathom's return value (nil) and the value I recieve in pre-merge/client db/props (which are all the same, ::merge/not-found)

nivekuil06:05:25

didn't know about :global-eql-transform, thanks