adopted-ember-addons / adopted-ember-addons/ember-data-model-fragments

[QUESTION] [3.0.0-beta.1] Is the fragmentArray ordering important when saving and updating?

未關閉
#359 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
TypeScript
星號
367
分支
108
PR 合併指標
30 天內沒有已合併 PR

描述

Hi,

## Context

I don't have much experience using fragments.

* I have a `fragmentArray` and I am manipulating the objects, adding and removing them.
* These are the version of the related addons:

```json
"ember-data": "3.1.2",
"ember-data-model-fragments": "3.0.0-beta.1",
```

**Note:** As always, willing to upgrade

* The array is created in the `normalizeResponse` serializer of the owner.

## Problem

In a template I iterate the objects of the fragment, I manipulate the fragments using: `removeFragment` and `addFragment` to add and remove (which seems to be simple wrappers for `addObjects` and `removeObjects`).

I am even calling destroy in the removed objects using `.destroy()` after removing it from the fragment. But, even when doing that, the fragment array gets mess up after saving the parent model, even though the response is correct when it gets to the parent serializer and seems to be correct until the point when Ember data push it into the store.

## Work around that seems to work

If I sort the array by a unique object key when adding new objects and when I get it them serializer, everything seems to work ok. It seems like somehow, the array ordering is important to keep consistency when manipulated fragments inside the fragment array.

## Questions

* Is the ordering of a `fragmentArray` ordering to keep consistency?
* How do I remove fragments completely from the store?

Best regards,
Daniel.

貢獻指南

開啟貢獻指南

研究方向

Start by reproducing the fragmentArray changes made with removeFragment and addFragment, then trace the data through the owner's normalizeResponse serializer, the parent serializer, and the store during save. Compare ordering before and after persistence and check how removed objects are handled after destroy(); the issue does not define a confirmed expected behavior or a specific fix.

由索引模型根據 Issue 內容生成。

評估

技術堆疊
typescript
領域
frontend
Issue 類型
缺陷
難度
4/5
預估耗時
3-5 天
活躍度
停滯
描述清晰度
需要釐清
新手友好度
32/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。