ok it was only the case when running queries within pathom viz

If I'm not doing something wrong and it's expected that not-found propagates to the UI if I don't do anything, I can: • Call nillify-not-found from my components every time access the value. (YUCK) • Be diligent on the server to never return nil. (mostly works, but this really isn't the data I want to be sending) • Do something in pre-merge for every load event I'm concerned about. I'm also not clear, based on the examples, what the "correct" behavior is. I can write things that look like they are doing what I want, but I'm not entirely clear. Is there a clear example of what to do? None of the examples in the book seem like what I want.

you do not want nil in app state if you can avoid it. Not founds are retracted, not set to nil

where are you seeing not-found values? pre-merge? They are supposed to be there, because you might find them useful.

but they should not be in the client db

Yes, I see ::merge/not-found in the data that gets to pre-merge

Fulcro is very pluggable…so, first question would be if you’re doing anything non-stock

as in setting the transactioin handler, adding in middleware in places, etc.

but yes, it is supposed to be visible in pre-merge. The sweep-merge happens after pre-merge

they are there so that a merge of various layers in pre-merge will work “right” semantically

I'm not doing any special configuration that I can see in initializing the app that would add any extra middleware or do anything unusual

So, confirm that you are seeing the not-found values in the client db after load is done, and you look at db in Inspect

This is an odd corner case, and in practice you should never return nils in maps from EQL requests. nil is not considered a legal value from a data perspective in Fulcro (the absence of the key is the proper way to indicate no value for a key). You can easily put a plugin on pathom that will dissoc keys w/nil values. That said, I would consider it a bug if a nil is returned and the not-found marker ends up in app state

and to confirm it is sending nil... I do have elide-special-outputs-plugin on the server side

What is your component query?

I just tried it on my app here, and it is NOT in app state

even though I returned nil

:query [{:project-parent/proposal
            [:proposal/design-name
             :proposal/estimate
             :proposal/faqs
             :proposal/team-members
             :proposal/timeline
             :proposal/what-we-heard]}]

very straight forward

that is not a proper query

the nested bit has no component, and therefore no normalization info

it’s legal EQL

And then I load as

(df/load! app
                  project-ident
                  ProposalData)

hm.

Where project-ident is entity in question I'm querying

so, this is technically a bug in Fulcro

The internals assume you’re always going to do joins on components that themselves have queries.

the fact that you are not normalizing the nested item is what is confusing it I think

Ah - so if I were put this on the parent entity and used :focus (or whatever the keyword is to target only some sub-query) for example, then fulcro would be happy

I’m not sure why it is breaking on that…I’m looking at the internal logic and I don’t see a problem

So, forget focus or without for a moment

if it was a flat query then it would work. Also, it would work if you had:

:query [{:project-parent/proposal (comp/get-query Proposal)}]

which is what you want 99.99% of the time

Write a second “kind* of proposal component to avoid self-reference

(defsc ProposalA {:ident :proposal/id …}) (defsc ProposalB {:ident :proposal/id …})

Hmm - this data doesn't have an ident, though I suppose I could borrow the id of the parent object....

unless you need true recursion, in which case

(defsc Proposal [this props]
 {:query [:proposal/id {:proposal/parent ...}]
  :ident :proposal/id}
...)

or you can flatten the query

or you can try to find the bug with non-normalized mark/sweep merge. 😄

hehehehe

If you want to make a very minimal repro project and send it along, I’ll have a look at it sometime

Ok - I'll see about trying to hack on some kind of id here for now. And yeah, it should be easy to come up with a reproduction