i have a small ember (2.7.0) project where i use ember-models-table
(1.8.0) to setup a small table. table contents come from route’s model, a
simple findAll. table ‘rows’ are created/updated/deleted in that
route’s controller, using createRecord+save (create), destroyRecord (delete)
and findRecord+then+set+save (update). the problem is, when i create a
‘row’, the table immediately shows the new row, but when i delete it, it
does nothing and when i update it, it shows both a row with the old
values and a row with the new values. but everything is fixed if i
refresh the page.
searched for some explanation of this mechanism but didn’t find any.
i’m having some problems answering both 'who is responsible for this
behaviour? and ‘what’s the best practice in this case’? didn’t manage to find a way
of refreshing route’s model in the controller or the table itself via
ember-models-table.
Your findAll("model") populates the store - the store is simply an in-memory representation of that data; ember-models-table displays what’s in the store. When you createRecord() a new record, it will be added to the store (even if not yet actually saved on your backend) and as such it will show in ember-models-table as well.
You can work around the new unsaved records showing immediately by creating a computed property:
You then use savedRecords rather than your model as the data for ember-models-table, and it’ll only show these actually saved records. You can combine that with the isDeleted flag as well if you need to.
A useful tool is ember-changeset, this allows you to validate the changes before they’re committed to the store. If you don’t use an add-on like this, your table will also immediately reflect any changes made in your form.
thank you so much for taking some time to answer my doubts.
your explanation makes perfect sense but after reading the official documentation about creating, updating and deleting records a couple of times i didn’t get that info.
on both cases (update and delete) i have do ‘find’ the object i want to modify. in this find operation you have to include the backgroundReload = false option and everything works as expected.
The backgroundReload option is used to prevent the fetching of the destroyed record, since findRecord() automatically schedules a fetch of the record from the adapter.