A named ReactiveDict should have an API to tear down the migrated data

[rclai]

Migrated from: meteor/meteor#4585

[zimme]

I'm thinking .destroy() which would call .clear() and unregister the dict from migration.

To avoid having to remove the migrated data on destroy() we could just update _loadMigratedDict() to clear it's reference to the data before it returns it.

I have preliminary version here https://github.com/zimme/meteor/tree/zimme/reactive-dict

[zimme]

I'm not sure about .destroy() as a name though, maybe clearMigrationData() and don't have it call clear()? Is there ever a need to "clear" the migration data without clearing the actual dict data? If there is, maybe it should be called unregister()?

[rclai]

To avoid having to remove the migrated data on destroy() we could just update _loadMigratedDict() to clear it's reference to the data before it returns it.

Honestly, I think it should just do that because it solves the re-instantiaion issue that I had.

[zimme]

@rclai, I don't believe it will because when you create a named ReactiveDict it registers itself with ReactiveDict._dictsToMigrate which is a list of dicts to migrate and this is what is checked whenever a new named ReactiveDict is created via _registerDictForMigrate.

The updated _loadMigratedDict function just removes the reference to the migrated data in ReactiveDict._migratedDictData and doesn't touch ReactiveDict._dictsToMigrate,
so the re-instantiated error should still happen, right?

[rclai]

Oh my mistake didn't realize they were two different properties.

[zimme]

@hwillson, this can be closed as meteor/meteor#9063 is merged.

[hwillson]

Excellent - thanks for the reminder @zimme (and the PR)!