-
Notifications
You must be signed in to change notification settings - Fork 156
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
support nested routes, and a base prop to start from if necessary #100
base: main
Are you sure you want to change the base?
Conversation
This is awesome @sskoopa! Only thought I had was maybe use |
I was just going on the fact that base is a calculated field, and props are supposed to be immutable in react-like codebases, no? We need to calculate it before setting the context in getChildContext(), as that method is not passed the context. |
Updated to use props.base, tests still pass |
Ack! Sorry, I hadn't meant to mutate class Router extends Component {
constructor(props, context) {
super(props);
let base = props.base || '';
if (props.history) {
customHistory = props.history;
}
if (context && context[CONTEXT_KEY]) {
base = context[CONTEXT_KEY] + base;
}
this.state = {
url: this.props.url || getCurrentUrl()
};
}
getChildContext() {
let base = this.props.base || '';
if (context && context[CONTEXT_KEY]) {
base = context[CONTEXT_KEY] + base;
}
return { [CONTEXT_KEY]: base };
}
} |
Once base is calculated, where do you store it to use in getMatchingChildren? |
Could just leave it as |
I'll work that direction then |
s/this.base/this.baseUrl works, of course this.base is already a preact variable :) |
Ahhh haha I completely missed that |
src/index.js
Outdated
|
||
this.state = { | ||
url: this.props.url || getCurrentUrl() | ||
}; | ||
} | ||
|
||
getChildContext() { | ||
return {CONTEXT_KEY: this.baseUrl}; |
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 needs to be [CONTEXT_KEY]
.
ok, I now:
Let me know if you think anything else should be there. |
super(props); | ||
this.baseUrl = this.props.base || ''; | ||
if (props.path) { |
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 wonder if we need to move this into the if
block on L156?
+1 |
this is high on my todo list, we're using workarounds right now and it's ugly. |
+1. Planning to switch our app to preact-router once nested routes are in. |
Yes - sorry for dropping this on the floor, we're super keen to get this merged too since our apps are using a workaround right now. |
@developit I updated the PR to remove conflicts, ready to merge |
Awesome, thanks a bunch! Hopefully we can merge this, right now we are hacking around it haha. |
I tried and failed to resolve conflicts, didn't want to botch it. |
@developit, I merged everything the way I think it should, but one of the tests I wrote for Match is failing:
I left the console.log of children in Match.render as the child is a vNode, and usually the Router did a cloneElement on match. Do we need cloneElement on Match.render()? If so, do we need more or other tests on Match itself? |
test/dom.js
Outdated
<Router base='/ccc'> | ||
<X path="/jjj" /> | ||
<Match path="/xxx/:bar*"> | ||
<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.
While the other nested router tests pass, the Match here cannot render the child as it is a vNode.
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.
hmmm. yeah we might need to do type detection in Match. I realize now we sortof have two matches, so it might be good to merge them. Need to think on this for sure, because I like the options your Match gives us.
OK, Match components are merged and tests pass. I think more people will use the simple Match, but the power is there. gzip size 2050 (2K+2). I could shorten the CONTEXT_KEY constant name :) |
This would be super-useful to avoid workarounds, anything missing for approval? |
Any update on this? My boss want to use sub directory according to this article https://fly.io/articles/one-hostname-to-rule-them-all/ |
Hi, anything I could help with this? Would be nice to have it. |
@sskoopa @developit Any news on this? Really don't want the extra size of React Router as this does everything I need. Thanks |
If anyone wants to take a stab at resolving the conflicts that'd help. We all want it merged :) |
When I go to review the PR i'm not seeing any conflicts, is there a certain view I should be looking at? I'm also very interested in adding the ability for nested routes, how can i help @developit? |
Hi quickly updated - #293 |
This would be so nice to see it merged. Big thumbs up to @sskoopa. |
@hbroer Agree the PR is really great and in my opinion there is not much standing in the way of a merge. The PR needs to be updated against the latest changes in master for Preact X, but that seems to be all that's left to do 🎉 |
What happened to this feature? I can't seam to find that it was solved and merged in another issue. Is this still being considered or have it been discarded? I would be happy to try and help solve the merge conflicts, but I'm not sure about the proper way to do it. Can I even update this PR? |
@Haugen it's still being considered, just hasn't been prioritized. There are so many great routers available that work with Preact, but the drawback is that it's hard to justify spending time on new features for FWIW, @38elements recently contributed a guide section in the README that covers how nested Routers work today (without the changes in this PR): https://github.com/preactjs/preact-router#nested-routers |
@developit what is missing for that to be merged? I could help investing time on it. I understand there are many routers that work with Preact, but since I'm working with preact for performance reasons, I would like to have this base prop to handle my requests on a subdir (it's not about the nested requests, it's about the base prop) |
No description provided.