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

Switching to path location strategy #472

Closed
denissb opened this issue Mar 27, 2016 · 13 comments
Closed

Switching to path location strategy #472

denissb opened this issue Mar 27, 2016 · 13 comments

Comments

@denissb
Copy link
Contributor

denissb commented Mar 27, 2016

I'm submitting a question about the decisions made in the repository.

Currently the starter is using hash location strategy for the routing by default. Why not switch to path location strategy?

I believe most users want to be html5 compliant out of the box. Browser support for Angular 2 includes only IE9+ with more recent versions of Chrome, Firefox and Opera, so it's not an issue.

@PatrickJS
Copy link
Owner

hash location strategy is easier to understand how a SPA works. Even if the goal is having html5 support

@denissb
Copy link
Contributor Author

denissb commented Mar 27, 2016

I was thinking the goal of this repository was to get people up to speed with an Angular 2 project instead of teaching them about how SPA works.

But if the intention is more towards the second I will happily close.

@samvloeberghs
Copy link
Contributor

Does the Path Location Strategy fall back automatically to Hash Location Strategy? :)
For example on IE9

@denissb
Copy link
Contributor Author

denissb commented Mar 30, 2016

@samvloeberghs nope :)
Normally path location strategy should work on IE9 if you use a polyfill like history.js
Sadly I have not experimented with it much, but if support for hash location strategy is more IE9 friendly then it's a reason to keep it.

@dsebastien
Copy link

@samvloeberghs the bootstrap code could probably use Modernizr to detect if the history API is there or not and adapt the config based on that. IMHO IE9 shouldn't be considered anymore anyways, time to move on. Microsoft dropped support, let's not live in the past. Ask people to move to a modern Web browser :)

@samvloeberghs
Copy link
Contributor

@spawnius @dsebastien totally up for that! But why do we still have Hash Location Strategy than.. Can't think of a case other than IE9

@denissb
Copy link
Contributor Author

denissb commented Mar 31, 2016

@samvloeberghs - while IE9 without push state support might be one of the reasons, the major one I see is when you don't want to delegate handling of deep links to the front end. Example: ngnix web server is handling / while the SPA is handling /# based routes.

@louisscruz
Copy link

I was going to open an issue relating to path location strategy, but it might be more appropriate here. Maybe @spawnius can help me out. I'm using path location strategy. On my server, nginx is handling incoming requests and sending them off to either the front-end server or the backend (api) server. I can't get non-root routes to work on refresh without specifying all routes like the location /about block below:

upstream app_server {
    server unix:/var/run/unicorn.sock fail_timeout=0;
}

server {
    listen   80;
    server_name xxxxxxxxxxxxxxxx.com;

    location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|mp3|flv|mpeg|avi)$ {
            try_files $uri @app;
    }

    location ^~ /api/ {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwaded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://app_server/api/;
    }

    location /about {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://198.xxx.xxx.xx:8080/;
    }

    location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://198.xxx.xxx.xx:8080/;
    }
}

If I remove the location /about block, then the /about route can not be directly accessed. If I visit / and navigate to /about, all will be fine, but on a refresh I'll get a 404 in the server logs. With the block, however, refreshes work as expected. Also, I don't understand how dynamic uri's (e.g. /users/3) can work out between nginx and path location strategy.

Any ideas?

@denissb
Copy link
Contributor Author

denissb commented Apr 13, 2016

@louisscruz this is a question for stackoverflow as it is an implementation specific matter.

@dsebastien
Copy link

FYI I've added support for push-state in the production build of my fork (dev mode being ok with the historyApiFallback option: dsebastien@1b351b9

@louisscruz
Copy link

@spawnius I totally understand. It's just that I've already made 4 or 5 posts on SO and Serverfault about this issue over the past few months. No luck. I personally think that it would be great if someone did a wiki on this, if anyone actually understands how this implementation should work.

@dsebastien I'm going to check out your setup/superstatic later. Thanks!

@PostImpatica
Copy link

I spent days wondering why back clicks weren't working. I thought i was supposed to add the following to the app.routes.ts file like the official docs state:

export const appRouterProviders = [ provideRouter(routes) ];

I then imported this into the bootstrap and everything appeared to work as push state except back clicks. Took me forever before I realized that location strategy is being forced and I'm not supposed to use provideRouter I guess, even though I have no clue what it actually does.

@mdo2
Copy link

mdo2 commented Oct 21, 2016

Thanks @dsebastien for you suggestion, it's exactly what i am looking for!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants