I'm building a view like the one below but have some doubts on how to do it. I don't want to make unneccessary calls to the service but I want to keep things simple.
My thoughts
The small piece of basic information with name etc will always be visible. I guess this little piece would be a nice directive? (never wrote one myself)
For the tabs I'm not sure how to do it at all? Will I make every tab a view with it's own controller (and a service that will fetch specific data for that view) or should I fetch a huge customerobject and put in some storage or..?
Would appreciate your thoughts and answers about best practice, regards!
I think you can use angular-ui-bootstrap directives, it includes some useful directives.
http://angular-ui.github.io/bootstrap/
Related
I have built an Angular app that consumes data from different sources (SharePoint lists). I setup a controller for each source.
What is the best practice for this? Use only one controller for the app and different services? Or one service and one controller? Or multiple services and controllers?
In the app I do not use routing.
First I'd recommend reading these articles. Also, go through their angular implementation and see how they've achieved some of their effects. It will throw you in a world of problems that you'll feel like "Why? I mean, why? why did I ever got into this mess?" But, grit your teeth and get through it. Then you'll see how much you can achieve. Learning Angular JS is a never-ending cycle of this.
angularjs-best-practices-directory-structure
Angular Style Guide
Advanced Design Patterns and Best Practices
The Top 10 Mistakes AngularJS Developers Make
Ok, and to answer your question: your way isn't wrong.
But controllers are not designed to be used like that. Controllers are a unit of code which co-ordinates your data into the UI, handle UI events, etc. generally of a certain view - i.e. a portion of your UI (navigation bar, home page, edit form, etc.). Of course this can be your entire page as well. But it's best to break it down so that it's easier to manage.
Use services for what you described. Create a service for each data source or type of data (users, equipment, roles, etc.). I recommend that latter, since sometimes you need to pull data from multiple ends and tie them together. This can be done inside your controller as well, but having services will enable you to re-use that functionality in another part of your application.
To summarize a long answer, I'd say go through these articles, code and tips. Then build a structure that will help build your application. Just don't over-engineer it.
I would say: use a controller for every "piece" of HTML in your app, (and it depends on the scale of your app how big that piece is, it could be just one controller if your app is really small). And use a service for each data source. Then you can use the services your need in your controllers. You could also use one service if you don't need a lot of behavior. It all depends on how big your application will be.
I have a web app that I'm building in AngularJS. It has accumulated 500 lines of code and is quite a burden to sort through it all. I was wondering if it would be possible for me to break off the logic into multiple files but still be able to interact with some of the $scope variables. Any resources on this topic would be appreciated.
Ex: I have a bunch of logic dealing with tables generated by ng-repeat that doesn't need to interact with code from graphs that I'm generating using Canvas.JS
These articles might help you:
http://briantford.com/blog/huuuuuge-angular-apps
http://cliffmeyers.com/blog/2013/4/21/code-organization-angularjs-javascript
Also read this answer.
I mostly choose the Modular approach.
Did you code all your app in a single controller?
I would think about:
Having an skinny controller (only exposing the scope content needed, and grabbing the content from services).
Implement services (Factories), in this factories you can for instance encapsulate your $http request to get the data you want to show.
Implement directives: e.g. if you are building a common chart, you can encapsulate it in a directive (it's like a control), is easier to maintain and reuse.
Once you have that I would jump into Danilo great suggestions.
Another link that might help you:
http://leog.me/log/large-angularjs-app-components
It's about a solution with RequireJS to partition the application in multiple modules that can be hooked together very easy.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a lot of jQuery background and am currently getting into angular.
So far I have resisted the urge to include jQuery to get things done the way I used to.
I would like really learn to do things the angular way.
Here are some things I ran across and I would really like the opinion of some angular professionals on them:
Adding user interactions.
Standard scenario: If the user does this, do that.
Should I create directives for each case or add methods to the controller?
How do I decide wether to make a directive out of it or just a controller method?
Adding the same functionality to multiple elements
Presume I have a bunch of divs spread out over the page, or even just several cols of a table.
In jQuery if I wanted to do something, when the user clicks on any of them I would just do $('div').click(...) or $('#mytable th').click(...)
In angular the only way I know how to do this is the ng-click directive, which results in very verbose code, when adding this directive to every single element.
Especially since I thought angular was supposed to make code more readable I was wondering if there is a better solution to that.
Separation of Code
One of the things I like about angular is the effort to keep html in html files and the js in js files. This was actually one of the things that most annoyed me with jQuery.
But the way directives are set up sort of contradicts this. Here you define some template html code (or link a template file). The same goes for user interaction handlers (i.e. user clicks this -> display that message).
So in the end I end up again sifting through code to find out where that particular piece of html code comes from. Am I missing something here?
MVC
In most of the examples out there the model is defined inside of the controller.
Shouldn't it be defined somewhere else for true MVC separation? What about for example always creating a service for the model, since often at least parts of the model are loaded by services anyway? Or am I overstepping the mark here?
app.js
This is more of a side note: I find it confusing that for both node and angular the convention is to call the main file 'app.js'. If I have both files open in my editor I have to click through them to see which is which. I know I can name then however the hell I want but as I said I'd like to do things right and am just wondering if this never bothered anyone else... Maybe angular should consider enforcing the convention "app_ng.js" or something...?
Please post your thoughts as answers, not comments, for readability purposes.
thank you,
Jan
User interactions
These can be done both using directives and controllers. there is no strict rule on when to use controllers or when to use directives. Often small one-off interaction code is done in controllers, but more complex interaction logic is done in directives. Reusable interaction logic should always be done in directives. Same as DOM manipulation. That also should be done in directives.
Multiple elements, same functionality
Often when this is the case you should be/are generating those elements anyway. e.g. using ng-repeat. Which reduces this to changing 1 line. In the situations where that is not the case, you could make a parent directive that checks the children. However, it might also be the case that you just need a custom directive. e.g. multiple divs doing a similar thing all over the page? Perfect example of something that should be a directive. Then you can either use the template in the directive or use more specific logic in the directive link or controller function.
html-js seperation
Most directives use templateUrl to do the templates which keeps them in partial html pages. A few libraries pre-seed the $templateCache on run so that angular doesn't need to request those templates. (also allows for customization by replacing the $templateCache entry.) When looking at the DOM in the dev tools it might not be completely clear where that html came from, but if you look up in the DOM tree, you will find the directive that is responsible for it. In older versions of angular it was possible for directives to use "replace: true" to replace the actual directive in the DOM, but in 1.3 that is deprecated. So, now you have the directive. Next is to actually find where the directive is specified. This depends greatly on you project layout, but with good project layouts it would be as simple as just browsing to the correct folder. e.g. bla-date-picker: prefix is bla, so it is in the blabla module. open blabla module, find a directives folder. open directives folder, find datePicker. Then in the directive definition you see if it uses the template directly or if uses a template html file.
Regarding code that lives in controllers, you should already know which controller you are in. For example by again looking at the DOM tree and seeing which controllers are the parents. Then you only have to find the correct controller file(again, this depends on your project layout. A good layout will make it easy to find). With a good DOM layout the object will at most have 2-3 controller parents and most often the lowest controller in the tree at that point will have the code you are looking for.
Do note however that angular does not place a whole lot of restrictions on you. So you can still make a mess of the project and make stuff hard to find(e.g. defining everything in 1 file, use $rootScope, use 100s of nested controllers, etc.). It is up to the developer to make sure those things don't happen. In a good project it should be easy and straightforward to find things. In a bad project, well....
MVC
Angular is not an MVC framework. You can use it for MVC but you don't have to. Often examples are kept small which means it doesn't use best practices for brevity sake. So yes, in general you would want to define the models in services(or as services).
App.js
You don't need to use angular with node. Also, you can name it whatever you want. For example in my projects I don't have an app.js for angular, but only a file named after the app module. And even better, I have 2 separate projects. 1 back-end(which is mostly API) and 1 angular front-end project. Because with angular the need for a templating engine is almost non-existant you can serve all angular files as static. Meaning that it is relatively easy to separate it to its own project.
The following picture is my web architecture.This is my first website too.This site is a kind of control panel, thus it is composed of many buttons and events.As the requirement becomes more and more, it becomes hard to maintain.
Web Architecture
Let's say if I need to add a new function, I need:
1. UI : design Input & output.
2. create event handler by jquery.
3. create ajax function. (draw the results on success function)
It is just like a chain.The problem is:
1.change one thing = change every thing.
2.Can't manage the output view very well(the output view can be a table, options, label..)
So I'm curious about does there exist any framework or better way can help me?
Thanks.
Your project might be having a "jQuery soup" problem, but to answer your question there's just too many MV* JS "frameworks" around, e.g. Ember.js, AngularJS, Backbone.js to name a few.
IMO Backbone.js is easiest to fit into an existing project in case you want to slowly refactor your existing code. There are others that are more opinionated and do a lot more for you, but you may require more substantial refactorings in your JS code.
All the above "frameworks" will help you with managing models, the views, events, and tying everytihng back to the server.
I'm reading this:
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
I'm using backbone.js. I love it, though it requires too much boilerplate. Anyway.
The author of the post seems to put great importance on UI-bindings and composed view.
I think I know the basic advantage of ui bindings, you can change small parts of the view as the model changes without re-rendering the entire view. I don't necessarily see the point though. If your view is huge maybe you should make smaller views? I've seen knockoutjs's code and it's littered with ugly data-bind stuff. How does emberjs handle it? Is there an example?
I have no idea what he means by composed views, could someone elucidate?
Composed Views - Like all software developers, I enjoy creating modular reusable code. For this reason, when programming UI, I would
like to be able to compose views (preferably at the template layer).
This should also entail the potential for a rich view component
hierarchy. An example of this would be a reusable pagination widget.
Is there an example?
Thanks
Edit:
Would this help make something like composed Views?
https://github.com/tbranyen/backbone.layoutmanager
Composed views are used to divide the view into small blocks which can be reused or adapted to different scenarios.
For example, in a form where you are editing a user, you could create a view for the address field and just call it from the main page/template. The author mentions pagination as an example too, in this case you could create a model that knows how to handle retrieving data as you switch between pages and just apply it to a table in your page.
Regarding the "ugly" data-binding code, backbone needs to know how to attach itself to the existing markup and how to modify it when an event occurs.
Maybe this example will help:
http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started/
Traditional web pages are monolithic. User calls a page and server constructs the page and browser renders it. Here author is referring to breaking down that kind of code in to a set of views. So your page is made up of multiple parts. And each part gets rendered and updated independently. Or one model change can trigger a series of updates on some or all parts.
Basically this allows you to create 'desktop' kind of applications on web. And you don't have to resort to iframe hacks to do this.
Gmail and Google Reader are good examples of web applications built with composed views.
I created LayoutManager for Backbone.js because I too wanted to composite views.
http://tbranyen.github.com/backbone.layoutmanager/
Let me know if you find this approach helpful.
It sounds to me like the author is talking about server-side code here. Building a system of reusable page templates, that generate pages from a common set of widgets, html snippets, etc...
Apache's Tiles is one way of doing this.