Closed meherhowji closed 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.
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?
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:
http://localhost:8000/Example.elm
in your web browserWell, 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:
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:
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:
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
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.
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.)
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.