I'm about to start a project at work, a decently large web app. I should learn and use fulcro2 at the moment then?

Q: is it possible to prune in a mutation join?

(remote [{:keys [ast state ref] :as env}]
    (-> ast
        (m/with-params {:report-id  report-id ;; use these server parameters, as we cannot use namespaced keywords in Python
                        :isotope-id isotope-id})
        (m/returning state IonImageConfig)  ;; <<< This component fetches too much

So in other words: I'm looking for an alternative for :without #{bla.bla/children} like in df/load

@jaihindhreddy Fulcro 3 is working, but not stable. If you’re willing to tolerate a bit of that, then you might start a new project with it, knowing you’ll probably see some issues. If you’re using it at work, you might consider asking your work to fund some of the F3 work, and it’ll get done faster 🙂

above message: nevermind. I appeared to be yak shaving into the abyss ...

root cause of the problem I was actually trying to solve (render speed) was a couple of solar systems off, solved now

@tony.kay Perhaps a suggestion for a side-note in the manual: when passing computed callback functions to Items in a large list, if the parent component that creates the callback is re-rendered, all the children will also be re-rendered because the fn is now a different one. (If I understand correctly, of course).

Quite logical of course, but a pitfall for noobs like me perhaps.

that is true, changing the callback changes the props ultimately. I think I mention that somewhere in the guide, but it is something worth mentioning, along with the fix (throw the function into the component-local state or put it on this at mount)

added a note to myself in optimization section of book

Hi! Is there any condition where an attribute that I’m trying to override using pre-merge would be overriden in the first call to pre-merge but not in subsequent calls?

And by the way, I’m not trying to do what I described, I’m trying to understand why it is happening in some of our components

F2 or 3 @f.o.thome

actually the code is the same 😛

all I can think of is merge order in your pre-merge logic

Oh, and the fact that each component gets a chance to mess with the data at each layer….that is to say a parent can affect a child, but then the child pre-merge could override that effect

Yes, that is the problem for what I see. Do you think it makes sense this line https://github.com/fulcrologic/fulcro/blob/2831bd57733cd74a65a93a0134b196af1876f2d4/src/main/fulcro/client/primitives.cljc#L1624 be somthing like (select-keys (get-in state (get-ident class data)) (get-query class))

The problem is current-normalized comes with the pre-merge attributes of children components

http://book.fulcrologic.com/#_working_with_pre_merge

I talked with @wilkerlucio at length about this…I’m not a huge fan of the inconsistency between having normalized and non-normalized data; however, it is well-documented what you receive, and up to you to implement the correct logic if you manipulate the pre-merge data. The data tree is actually what is being merged, and there are good uses-cases for being able to see it unmodified (e.g. you might be reorganizing that data tree via pre-merge)

The fact that you have the state map and “real query used for obtaining the tree” means you can use db->tree to get a denormalized view from the db…so all options are open to you

But do you think other components should see attributes they didn’t asked for in the query in the current-normalized param? I think you should look for these attributes in the state param

I think the answer is: some ppl with want it one way, some the other…I don’t see a reason to take the overhead for everyone.

db->tree isn’t free, and that’s what you’d really need to run to process the queyr, not select-keys

and it would often not be the query from the class…it’d be the query in the params passed to pre-merge

lots of possible alternatives that are perfectly valid

the default is the “least overhead” providing everything needed

I understand, but maybe this could be better explained in the docs. It took me sometime to realize what was happening. The docs recommend to use (merge {} current-normalized data-tree) this way you will have pre-merge of components with same ident interfering with results of each other

feel free to send a PR, preferably against the new version of the docs for F3

Yeah, any help clarifying easily misunderstood topics is greatly appreciated