Fork me on GitHub

@tony.kay In cases where parent component needs data from the child & to update data from the child. Ex: A group selector and the parent needs to reset selected groups & display the selected count. What would be the recommended approach in fulcro ?


- is it ok for parent to use the props that it sends to the child in it's render ? (with the this of the parent so that if the child data changes parent will see the data) - is it ok for parent mutations to know about the child's data location in the app-db (update it directly & use it in mutations) ?


@claudiu So, when the parent’s view is affected by interaction with a child, then the transact calls should happen in the parent (since you want the parent to refresh), but they should still be abstract mutations, and they should be triggered from callbacks from the child. It is fine for an immediate parent to look at the props of a child. The parent has to know about the child or it can’t compose it in, so there is nothing you’re breaking by doing that. We don’t hide information in clj 🙂 The main thing is that your mutations should be written with respect to the thing that they make sense for. This is a design criteria, not a requirement of Fulcro…you just want to keep your reasoning model simple. The only thing that Fulcro cares about is that the component in question has some kind of query (because that affects the ability to refresh). Where you run the transact! will be the root of your refresh


Of course, follow-on reads augment that


(technically if the component does not have a query, the transact walks up the component tree until it finds root or a component with a query)


As far as the parent knowing the child’s location. you’d probably prefer to isolate yourself from that in the parent by using mutations. It’s ok for you to know facts about the child (like it’s ID). Technically you could pull the ident of a child (call ident and pass in the props), and that is perfectly safe even under refactoring: (ident ChildClass child-props). But you should not be meddling with state in the UI, so again, mutations 🙂


@tony.kay Thank you. Yep will see how it goes once I start refactoring the app a bit, trying to keep things flexible but without adding extra layers 🙂


Hello. I wonder if this is correct or if I need to correct my mental model about how Fulcro works:


@rastandy I'm using it the same way. Can't remember exactly if I do [[:table/by-id 0]] or just [:table/by-id 0] 🙂


@claudiu the problem is that It seems that it’s not working


I think [[:table/by-id 0]] would be the way, going by the rule that you can put an ident in a query anywhere a keyword might go.


agh fair point. Need to experiment a bit more with that one 🙂


what part is not working ? 🙂


I tried this on the interactive Fulcro Development guide:


the problem with that is that with this query, I’m puzzled about how to extract the props from the component


for example, this query:


[{[:panelA 1] {:panelC [:sticky], :panelA [:boo], :panelB [:goo]}}]


return this:


{[:panelA 1] {:boo 42}}


how should I destructure that when getting props from the component?


(let [{foo [:a 1]} {[:a 1] :foo}] foo)


@sundarj wow, thanks, I should exercise on destructuring then


of course, you always have the option of doing (let [foo (get props some-key)] ,,,) too


thank you guys. For sure, another superpower of Fulcro is it’s reactive and friendly community


@tony.kay did you ever try to use :npm-deps with victory charts?


f/form-field allows :maxlength option (rather than :maxLength), which causes a warning: Unknown DOM property maxlength. Did you mean maxLength?


fulcro.server/serialize-exception takes a single argument ex and starts off with {:pre [(instance? Exception ex)]}. It is not rare for it to be called where ex is not an Exception. In these cases the problem is hidden from the user. Should I file an issue? I've changed the code for myself so that if it is not an instance of an Exception it does (throw ex).