-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
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
fix #9571, rendering async components after initial context was destroyed #9572
Conversation
} | ||
|
||
if (owner) owner.$on('hook:destroyed', () => removeOwner(owner)) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This stuff isn't mandatory. It doesn't break anything if destroyed owners are force updated. But it might be cleaner to remove them.
// already pending | ||
factory.owners.push(owner) | ||
} else { | ||
if (!isDef(factory.owners)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not too happy with double checking for isDef(factory.owners)
here and above but cleaner than moving this block above the block which returns the loadingComp
I guess?!
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
dev
branch for v2.x (or to a previous version branch), not themaster
branchfix #xxx[,#xxx]
, where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information:
I have not heavily tested this in a lot of circumstances. The async part of it almost broke my brain ^^ But tests are passing, so... ¯_(ツ)_/¯