-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Factor out support for query_arg
binding from rest of router changes
#1892
Conversation
7addcf5
to
bee2700
Compare
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 left some comments. This looks good for the most part. I feel like some items deserve their own modules (like Route
) and there were things that were exposed which shouldn't have been. Also, please update the macro tests.
a87ddd7
to
89ca2d7
Compare
registration from getting the current context value.
3247acc
to
7c548d4
Compare
Tests are now passing. The only remaining issue is the naming of "munchers". |
Great, can you update the docs too? Those will need a good amount of updates. Also, I will try to do the second round of review as soon as I get some time (pretty busy with other stuff right now) |
👍 |
de24938
to
b0fee4b
Compare
Visit the preview URL for this PR (updated for commit 4d2e27c): https://yew-rs--pr1892-router-rewrite-parti-4iny57da.web.app (expires Wed, 23 Jun 2021 22:42:50 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
b0fee4b
to
f15a5cb
Compare
I've performed the renaming and updated the documentation. That should address everything you've brought up so far. |
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 feel like HistoryState
and RouterState
are too abstracted and complicated? Can we simplify those any more? Want me to give it a shot?
This review is incomplete. This is what jumped out to me when looking though the code.
They both implement the same rules, which are as follows:
These rules ensure the router does the minimum amount of work for any sequence of calls to its API (since the current value will always be cached as long as it is still valid) whilst minimizing the overhead of the router when it is not in use, and ensuring that it cleans up after itself gracefully. The difference between The code maps 1:1 onto that state machine: the constructor is used to "activate" the state. The If you can simplify the code whilst implementing the same state machine, and without breaking the 1:1 mapping between the code and the state machine it implements, then that would be worthwhile. |
130f22f
to
ff52954
Compare
I was thinking of simplifying it in a way that the router's state is stored inside the router, not globally. Is that something that can happen? Locally managed state is better than global state. |
The router API is global, so even if you were able to do that, you'd just be lying to users about where the state lives... Regardless, I think this should be global state, since it is state which is derived from |
ff52954
to
b49769a
Compare
b49769a
to
4d2e27c
Compare
I believe correct way of implementing this would be to to first contribute to Also I'm closing this PR as it is stale for a long time |
Description
This is #1860 minus the following features:
It is based on #1891
Checklist
cargo make pr-flow