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

Think through what should happen if all fragments in a visit already match the new URL #80

Closed
4 tasks done
hirasso opened this issue Jun 2, 2024 · 6 comments
Closed
4 tasks done

Comments

@hirasso
Copy link
Member

hirasso commented Jun 2, 2024

Describe the problem 🧐

If all fragments in a visit already match visit.to.url, currently the matching fragment visit will simply be ignored, falling back to swups default containers for that visit.

That is not what would be expected. That kind of situation is basically like a link to the current page, even though the visit.from.url is not equal to visit.to.url.

Describe the propsed solution 😎

I've done a bit of research in #79 and then decided to first start with an issue.

I'm unsure about the ideal solution for the scenario described above. Maybe the behavior could be aligned with whatever is defined in swup.options.linkToSelf:

  • if linkToSelf is scroll, nothing should happen (matching fragment visit, empty containers)
  • if linkToSelf is set to navigate, the fragments should be reloaded (matching fragment visit with the containers of the matched rule)

As mentioned above, I'm not absolutely sure about the perfect solution here. Happy to talk it all through together.

Alternatives considered 🤔

Add a hook and always remove the fragment URL from the fragment element:

/** allow details to always be replaced */
swup.hooks.on("visit:end", () => {
  const detail = $<FragmentElement>("#detail")!;
  detail.__swupFragment!.url = "";
});

How important is this feature to you? 🧭

Would make my life a lot easier

Checked all these? 📚

@daun
Copy link
Member

daun commented Nov 25, 2024

@hirasso Did the changes in #79 resolve this? Or is it still a thing?

@hirasso
Copy link
Member Author

hirasso commented Nov 25, 2024

Yes, this was resolved. Take a look at https://filter-munich.com/calendar/ and click one of the items on the left multiple times. It will reload the fragment on the right, as that fragment already matches the current URL.

CleanShot.2024-11-25.at.12.19.50-small.mp4

@daun
Copy link
Member

daun commented Nov 25, 2024

@hirasso Nice. How does it know to only reload the right-hand fragment, and not all of them?

@hirasso
Copy link
Member Author

hirasso commented Nov 25, 2024

That's because the /event/:slug route only targets the container on the right.

@daun
Copy link
Member

daun commented Nov 25, 2024

Ah, true!

@hirasso hirasso closed this as completed Nov 25, 2024
@hirasso
Copy link
Member Author

hirasso commented Nov 25, 2024

Thanks for reminding me to close this as completed :)

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

No branches or pull requests

2 participants