-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[chore] Router refactor #2655
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
[chore] Router refactor #2655
Conversation
|
trailing_slash, | ||
handle_nav: renderer.handle_navigation.bind(renderer) | ||
}); | ||
renderer.router = router; |
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.
Is it possible later on to resolve this somewhat cyclic dependency? I read this as "renderer depends on router, which depends on renderer"
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.
yeah, it's a good question. I'm not quite sure and don't have any ideas on how it would be done
the cycle isn't a new one. In master
, the router takes the render as a constructor arg and then did this inside the constructor. I just moved where it's occurring. I agree with you that I don't love it, but am not sure how to change it. I'd be all ears if you have suggestions
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.
I dug into this a bit and added a comment explaining options for cleaning it up. It'd be too big of a change to try to tackle in this PR, but might make a nice follow up if I get some time 😄
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.
I also think we can address the comment later if this provides a stepping stone to modularize the router.
I'm going to put this on ice temporarily. I've been working with the Routify folks to figure out how to make the routers swapable and I'm better figuring out through that process where it might be nice to draw some of the interface lines. This may still be a nice change, but possibly doesn't advance us towards making the routers swappable. I may reopen later, but right now want to dig into Routify more first because I think they've done a couple things that are pretty cool in terms of how they've structured things |
This makes two primary changes (which are on two separate commits):
Prefetcher
separate from theRouter
Router
andPrefetcher
use generic handling functions instead of depending on theRenderer
(though not yet that generic since we'd need to cleanup the APIs)This is a step towards making a separate
@sveltejs/router
project (#2611) by decoupling routing / rendering. The basic structure is now there though the interfaces would need to be cleaned up a fair amountIt's also possible this would be a step towards not pulling in prefetching code for people that aren't using it
No changeset since there are no user-visible changes