Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Destroyables #580

Open
wants to merge 12 commits into
base: master
from
Open

Destroyables #580

wants to merge 12 commits into from

Conversation

@pzuraq
Copy link
Contributor

pzuraq commented Jan 11, 2020

Rendered

pzuraq added 2 commits Jan 10, 2020
text/0580-destroyables.md Outdated Show resolved Hide resolved
Copy link
Member

rwjblue left a comment

This is really great, thank you for working on it!

I think we may need a couple additional things to allow for introspection:

  • isDestroying(obj)
  • isDestroyed(obj)

IMHO, these are somewhat important so that we can "mark" all of the graph that will be destroyed before calling all of the registered destructors and that the object itself can determine if it is in a destroying state or not before doing any work.

text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
@rwjblue

This comment has been minimized.

Copy link
Member

rwjblue commented Jan 13, 2020

@pzuraq - Another feature that ember-lifeline has, that is pretty nice (and we would either have to drop there or not be able to migrate to this builtin API) is that we can assert that all destroyables that were ever registered have been ran. This is used in testing infrastructure (see the documentation here) to ensure that folks don't accidentally forget to properly destroy(obj) something that they should have (the assumption here is that at the end of the test, all destroyables that were created during the test are ran).

@jessica-jordan jessica-jordan mentioned this pull request Jan 15, 2020
10 of 28 tasks complete
@amyrlam amyrlam mentioned this pull request Jan 17, 2020
8 of 25 tasks complete
@amyrlam amyrlam mentioned this pull request Jan 24, 2020
6 of 27 tasks complete
Co-Authored-By: Robert Jackson <me@rwjblue.com>
@pzuraq pzuraq force-pushed the destroyables branch from 35b84e2 to 038f188 Feb 28, 2020
text/0580-destroyables.md Outdated Show resolved Hide resolved
@pzuraq pzuraq force-pushed the destroyables branch from 038f188 to 09e3bef Feb 28, 2020
Copy link
Member

rwjblue left a comment

Thanks for the updates here @pzuraq, looks like great progress!

text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Show resolved Hide resolved
pzuraq added 2 commits Feb 28, 2020

- Calling `destroy` on a non-destroyable should throw an error.
1. Mark the destroyable such that `isDestroying(destroyable)` returns `true`

This comment has been minimized.

Copy link
@rwjblue

rwjblue Mar 4, 2020

Member

Does it also mark each of the children?

This comment has been minimized.

Copy link
@pzuraq

pzuraq Mar 4, 2020

Author Contributor

It does while calling destroy() on the children, since it recurses. It does not mark them as destroying before running its own destructors.

text/0580-destroyables.md Outdated Show resolved Hide resolved
pzuraq and others added 4 commits Mar 4, 2020
Co-Authored-By: Robert Jackson <me@rwjblue.com>
text/0580-destroyables.md Outdated Show resolved Hide resolved
text/0580-destroyables.md Outdated Show resolved Hide resolved
pzuraq and others added 2 commits Mar 4, 2020
Co-Authored-By: Robert Jackson <me@rwjblue.com>
Co-Authored-By: Robert Jackson <me@rwjblue.com>

## Unresolved questions

- Should `willDestroy` and `didDestroy` (e.g. mark-and-sweep style semantics) be

This comment has been minimized.

Copy link
@MichalBryxi

MichalBryxi Mar 15, 2020

Just throwing a thought: Will this be a footgun? Seems like first thing I would try if willDestroy get deprecated and codemods are not working for me (for whatever reason):

registerDestructor(this, this.willDestroy);

This comment has been minimized.

Copy link
@pzuraq

pzuraq Mar 16, 2020

Author Contributor

This specifically was referencing synchronous willDestroy semantics, which are a footgun for performance, but are necessary for things like running code before a component is removed from the DOM (e.g. willDestroyElement). Generally, you should do the minimal amount of work synchronously, and schedule the rest, but often this doesn't happen. I'll reword this to make that more clear.

This comment has been minimized.

Copy link
@pzuraq

pzuraq Mar 16, 2020

Author Contributor

FWIW, the current semantics would be exactly the same as willDestroy is currently.

Copy link
Contributor

MelSumner left a comment

Please update for better MVP guides content.

Any future classes that are added and have a container managed lifecycle should
also be marked as destroyables.

## How we teach this

This comment has been minimized.

Copy link
@MelSumner

MelSumner Mar 20, 2020

Contributor

We've said previously that we don't want this section to say how we should theoretically teach this, but rather be an MVP of documentation for the guides. I would ask that this section be updated accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.