Fork me on GitHub

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

Thomas Moerman14:07:58

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

Thomas Moerman14:07:20

(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

Thomas Moerman14:07:01

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 🙂

👍 4
Thomas Moerman15:07:56

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

Thomas Moerman15:07:40

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

Thomas Moerman15:07:24

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

Thomas Moerman15:07:57

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


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


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.

☝️ 4

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

👍 4

Yeah, any help clarifying easily misunderstood topics is greatly appreciated