It seems that there is a trend in eschewing designs which lend themselves to massive and unruly controllers for a more directive-based, granular design pattern--Angular 2 seems to be promoting this direction as well. I, admittedly, have rather large, non-DRY controllers in my angular apps, and wish to start using angular without relying on massive controllers and page-level scopes, but when I think about simply using directives for everything that I would have stuck in a controller the prospect of initiating and maintaining communication between relevant scopes, controlling scope inheritance, and keeping directives as modular as possible seems like I'm just thinking of directives as tiny, isolated controllers with an attached scope. Is this the wrong way to view this angular design pattern shift? How can I properly think about designing with directives if I am used to holding much of the logic in services / controllers? Is this still MVC or MVVW?
Related
I'm relatively new to Angular and have begun writing my application with a component architecture. When looking through the Angular docs it recommends testing components with the $componentController mock method.
However, when I look at how directives have traditionally been tested in Angular pre-1.5 it looks like the preferred method was to use the $compile service to actually build your directive template-and-all. By using $compile you can make assertions about your template logic as well as the controller logic. Whereas with the $componentController method you can only test the controller logic, which doesn't actually seem all that useful since most complexity is found in templates and services.
Can someone shed some light on modern best practices? To me it makes more sense to use $compile so that you can test the template as well. But why do the Angular docs not mention this at all and instead recommend $componentController?
One of the biggest problems with AngularJS is that it has $scope. This is the place you put your bindings onto that are used in the DOM. It introduced much confusion.
Every good application design should have layers: business logic, UI etc. In AngularJS those layers pretty much corresponded to controller for business logic and directives for UI. However, because of the $scope being available in directives, many people decided to not use controllers and put all business logic in directives. This led to hard-to-test directives because they simultaneously implemented both layers. Also test became slow since DOM manipulation is slow.
Ideally, you should put as much testing as possible into business logic and less in the UI. Since framework handles synchronization between business logic and UI there is little possibility of bugs there. But business logic is where most bugs are introduced. That's why in the newer AngularJS they recommend to use $componentController to test business logic in controllers, not directives.
New Angular doesn't have $compile and most tests are written for controllers, which are implemented as classes there.
I know that this topic was discussed many times but I'm still not quite sure if I'm doing things right..
Many on-line resources embrace directives as a building blocks of the angular applications, in the same time many resources emphasize re-usability of the components. Anyway from my experience when I build typical app, there is not much things to re-use, usually each component has single role and it is used in the single place. As I understand angular, one of the main concepts is to provide semantic DOM, and in order to achieve that we can use directives. So when I build an angular app usually I create a set of directives and combine them in the views.
In my apps in the most cases all the DOM manipulation can be done using the build in directives. Most of my directives has a template and a controller, I do not need to use link function. In most of the resources in the internet I can read that I should use link function when creating directives. But this seems to be far more complicated code... . What is the benefit of the link function if I don't need any fancy DOM manipulations that are beyond build-in directives ?
tldr; I build my apps using directives with controllers and put them into views, is this a right approach ?
I've been developing in Angular over a year now on an enterprise level application and my team has gone by a standard of creating directives if you are using that same element more than once. It saves time, saves the DOM trouble, and makes it easy to create separate, testable pieces of code.
We've created directives for many listing items that use ng-repeat. Pretty much every ng-repeat we have is iterating over a directive to create true isolate scope in our elements' functionality. It's one of the most powerful features in AngularJS when done right and conforms to the standards of Object Oriented Programming where you can really make your applications use abstraction to the finest degree. Here's a wiki link on abstraction.
I know from experience that internal communication between controllers should--when at all possible--not be implemented using $emit and $broadcast with $watch--this introduces perhaps unnecessary dependencies and is difficult to map, both mentally and physically--looking around for $emits is no way to track $scope changes.
Many advocate sharing data with services which also includes introducing $watch[ers] into controllers. Nesting views and sharing $scope is another option though it may not always be possible.
Does anyone have any readily available info on how these different techniques affect performance in a general manner?
I understand that the subtleties and nuances of angular app performance are difficult to pinpoint when complex app are implemented and dependencies start stacking up, but it would be very informative to the angularjs community (and myself of course), if one could discuss the performance differences between $scope sharing techniques among controllers.
The correct answer will detail the three techniques stated above and discuss their virtues and pitfalls as they relate to angularjs app performance. Thank you.
I have a big app, which contains many layouts and subviews.
Looks like (simplified):
http://plnkr.co/edit/x4kleCCQH5Hsy6dcjgXe?p=preview
So, I have many directives and services. And only 2-4 simple controllers (10 - 20 lines of code). All logic stored into big directives, which contain many small directives. Am I wrong?
The way I'm approaching it is.
Directives contain view logic, not business logic. This is also where DOM-messing about happens if needed.
Controllers are fairly thin, have minimal business logic.
Angular Services are where most of the heavy lifting is done.
If you have logic that needs to be re-used by multiple areas/controllers or is stateful - it's probably a better fit to put into a Service than a Directive.
Depending on your app/architecture - you could be posting to a server, and having the heavy BL happen on the server side.
The Angular docs have a nice bit on Using Directives Correctly that has a few pointers.
Sounds good to me.
At some point in the DoubleClick talk, the speaker says something similar to "make controllers as thin as possible."
The link was busted... a working link to the same guide is here:
http://docs.angularjs.org/guide/controller
When I gloss over the backbone.js site, I'm not sure what is it trying to do.
It seems somewhat popular, but why should I want to learn it? What will it do for me? Why was it made? What problem does it solve?
I find the question perfectly valid and from my point of view there is nothing wrong with inquiring about the potential use cases of a library/toolkit.
What Backbone.js does (so do several other javascript mvc implementations) is that it provides a means of organizing the code into a modular pattern known as MVC pattern which is all about separating your code into three loosely coupled layers:
Model layer dealing purely with data and associated operations
View layer being the presentational aspects
Controller layer being the binding glue layer
(different frameworks deal with this differently : Backbone implementation of controller layer comprises of client side routing capabilities).
So, on the whole backbone provides you an infrastructure using which you can deal with data through models which contain encapsulated within them the data and associated validations, which can be observed ie. you can bind events to change events.
The View layer is mostly left for the user to separate the ui into manageable isolated sections.
Here are some problems that Backbone solves for me in the JS/HTML space:
Separation of Concerns (SoC)
Composability
Testability
Component Model
Abstraction
That is not to say that this is the ONLY system that does this. There are others. Backbone does a pretty good job of helping with these things, though.
From backbonejs.org
It's all too easy to create JavaScript applications that end up as
tangled piles of jQuery selectors and callbacks
And that's exactly what backbone does, a series of callbacks on model changes and jQuery selectors to bind events.
So to answer the question, it solves nothing only to provide a way (the backbone way) of structuring code with some slight automation in the REST side of things.