Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix: fallback frame when navigating#948

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
rigor789 merged 4 commits intomasterfromfix/frame-fallback
Mar 8, 2022
Merged

Conversation

rigor789
Copy link
Member

This handles a case where a frame with a different id might have overridden the previous frame with the same id, but has been unmounted.

/cc@farfromrefug

@farfromrefug
Copy link
Contributor

i am not sure i understand. if no options.frame is passed and there is no more frame with iddefault in n-vue frame cache (because there are actually 2 frames with iddefault and one was removed) then there is no fallback toFrame.topmost()?

@rigor789
Copy link
MemberAuthor

getFrame(id) returns a frame from the frameMap - which is set/unset in the<Frame> componentmounted/destroyed callbacks.

So when we destroy the 2nddefault frame it's unset from theMap - but then$navigateTo is called, and by default theframe option is set todefault, so it ends up usingFrame.getFrameById('default') which returns the remainingFrame<default> that we pass as a fallback togetFrame(id, fallback) -> which then adds it back to the frameMap and returns it's vue VM instance... Essentially restoring it's entry to the frameMap.

It's a bit weird how we handle this, and the reason we even have the frameMap is because core will only return the frame fromgetFrameById if it has been navigated at least once... Perhaps it would make sense to patch that in core at some point and then refactor this whole setup to not rely on the frameMap.

@farfromrefug
Copy link
Contributor

@rigor789 thanks for the explanation. I get it now! seems good to me

@rigor789rigor789 merged commit6bad6c8 intomasterMar 8, 2022
@rigor789rigor789 deleted the fix/frame-fallback branchMarch 8, 2022 14:47
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@rigor789@farfromrefug

[8]ページ先頭

©2009-2025 Movatter.jp