I am learning AngularJS and MeteorJS and would like to use them both. I noticed that each package has their own object to store global variables: $scope in Angular, and Session in MeteorJS.
Does it make sense to sync them, i.e., a variable change in $scope will cause corresponding change in Session and vise versa? How should I go about it?
(Not an entirely satisfying answer but rather a quick heads-up as I'm currently experimenting/evaluating with both right now)
Meteor uses the Session as a global cache object whereas Angular $scope is simply but powerfully based on the classic concept of scopes -- and along the way brings an intuitive understanding of what it means. In other words, controllers and directives in Angular have their own $scope, while Meteor templates and pretty much all objects could all access the Session object.
As far as I see the current benchmarking game between Angular and Meteor, both are very well thought frameworks but don't fit too well together as many components are redundant -- same observation for Backbone and Meteor. Reactive programming is achieved in Meteor, same as Angular does it with the two-way binding variables. Meteor seems to make things easier by enabling one language and toolbox for both client and server.
Related
Why do we need services or factories, we can also do the same thing by making a normal javascript function, or writing the logic in the controller itself.
For example, when i get json data from the server using '$http.get', i can do it by writing a separate service for it but why is it even required when we can directly write its code in the controller?
This is a good question to ask for clarification before digging into Angular as understanding the parts will enable you to write good Angular code and not just do something because you can.
http://i.stack.imgur.com/BKl1Y.jpg
This is a good visual for Angular as an MVC.
The simple answer to your question is that services should be passing information through your controllers to your various pages and routes. All information logic shared across these views belongs in the service. Controllers pass along that information from the view to the service and from it. Information and logic local that view that doesn't need a broader scope can stay in the controller. This is the clean separation that makes Angular a strong framework.
I have worked with MVC on the back-end (Rails), and am currently working with MVC(MV*) on the front-end (Angular). I have seen Angular as considered an MV* pattern, but why is it considered that exactly?
Using Angular, I understand the separation of concerns, with Views (templates), Controllers, and use Services to serve up data. In this case, the model (data store) via ng-model makes sense for front-end temporary storage, but the actual persistence (when a POST or PUT is made to an API) seems to be the wildcard. As the way data can be persisted, could be handled differently (database, firebase, etc..).
It seems to me that *VC is more appropriate based on my understanding, as Controllers in Angular are better defined than Models.
There must be something core about the MV* pattern that I am missing or confused about, any clarification is greatly appreciated.
Here are a few ways * can be chosen in Angular:
Controller:
ngModelController
$controller
View Model:
dependent expressions
directive attributes
Presenter:
WebGL Directive
Presentation-Abstraction-Controller
module per iframe
Important thing is that UI and Models are the common denominator. Build interesting UI without breaking app and build interesting business logic without breaking UI.
References
Keynote for BackboneConf with Jeremy Ashkenas
I started working with AngularJs recently.
Looking to understand the reason for using multiple controller, I found different site explaning how to use multiple controller (AngularJS site). But what I'm actually looking for is a rationnal for using multiple controller.
So my question is : Why or when should we use multiple controller in a project? and the subquestion that is tied to this question: is it a good pratice to use multiple controller in an Angular project.
That's also an MVC question as angular extends this pattern. In Apple's View Controller Programming Guide for iOS, it says :
Every view is controlled by only one view controller.
So the idea in MVC pattern is to separate views. By having 1 Controller per View it makes it easier to achieve this. it simplifies the organization of controllers that serve one module. You do not suffer from code smells.
Also, it is important for routing issues in app.js for angular case. It clarifies structure for other developers that will have look at project. Using testacular in angularjs, unit testing is great, having multiple controllers makes unit testing easier.
Edit :
You would also most likely need more controllers for further functionalities. For example a Auth Controller where users can create new accounts. In addition to this you need a superadmin view where you can edit the resources with higher privileges. In such a case it is quite common to have separate controller. Scope and security issues has to change.
It is just a very good pratice to use 1 controller per 1 view. So for example you should have seperate controller for /home view, another one for /gallery, and another /contact.
It forces you as a developer to organise your code, so that you can take advantage of using services, filters etc.
Also it is easier to write unit tests because you can see what is covered and what is not.
When I first looked at Play and went through all the samples, I was pretty excited by the zentasks sample and the fluid, clean, effortless Javascript routing that left the work of rendering things to Play. But we decided instead to go with Angular.
Upon going down that road, I thought that Angular would control all aspects of rendering.
However, we have a page that has to get a socket. We were having the socket made on the server, so for now, we still have a Play (Scala) template doing that. We have pared it down to pretty much nothing: create the socket and then inject it into the Angular context.
But we are also trying to do Protractor tests and that is made uglier by having to figure out how to accommodate the Scala template.
Question: should we just ditch the scala template and have the Angular controller call the server and get the socket? That was my favored approach to begin with.
I'm currently working on two Play apps with Angular and in both we decided to have one single main.scala.html file that load all the necessary controllers,services,directives, etc from angular using of require.js.
The goal with Angular is to create a single page app and therefore you should avoid to mix it with server side templates.
You must see your main.scala.html template as the entry point of your single page application. There you generate and load all the pieces you need and give the hand to angular to manage the rest.
I agree with Renato. It's probably better to have a single controller and template that sets up the single page app with angular. Then use AJAX to send requests from the browser to other controllers (see http://www.playframework.com/documentation/2.2.x/JavaJsonRequests).
If want to to avoid Scala templates completely, you can put your web pages and javascript in the public directory and only use AJAX.
I am currently using the Backbone philosophy which involves dust.js for template style. Recently I came across AngularJS, which extends the HTML syntax with custom elements and attributes.
Cons of Backbone+dust.js environment:
Upgrading components is time consuming.
Module specification and identification is not easy.
If I move my functionality to AngularJS will it be helpful or does it feel the same?
Can anyone explain to me what the major differences among these two libs are, as they seem similar to some extent?
dust.js is purely a templating module. So, it allows the combination of json with a template to deliver html output.
Angular.js is client side framework that allows binding of logic to variables defined in a template (your page).
So, with dust.js you are responsible for deciding when to run the json through the template. Typically you feed in the json on the server (or client) and ask it to render the results.
With angular.js when the model (the json) changes the framework re-renders as appropriate. Triggers for that change could be user actions (such as filling a form in) or it could be due to loading some fresh json from a service.
Typically you would use angular.js if you want a single page JS app (think gmail). dust.js is perhaps more akin to a traditional approach with multi pages with content driven by passing in json.
You could even use the both of them in tandem - server side rendering using dust.js with dynamic client side logic in angular.js.