Fork me on GitHub
#om
<
2016-07-15
>
anmonteiro12:07:49

@dnolen: The PR for #637 also has a commit for #604 as I mentioned yesterday

anmonteiro12:07:06

let me know if you want me to squash those commits, I purposely made them separate for your review

tmulvaney17:07:28

I have a root component which renders a list and each item in the list is clickable. On clicking an item i want the list to update, so i pass a mutation function to each item which closes over the root component, something like: (map (fn [props] (ui-item #(om/computed props {:on-click #(om/transact! this ‘[(stuff …)])}))) props-list). This works as intended. But, all the children re-render even if they don’t need to, because fresh on-click functions are being created and passed to each ui-item component. Is there a better way of doing this, without digging into shouldComponentUpdate?

tmulvaney17:07:27

One thing I tried which does work is adding a mutation method on the parent instance and then passing the parent component to the child via om/computed. The child can then call the method bound to the parent but this seems a bit an odd way to do things as the child needs to know the name of the method on the parent.

danburton18:07:09

When I've got a mutate action that nukes the whole app state... what do I put for :values {:keys [???]}? If I call the transaction on the reconciler, it should just update everything appropriately if I leave this part off, right?

danburton18:07:46

> all the children re-render even if they don’t need to, because fresh on-click functions are being created and passed to each ui-item component. It might re-run the render function for all of them, but doesn't react handle this correctly by only updating the parts of the dom that actually changed? (In this case, just the on-click fields). Is this re-render really all that bad?

danburton18:07:07

I thought the whole idea of react and om was that it's ok to run pure functions superfluously because they're fast.

tmulvaney18:07:09

@danburton: if you call the transaction on the root component the root will re-query. The keys vector you mention is just for documenting the mutation. You would normally list the keys after the mutation functions in the transaction

tmulvaney18:07:57

Unless the keys are on the requesting component in which case they will automatically update

danburton18:07:14

> You would normally list the keys after the mutation functions in the transaction I've always found this very odd. Shouldn't the one who calls a mutation be decoupled from knowing which keys it mutates?

tmulvaney18:07:40

I think the idea is that you may be developing different UIs but want to use same mutations, so as the UI developer you make the calls as to what updates in the UI you are developing

danburton19:07:07

Is this an abomination? (defmethod read :reconciler [{:keys [reconciler]} _ _] {:value reconciler}) Or (worse?) this? (defmethod read :env [env _ _] {:value env})

danburton19:07:24

Oh the reconciler isn't on there. Thought it was.

a.espolov21:07:06

Guys, I understand that om working with the backend via reconciler only supports optimistic update?