Handle entity update with sparse attributes #1392
Conversation
| const attributesOld = oldRes.attributes || {}; | ||
| const attributesNew = newRes.attributes || {}; | ||
| // Allow (potentially) sparse attributes to update only relevant fields | ||
| const attrs = attributes ? { attributes: { ...attributesOld, ...attributesNew } } : null; |
There was a problem hiding this comment.
I think this is fine. We really should always use the latest attributes we have already fetched.
This will result in part of the data being stale, while part being updated. Before we showed only fully stale or fully updated data. But I think this is perfectly ok. If the sparse updates don't make sense, e.g. in cases where extended data is synced along with other attributes, then more sparse attributes can always be added where the update happens, right?
There was a problem hiding this comment.
@kpuputti Yes. Mainly, I was thinking about the reduction of data. E.g. if a listing has 50kb worth of publicData that somehow cumulates in the long-living app. But I guess that's an edge-case scenario that needs to be addressed case-by-case in customizations. (and full page-refreshes do happen every now and then)
Gnito
force-pushed
the
handle-sparse-attributes-in-data-update
branch
from
47b46c7
to
4f9cf2d
Compare
Gnito
force-pushed
the
handle-sparse-attributes-in-data-update
branch
from
4f9cf2d
to
ef4366c
Compare
I think we have forgotten to think about this merging setup when sparse attributes were added to templates.
However, I'm not entirely sure if we should make this update or not. Is there any reasonable customization concept that relies on "reduction" of marketplace data in the store?
(This PR was motivated by a recent question in Slack.)