Simple enough question I think. I see people raving about it but I haven't seen anything on the "why" use it. It doesn't seem to me (from my naïve outside perspective) ng-repeat, if not in that nested layer do ng-repeat inside another. I looks like that it doesn't add functionality that angular doesn't already have—I'm sure I'm wrong—
I see the term "lazy loading" being used with it and it doesn't seem like it's that much easier after seeing there docs. What are some things lodash makes significantly easier in AngularJS specifically that I would make it work adding another lib to my project? And what can you do with it that you cannot with angular out of the box?
They're just not the same, and exist for distinct reasons. I think you already know what AngularJS works for, so about your questions:
What can you do with it that you cannot with angular out of the box?
Well, if you need to deal with several data in structures like arrays, objects or mixed/nested shapes, lodash will save you a lot of time and effort.
Maybe there's a lot of items in collections which should be presented to your client application in some particular way, you would have to write a lot of JS code in Angular controllers or services with out the aid of lodash.
If there's a lot of logic tied to your data structures and/or complex algorithms and coding workflow, go for lodash.
Lodash is a great tool, you can get some intro here and of course, just check out the API reference. You can use it at everywhere, either Angular or any other framework, and of course, also at Node too!
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 have a general question. I've recently seen plenty of examples of people putting all their directive logic in a directive controller (and using it with controllerAs) instead of using link. I do see certain benefits in that:
The directive logic can be easily unit-tested.
You are seamlessly obligated to use the "dot notation" in your view model, thus prevent unexpected behavior.
As for the disadvantages - once the logic is inside the controller, it is exposed to other directives, as if encouraging developers of other directives to access those variables/methods, even if they are not meant to be accessed from outside.
I am interested in getting your take on this? How do you organize your code inside the directive.
Thanks
I am using Angular for about 4 months so I cannot
Say that I have too much experience. However in my
Personal experience I used the controller only for logic
That needs to be shared or executed before the link
Function. I guess you can hide some logic from your controller by using the module pattern and only exposing the logic that is really necessary. In my defense I haven't wrote really complicated controllers but this is the way I would go. (Sorry for my bad writing I am responding from my phone)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Learning angular is a pretty frustrating process. I've just started the journey down this endless road a couple of weeks ago. I've gone through the official tutorial on the angular website, watched the first 40+ videos on egghead.io and read through several other tutorials and examples. I'm new to angular but have a good amount of experience with javascript, jQuery, and knockout, but even after all of the research and examples I've gone through, I still can't piece together even the simplest angular app in a real-world situation.
The problem is that most of these tutorials and examples try to show all the different parts of angular, including controllers, directives, filters, services, $http/$resource, routing, animations, etc.so you end up with this one or two controller app that doesn't have any substance but it incorporates the basics of all of these features. Now, strip away all of the features that aren't really needed for a simple app like $resource, routing, and animations, and add substance to the business logic and data management, and you quickly can see how many holes exist in these tutorials.
For example, a tutorial will show how you can share data between controllers using services. It will go over creating the controller, and using a service to get the data from a server using $http or $resource. Then it will show that even though the request for data is asynchronous, there is rarely a need for callbacks because the data-bindings will just be empty until the data arrives and then magically filled in. Now you have a reusable service to get data in all of your controllers.
Wow! everything is so simple and clean, and it just works! Angular is awesome! Then, of course, when you go to write an actual app that needs more than one controller, and the controllers all depend on the same data, and you add something called "business logic" that is also shared and uses this data, you immediately realize things aren't so simple.
First of all, as soon as you add business logic that has to use the data from the server (like with any real app), your clean code with no callbacks is broken. You now have to implement callbacks everywhere, because you have to wait for the data to arrive before you can use it. Second, prototypal scope inheritance becomes unreliable because you don't know if the data from other controllers has loaded yet or not. Worst of all though, there is nothing in these tutorials about how you are supposed to keep the data in sync between controllers, and with the server. If the data is modified in the scope of one controller, somehow all of the other controller scopes need to be updated as well...
These are just some of the complexities that are introduced even with a pretty simple app that doesn't even use routing. I'm trying to make a simple calculator that doesn't persist data, and I am stuck with all of these problems and questions and can't find any real solutions.
Can someone please point me in the right direction of a good tutorial, example, or book that will fill in these missing holes without getting into complex parts of angular that my app doesn't require?
Thanks in advance and sorry for the rant, this has been very frustrating :/
I am far from being an angularJS expert, I am actually in the process of learning too. However, we are almost done with our first angularJS MVP at work so maybe I can share some of my experience. Here are a few patterns I learnt
Your controllers should be minimalist and call services and factories.
Controller actions are triggered by $emit and $broadcast which is what keeps everything in sync. I have controllers with just a list of $scope.$on('onCustomAction',function(event,params){ $scope.myObject.doSomething(); }). Ideally, it should be a minimalist list of those.
In ng-click, you should have methods like myObject.fancyMethod() where myObject is part of the '$scope`.
Put small pieces of reusable html that have their own little controller in directives. I am quite late on that but I am starting to have a few.
Use ng-include for large pieces of html that you need to move around (ie: modal windows, main content, sidebars etc).
Remember, if it's not in the $scope, it might as well not exist.
Services can call other services and can be used for singletons and instanced objects. They should be the meat of your code.
Hope this helps. Feel free to argue each of those items.
As someone who was experiencing the same type of angularjs frustration. I get it. What helped me immensely was Jeremy Howard's 4 part tutotial, "Angularjs End to end web app in under an hour". It uses ASP.net but I am sure most of the back end examples would be easily reproducible with any other framework.
Here is a quick and dirty laundry list of why I found this useful.
Example is a Todo CRUD app that could be used as a template for most other web apps.
The videos move at a reasonable pace and are broken down into logical functional areas.
Jeremy uses some of the techniques you described above that are in other videos such as promises, directives, factories, services, link functions, controllers, etc. However, the examples he uses do have substance as they work within the context of the todo app.
Lastly, it becomes clear in watching Jeremy going through his tutorial that being very organized in how you structure your back end will make your front end angular app so much better and powerful. Think separation of concerns to a whole other level.
I could go on and on but one thing I can say, is that Jeremy's tutorials not only made me better at angularjs but made me better at being a full stack developer.
Do yourself a favor and check it out. You won't regret it. Good luck.
Here is a nice tutorial on data model dealing with your problem:
"Worst of all though, there is nothing in these tutorials about how you are supposed to keep the data in sync between controllers, and with the server. If the data is modified in the scope of one controller, somehow all of the other controller scopes need to be updated as well..."
http://www.webdeveasy.com/angularjs-data-model/
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.