Repurpose `store.data` to return something meaningful

[chuckn0rris]

Forum post

See comment below by @isglass on what it should actually do.

• [x] #5499
• [x] Change it to return current state as raw objects in 6.0.0

[chuckn0rris]

Still reproducible https://www.bryntum.com/forum/viewtopic.php?p=112630#p112630

[dvakatsiienko]

Confirming, still happens for very basic EventStore with about ~16 events of data. It needs to be fixed since EventStore.data access is a very basic and much required operation of data access.

[isglass]

store.data returns the original array of data object that the store was loaded with. There was a path where it was not previously set, which should be fixed already IIRC (not released)

But, the actual original array of data objects is not updated by the store on record manipulation, so its existence is questionable and very likely not what you want to use anyway.

You should probably be using store.toJSON() or store.records.map(r => r.xxx), where xxx could be for example data or modificationData.

I will change this ticket to be about repurposing what get store.data means, but that will be a breaking change so can't happen before 6.0.

[ExtAnimal]

The presence of the data property should have been fixed by this: https://github.com/bryntum/bryntum-suite/pull/6037/files#diff-e9384412668e5d54825dbe66e48f36c9d59a621e92ba967597705ad6e1f72b45R1546

The raw data element of the incoming data array is used as the data property of the record.

So the raw data block should work to mutate and feed back through if you are using syncDataOnLoad

[dvakatsiienko]

@isglass so if you load data 10 data entires into EventStore, and let's say delete one of the records with EventStore.remove(record), the EventStore.data will return 10 records (the initial ones), and the EventStore.records will return 9 records (which are actual ones). Correct?

[dvakatsiienko]

When Bryntum v6 is planned to be released?

[matsbryntse]

Early 2024! (Sorry for the late reply)