-
Notifications
You must be signed in to change notification settings - Fork 73
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
Add construct_router function #447
base: main
Are you sure you want to change the base?
Conversation
@@ -66,7 +66,7 @@ where | |||
|
|||
/// Modify the router with a mutable closure. This is where one may apply middleware or other | |||
/// layers to the Router. | |||
pub fn mutate_router(mut self, mut alter: impl FnMut(Router) -> Router) -> Self { | |||
pub fn mutate_router(mut self, alter: impl FnOnce(Router) -> Router) -> Self { |
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.
How is FnOnce
less restrictive than FnMut
? Not understanding, honestly.
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 allows you to use closures that can only be called once, such as ones that take ownership, which won't satisfy FnMut
. FnMut
by definition must satisfy FnOnce
, so this does allow more closures/functions.
/// <div class="warning"> | ||
/// You must call `into_make_service_with_connect_info::<SocketAddr>()` before serving this | ||
/// router for matchbox to work | ||
/// </div> |
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 is a little concerning. It seems too easy to get wrong. Perhaps a flyway pattern could help us?
However, I'd rather pass the 2 routes ("/"
and "/:path"
) as arguments to build
or have some build_with(Router)
method alternative.
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.
Flyway pattern?
Yeah I was hoping that there was some way of passing across the service that ensured this but couldn't find a way.
A build_with
alternative sounds like a good idea though, I think it's best to have something more flexible than just passing routes.
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've implemented a build_with
alternative, and added a test for how it can be used too.
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'll try testing this soon. Thanks!
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.
Bump for a review when you get a chance
b26824f
to
2b783af
Compare
This allows you to modify the final router while ensuring that the connect info is still available to the signaling server.
2b783af
to
18357c7
Compare
I've rebased this, @simbleau could you take a look? |
If you want to use a single server and have matchbox signalling at a specific route it's useful to be able to get the router directly and work with that. You can't use
mutate_router
as that occurs before the final router construction and you'll likely end up with conflicting routes. I don't think you can expose a constructedIntoMakeServiceWithConnectInfo
as that can't be merged/nested into another router, it just has to be called at the root level before use.Open to other suggestions to how to do this, but this seems like the most straight forward and flexible way to do it.
I also loosened the traits for
mutate_router
which I didn't end up needing, but it is more restrictive than necessary.