If it is truly global, then that is a reasonable thing to do. You can also add it to the shared data.

https://book.fulcrologic.com/#SharedState

Read carefully. Shared is best for things that change rarely. They don’t have the same UI update guarantees as link queries. In general I use link queries.

Unfortunately this is a bug in Inspect I introduced when I optimized it to be faster some time ago. I have not had time to fix it.

Normalization is not broken, so you can stop barking up that tree. You should look at: What query did you send (network tab) and what response did you receive. If they match up then things will work.

When I load a picker option it deletes po/query-key from the DB.

i.e. load works. I’d know if it didn’t because i use Fulcro in 300k lines of production apps 😄

picker options are normalized…there may be some additional login in RAD picker support (don’t remember) that is removing the key from the db

RAD uses pickers by loading the entire table via a link query. It never uses the load key

I have ::all-categories loaded, the picker uses same load to load them into options cache, but it deletes the ::all-categories value at the root of DB for some reason

the load works as expected

by that I mean I get the expected value from backend

if the load “targets” them, then load removes the root key after the relocation

that would explain that

pickers DO target their results

see picker-options/load-picker-options!

The link query that RAD uses for picker options is

[::picker-options/options-cache '_]

kinda unfortunate that nukes the value already in place

The fact that it puts it in root at all (when targeting is present) is a legacy thing

if you actually want it in root, you can always include that as one of the targets, but the general idea is that top-level keys should not pollute the root unless it is intended.

so I should load target ::all-categories into all 3 components that need it?

are you using picker options?

probably best, as I stop using link queries

in one part yes

so, you could manually write that load so that you don’t target

up to you and which is less complex for your use-case

Yeah I have to think about that

I don’t know what you mean by manually writing that load though. Picker does its own load that I cannot affect target-wise as seen in docs:

* `load-options` - Additional options you wish to pass to the load (optional). Only used if the cache was missing or
   stale for the options. Currently you cannot use `:target`, `:params`, or `:post-action`. `::picker-options/remote` can
   be used to select the load remote.

I mean read the source of that, and just do what it does…it just issues a load

I guess if you’re relying on RAD to do the load, then that doesn’t work…you could pull the entire table like RAD reports do

(link query I mentioned earlier)

yes and it does have a non-trivial post-action

or if you’re in the body of a report, you already have that

Thanks I’ll mull this over