evancz / url-parser

Parse URLs into nicely structured data
http://package.elm-lang.org/packages/evancz/url-parser/latest/
BSD 3-Clause "New" or "Revised" License
114 stars 29 forks source link

Page not found when using parser #35

Closed meherhowji closed 7 years ago

meherhowji commented 7 years ago

Hello Team,

I cloned the parser repo and did a npm install. I was able to load the example in my browser as well. When I navigate from homepage example to a link like '/blog/42' it works, however when I hit that url directly in the browser, it throws me a 404. I also went through a guide mentioned in elmseeds video tutorial, however I am unable to find a workaround.

Any suggestion, workaround or pointers would be appreciated. Thank you.

Update: I am able to make it work under development environment by using a dev config option in the webpack config file to redirect 404s to index page. However when I build the files the same behavior is not produced. Does that suggest I would need a redirection proxy on a prod enviroment.

process-bot commented 7 years ago

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

tkgalk commented 7 years ago

That's a great question, I am facing the same issue (new in Elm). Deep links shared by someone via copy-paste is the reason client side routing exists. We could just change HTML without changing URL, but we want users to deep link to application's state... right?

How should I approach this problem?

john-kelly commented 7 years ago

First and foremost, I don't believe that your issue is something than can be fixed by changing how url-parser works. This issue is related to how the elm-reactor works.

I'll do my best to help in this case, but it's important to note that this issue will probably be closed due to the fact that it's not something that the library author can fix for you.

This issue is related to what the elm-reactor decides to send you when you make an http request to it. Let me try to break it down:

  1. Clone the url-parser repo
  2. Enter url-parser/examples directory
  3. Run elm-reactor
  4. Navigate to http://localhost:8000/Example.elm in your web browser
  5. What happens next?

Well, elm-reactor is running a web server for you -- so when you navigate to http://localhost:8000/Example.elm it makes an http request. You can see that if you open your chrome dev tools:

examplehtmlelmreactor

As you can see, it's serving an html file which runs Example.elm's main. So far so good. Now let's click on a few things:

norequests

I clicked on the links on the Example.elm page and it generated some history under that history header. It's important to note that clicking on these links did not cause http requests to the elm-reactor server. You can read up on how this works here: https://stackoverflow.com/questions/824349/modify-the-url-without-reloading-the-page

Cool! Now the final part. I'm going to manually navigate to http://localhost:8000/blog/42 by changing what's in my browsers url nav: screen shot 2017-07-13 at 5 22 32 pm

And we've finally reached what this issue is about. As you can see by the image, navigating to http://localhost:8000/blog/42 by changing the url manually in your browser causes an http request to the elm-reactor server. The elm-reactor server does not know what you are looking for because the elm-reactor only serves your *.elm files (like Example.elm).

If this all makes sense so far, you'll see that your issue is related to how the elm-reactor chooses to serve things and not related to url-parser.

If you want a bit more proof that url-parser works and it's the fault of the server, pull down this gist and try it on your own machine:

https://gist.github.com/john-kelly/be546ca3e9c26599a0203d392ae8457c

tkgalk commented 7 years ago

Yes, totally makes sense.

I also found some help outside of GitHub and for production - it will work behind Nginx with all requests redirected to index. For development I might use elm-webpack-loader and webpack-dev-server with historyApiFallback flag.

Now I get it why it would be closed. But I think adding that information to README (or in-code comments) would be great as this example is one of the first ones that Elm beginners see.

evancz commented 7 years ago

Seems like the root issue is resolved. If you want some other change, make an issue that describes it specifically with concrete suggestions and reasoning. (Not just a link to some other discussion.)