As far as I know the hash symbol(#) is the key when implementing routing in Angular. The web server only takes care about the part of the URL which is before the hash, and Angular takes care of the rest.
I´ve read some articles that explain how to remove the hash from URL. But if I remove the hash(#) from URL: Which routing works first?
OK, it is MVC. In that case we have to edit the MVC Route in order the server to understand the URL. But we are at the beginning again. Does it make any sense to use Angular Routing and MVC together ? Is not enough with MVC Routing?
Maybe I´m missing something. I hope you can help me.
Does it make any sense to use Angular Routing and MVC together ? Is
not enough with MVC Routing?
TL;DR;
I've rarely use both. The only time I use both is when I need to authenticate the user for some routes.
Long answer
1. Authentication
As you already figured out, Angular routing is great when you want to navigate to another page without the roundtrip to the server. It's usually a SPA. But there might be a scenario when you need to authenticate the user before sending the HTML, then MVC routing will be handy. I wrote an answer about it here. Note the difference between sending HTML and sending DATA to to the client. If you have no server routes the html-pages (or templates) will be fully accessible (unless you limit access in web.config or some other way). Some times the HTML-pages can contain some sensitive information as well...
The most common scenario is if you have a public site with an admin-part. But in my experience you can handle this on client side with client-side-routing only. It's usually the data that is sensitive, not the templates.
2. Server-side logging
The other scenario is when you want to do some logging on server side. For example if you want to log every page request. This can often be done on the client as well... Look at Google Analytics. But you might want to log the request even if the browser has javascript turned off.
3. SEO
There might be some SEO-issues when using client-side-routing. But this is only when we render the html with client side templates and if we compare to completely rendered views with MVC.Net. Do not confuse me posting the link with me actually agreeing with the content...
4. WCAG
In my country all government sites need to follow WCAG. One of the rules are - no javascript. Or at least that the site should be fully accessible without javascript. Without javascript client-side-routes are simply very difficult. ;)
These are some examples when you might need both server-side and client-side routes. But to sum up, in most cases client-side is enough.
Related
I have a Django application with an AngularJS frontend. The application sends notification emails, which it renders using Django templates.
ITEM: {{article.title}}
DATE: {{article.date}}
SOURCE: {{article.link}}
{{article.body}}
The issue is article.link. The previous version of the application didn't use Angular, so it was simple to find the link. In urls.py we had
url(r'article/(?P<article>\d+)/$', views.ArticleView.as_view(), name='show-article')
which meant that we could reverse a URL to a particular article with
django.core.urlresolvers.reverse('show-article', kwargs={'article':article_id})
Now, on the Angular-based revamp of the site, the display URL for an article looks like /mysite/#/article/1234 and is determined by routes.js:
$routeProvider.when('/article/:articleId', { ... } )
Bottom line, I don't have a way to grab an AngularJS route from Python. I could hard-code the all the routes from routes.js into something the backend sees, but it wouldn't be very DRY. I could generate routes.js dynamically with Django, but right now none of our other JS source is touched by Django -- that doesn't seem very clean either. Maybe I should continue to support the old-style URLs (/article/1234) as a redirect to the Angular-style URLs (/#/article/1234)? That still requires logical duplication, I think.
Is there a better pattern I should be using here?
Decoupling clients and servers is often a goal so duplication should not be considered a bad thing in this case. Depending on your needs however there are solutions which provide a reverse method which behaves like in Django. There is django-js-reverse and django-angular for angular specificaly.
In my web app, I don't want to use hash-based routing, I don't want to see any # appear in my URLs. I want to use RESTful URLs, e.g., http://www.example.com/blog/id.
react-router can deal with client-side routing quite well, but if a user hit enter on the browser address bar or refresh the page, the request will be sent to the web server and then the web server has to understand the URL and handle the routing.
Isomorphic is a good solution to this situation since it can render any page on both client-side and server-side. Actually there are many react starter kit projects on Github which claim to be isomorphic.
In my opinion, isomorphic looks beautiful but it's too expensive to write code: you need to make you react components render successfully both on client-side and server-side, which needs developers to make great efforts.
So here is my question, can I just make the react-router be isomorphic, not the entire code?
Yes. You can use react-router for a purely front-end (non-ismorphic) app with HTML5 history.
The routing is determined client side, so react-router will spit out the expected page.
However, whilst you don't need to write any server side code, you will need to configure the web server to point your routes to the correct place. This usually means pointing every single request - or every single valid request - to the same HTML file or entry point. Exactly how you do this depends on what you're using to serve your pages - Express, Apache etc.
I hope that makes sense.
I'm new in MEAN stack area and I have some doubts related to Angular routes. Why should I recreate on the client side the routes already made in backend with express.js, what are the benefits? Is this the only way how Angular.js works? I saw some examples with Jade.js and it wasn’t necessary to recreate the routes on the client side, making the things simpler.
Thanks!
Disclaimer: I haven't specifically used Angular myself, but I have used Backbone.js for the same purpose, and the same arguments apply.
There are many use cases where it makes sense to define routes on the client side, not the server side. For instance, I do a lot of work with Phonegap using Backbone, and the architecture is generally a REST API for the back end, and the data gets used to render the pages on the client side. This approach has the advantage that it reduces the amount of data sent over the network, generally making the app quicker. Client-side routing also preserves browser history when compared to just updating the existing content via AJAX.
Ultimately, it's something you have to consider on a case-by-case basis. For something that's very dynamic, building it as a single page web app with client-side routing may make sense. For a more traditional web app, such as a blog or ecommerce site, you're probably better off defining routes on the server side.
I feel like both Express' and any MEAN stack tutorials gloss over this, so I decided to ask here.
See also these similar SO posts:
Why would one want to use Express instead of AngularJS?
Angular and Express routing
Using plain HTML with Angular directives/attributes as the view engine in Express, what's the best practice for rendering page partials in a single layout template with regards to routes?
How do you do this with HTML/Angular as your view engine?
In Jade, you'd do something like block content.
Do you use the Angular Router, ng-view and use directives?
If so, what's the point of Express? Just a server? Why not just use Connect?
P.S. If you're wondering about Jade or EJS, I'm just learning Express, and Angular, so I'm trying to keep language abstractions to a minimum.
I guess my confusion originates from the overlaps between Express and Angular in regards to templating and routing, but Express focuses on the server-side, and Angular, the client. For someone just learning these, it's tough to know how to implement when everything is so wide open.
I'm looking for detailed, specific implementation code examples that use best practices when it comes to separation of concerns. Seeing it and having it explained in context is how I learn best from others.
Check out angular-blocks if you want jade-like blocks:
https://github.com/wmluke/angular-blocks
It's important to understand that Angular and YOUR_SERVER is generally irrelevant. It's a matter of "where do my files go". As single-page application suggests, it is a single static route. I'm sure Connect would handle this just fine, but the server portion of your application likely has more concerns than simply serving a static page. Authentication, business logic, API routes and other concerns come into the picture at some point, so Express (and its ecosystem) makes a lot of sense.
Your single-page application will definitely have its own routes. These are unrelated to your servers routes, which will include the static route to the Angular application page, and also any routing for API calls that the Angular app will be making.
It's important to understand that you are writing two distinct and separate applications, connect via an API. The fact that your Node server is delivering the static HTML and JS is, for the most part, coincidental. The Angular application should be considered, and developed, in an isolated, decoupled way for best results.
Express and angular serve totally different purposes.
In most MEAN-like stacs situation (for example just express-angular), express acts as server PLUS API provider.
You use app.get('/') with any server side templating like jade (just to have cleaner html files...), then You use app.get('/partial/:name') to handle all partials with same template language.
then, You use app.get('/api/anyapi1'), app.get('/api/anyapi2') to provide whole api to angular - no matter what it will be - some mongo or postgres handling, or just Your static json files.
In new express4 You can also create dedicated api route with:
var api = express.Router();
api.get('/somget', function(req, res) {
res.send('some json');
});
// init api route. all api routes will begin with /api
//(like above api.get will be at /api/somget)
app.use('/api', api);
You can also deal with sessions and authorization on express side, and whole awful lot of stuff, that shouldnt or cant be done on client side.
Hope it helped.
EDIT: speaking shortly: express is backend with http server, other services and api, and angular is whole frontend which consumes what backends provides.
Having such separation You can even provide that backend api to others, or build different services on top of it.
Correct, the MEAN stack puts an emphasis on making most of your logic on the front end. Your express server will act as a mule to save, read, validate, and delete data based on the get and post request you make from the front end.
The idea is to have all your front end code in a public folder of your express app.
`app.use(express.static(__dirname + '/public'));`
Then simply make a route that renders the index file as such
`app.get('/',function(req,res){
res.render('index')
})`
With this in mind you may we wondering if there is a solution that can generate an api for you so that you just name your models and the rest is done via angularjs services. There is.. http://loopback.io/ just name your models, relationships and restrictions. It will generate an enteprise level api for you to play with.
For a complete working example on how routing is done and how to model your app check out this tutorial: http://www.ibm.com/developerworks/library/wa-nodejs-polling-app/
I'm doing some due diligence on backbone for a single page app and wonder if it is possible to re-use the same views/routes from the client on the server side, so that when google visits a pushstate URL, or it is accessed directly, the server can generate the exact same HTML that would be generated by backbone in the client.
It would be a pain to have to maintain two separate sets of views/routes, one on the client and one on the server. I have seen the backnode project on github however this seems to miss the point a bit and you end up having to write the same backbone router twice.
Just wondering how people are generally handling the case when using pushstate urls in backbone and needing to serve the same view from the server? Are people duplicating code or is there a better way?
I haven't tried this yet but these ideas using node.js and backbone might help:
http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
http://bennolan.com/2010/08/13/pushstate-and-nodejs.html
Basically the only way to make it so your not writing the same thing twice is to have both your node.js server and frontend client share the same routing/model code. If you are using something else on the server side (like Ruby) you would have to place node.js in front of your app server. Then make node.js proxy for new clients (push state and client js) and do actually rendering work for old/bot clients.
The other option is doing what jQuery Mobile does which is the Hijax method. The idea to make tons of HTML5 pages (you'll have to look at its routing to see).
And for completeness you should be aware of how google crawls AJAX: http://code.google.com/web/ajaxcrawling/docs/getting-started.html
This project does exactly what you are trying to do. It might interest you to check it out.
https://github.com/developmentseed/bones