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

initialPath / rootUrl option #111

Closed
ryanflorence opened this issue Jul 23, 2014 · 17 comments
Closed

initialPath / rootUrl option #111

ryanflorence opened this issue Jul 23, 2014 · 17 comments

Comments

@ryanflorence
Copy link
Member

I haven't tested this, but I'm pretty sure we can't handle an app starting at a deep url already.

For example, we're building a new feature that starts at /courses/123/files, hash urls will be fine, but as soon as we turn on location="history" it's probably not going to work.

I suspect we'll need <Route rootPath="/courses/123/files"/>

@ryanflorence
Copy link
Member Author

Actually, you might be able to just put that path as the path to the root route ...

... Nope, because paths don't get inherited.

Three options:

  • We can do the rootUrl option
  • We can do nothing, and require people to provide full paths to their routes/links
  • When Route is more extensible (Make Route more extensible #65), people could bake in the root url to their own Route and Link components.

@mjackson
Copy link
Member

I agree, we should have this. To stick with existing React convention, I'd like to call it initialPath. React does that in places where you can specify a prop that is the starting value for some state.

BTW, this feels like something that should be on <Routes> instead of <Route>, when we get to it.

@ryanflorence
Copy link
Member Author

Ha, yeah, that's why I opened #112.

Sent from my iPhone

On Jul 23, 2014, at 11:18 PM, Michael Jackson notifications@github.com wrote:

I agree, we should have this. To stick with existing React convention, I'd like to call it initialPath. React does that in places where you can specify a prop that is the starting value for some state.

BTW, this feels like something that should be on instead of , when we get to it.


Reply to this email directly or view it on GitHub.

@ryanflorence ryanflorence changed the title rootUrl option initialPath option Jul 24, 2014
@KyleAMathews
Copy link
Contributor

👍 to this. Just ran into a situation where it didn't make sense to put the preferred start screen at /.

@ryanflorence
Copy link
Member Author

Since we reverted from #133, reopening.

@ryanflorence ryanflorence reopened this Aug 6, 2014
@ryanflorence
Copy link
Member Author

Also, I'm not sure initialPath is the right name, because that could mean "when the router fires up, go here", I think I'd prefer rootPath.

@mjackson
Copy link
Member

mjackson commented Aug 6, 2014

that could mean "when the router fires up, go here"

That's not what it means?

@ryanflorence
Copy link
Member Author

ha, no.

Consider a mature app with a lot of server-side rendering + jQuery spaghetti barfed all over the page. You rewrite the app in React and want to use location="history" but when your react app starts up, your url is already /courses/123/files.

With rootPath, a <Link to="foo/bar"/> should not go to /foo/bar but rather /courses/123/files/foo/bar.

Much like our friend: http://emberjs.com/guides/routing/#toc_specifying-a-root-url

@KyleAMathews
Copy link
Contributor

Why not just write out the whole path? Or if that's too hard, add a helper
function which adds the /course stuff? Seems unnecessary.
On Aug 5, 2014 10:54 PM, "Ryan Florence" notifications@github.com wrote:

ha, no.

Consider a mature app with a lot of server-side rendering + jQuery
spaghetti barfs all over the page. You rewrite the app in React and want to
use location="history" but when your react app starts up, your url is
already /courses/123/files.

With rootPath, a should not go to /foo/bar but
rather /courses/123/files/foo/bar.

Much like our friend:
http://emberjs.com/guides/routing/#toc_specifying-a-root-url


Reply to this email directly or view it on GitHub
#111 (comment).

@ryanflorence
Copy link
Member Author

it might be, but sometimes you just implement features you're used to without asking questions.

@ryanflorence
Copy link
Member Author

writing the whole path on the routes is not actually all that bad, closing until more squeaky wheels show up.

@mjackson
Copy link
Member

mjackson commented Sep 4, 2014

This should be a little easier to implement now that we have relative paths.

@tjwebb
Copy link

tjwebb commented Dec 5, 2014

+1 squeakasqueaka

This is a PITA for dev mode; e.g. currently my path is http://localhost:81/workspace/hashware/hashpanel/www/. Makes no sense to hardcode that whole path into my Route definitions when it will be different in production.

I just did this:

  <Route name='app' path={window.location.pathname} handler={App}>

Is that legit?

@ryanflorence
Copy link
Member Author

if your'e using HashLocation that should be fine.

@Davorak
Copy link

Davorak commented May 11, 2016

writing the whole path on the routes is not actually all that bad, closing until more squeaky wheels show up.

@ryanflorence - Consider this one more squeaky wheel in the application I am working I want to be able to host everything on a suburl. Currently use a slightly modified version of Link and have a helper function that I mostly remember to use when using history.push and friends.

@taion
Copy link
Contributor

taion commented May 12, 2016

This is a really ancient issue! We have this concept – it's called basename now. Check the current docs.

@dverbru
Copy link

dverbru commented Jun 27, 2016

@lock lock bot locked as resolved and limited conversation to collaborators Jan 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants