Model attrs not accessible after destroying about data

[runspired]

broad strokes this is expected. As we shift more and more away from classic computeds some of the less-well spec'd classic computed behaviors may silently vanish, and computeds retaining state and never recalculating once their owner object is destroyed is a pretty unique quirk (and also dangerous, as it often lead to memory leaks).

If you use a more manual control flow though you will be able to do this.

destroyRecord is a "macro" that does 3 things

• synchronously tells the record it is deleted (record.deleteRecord() or store.deleteRecord(record)
• synchronously initiates a save of the record (record.save() or store.saveRecord(record)
• awaits the save promise and then unloads the record (record.unloadRecord() or store.unloadRecord(record)

Note: unloading a record physically destroys the instance of that record that you have access to in the UI, running all of its teardown lifecycle hooks. It also clears the data for it from the backing cache.

The attributes and relationships will only be cleared once the unloadRecord bit occur, because the record then is severed from the cache, and the cache is cleared.

However, based on what you posted in discord there is another bit here to also be aware of. If a record is in the new state (e.g. record.isNew === true) which is true when a record has been created on the client and never persisted via a save, then calling rollbackAttributes or deleteRecord will immediately also unload the record. Not saying this behavior is great, but this has been a codified behavior since the earliest days of EmberData and I suspect it was done mostly to prevent memory leaks since too often folks wouldn't remember to fully clean up new records when bailing out on the create flow in their ux.

That means that if your form or what not may be displaying attributes for a new record, then you will want to perform a check of isNew and adjust teardown logic appropriately if you need to display information off of the record for a bit of time.

Can anything be done to preserve access post-destroy?

Yes, actually. More recent versions of EmberData allow access to the full set of resource data available in the cache as one blob, and record instances are pluggable via the instantiateRecord hook. A class could be written that when torn down saves some of its resource state onto itself in case it continues to be accessed but divorces itself from the cache. In a destroyed state it would need to have any property accesses proxy to the local copy instead of to the cache.

[amk221]

Thanks, I as a long time user, I'm aware of the isNew/rollbackAttributes quirk.

In terms of this issue though, I fully appreciate that if I've deleted a model, I can't expect to be able to access its attributes after the fact. That makes sense. And I understand how an old-school computed property could have accidently cached that state.

But what's frustraiting is:
a) as far as I can tell nobody mentioned this was going to change and suddenly break things
b) that it still feels broken - in sense that it's possbile to write code that works by accident (see my repo)
c) that the js behaves differently to hbs!

It's possible we (and other apps that use ED) have loads of places in the codebase that 'just so happen' to access a property before a deletion. And therefore, loads of places which are liable to just stop working whenever Ember Data decides to tighten down on these "less well speced" areas.

Should I assume that once delete/destroy record is called, that I should never be accessing a model's attributes? Shouldn't it just throw? If it's just a footgun? Why make it half work?

Anyway, I don't want to rant bceause I know how hard it is to update a library under the hood whilst reducing breaking changes.

In terms of getting from v3 on to v4 and fixing the failing test in the above repo (with least effort) is the simplest thing to capture the attributes I want to use in the UI before doing the deletion? It seems so...

[runspired]

Should I assume that once delete/destroy record is called, that I should never be accessing a model's attributes? Shouldn't it just throw? If it's just a footgun? Why make it half work?

delete is safe, destroy is not. Once the instance has been destroyed you should not assume accessing is safe. This honestly should have always been self-evident but the nature of Ember's object model and classic computeds has hidden this and you probably are right that yours isn't the only app that is using this without giving it proper consideration.

Unfortunately, attr/belongsTo/hasMany are still computeds because until we cut support for classic syntax they have to be, which is why if you've previously accessed you might be able to get away with re-access unexpectedly.

Note there is something else going on that allows the template to not recompute that EmberData has nothing to do with: templates have their own memoization.

In terms of getting from v3 on to v4 and fixing the failing test in the above repo (with least effort) is the simplest thing to capture the attributes I want to use in the UI before doing the deletion? It seems so...

This can work, or doing the unload only after you've shown what you want to show.

[amk221]

Thank you