We initially approached Marionette Behaviors as a tool to build modular components for our views but that's the thing - only to create behaviors for re-usability. There are still specific behaviors I would like to build in order to separate the view from event driven behaviors however, they would be considered too specific ie. events driven behaviors on a form that interacts with a complex template with complex business logic.
But looking past my situation, is building only modular behaviors the right path? Apparently, Marionette gives the users the freedom to use behaviors as they see fit but should we build a behavior even if its used only once?
Marionette behaviors are a way to extract reusable behavior from a view and then reuse it where needed, just like The Pax Bisonica writes. Although there are definitely good reasons for choosing to abstract your functionality into behaviors even if they will not be reused in other views, instead of building specific non-reusable views or to simply inherit view C from view B, and view B from view A etc.
As an example, let's say we want to have a custom view (C), acting very specifically. That view has x things in common with two other views, so we'll create a new view (B), based on a BaseView class (A), that has the common behavior. Then extend that view to create the custom view we were after (C).
This 'class' inheritance can get quite messy especially as the app grows. Behaviors let's you abstract the functionality to attachable objects instead. With the class inheritance approach, we would have only one initialize method, so if our behavior needs to add listeners etc. in the initialize method then we'd have to change the view right from the beginning.
A behavior is a specific purpose compartmentized which is generally a good way to go, whether you will reuse it later or not, because it's easier to understand, refactor and read.
So yes - I'd recommend you to use behaviors as much as you feel makes sense, even if the behaviors will turn out quite specific and in the end will not need to be reused, if only to keep your views leaner.
Related
Is it advisable to use angular with atomic design?
"A lot has been said about creating design systems, and much of it focuses on establishing foundations for color, typography, grids, texture and the like. This type of thinking is certainly important, but I’m slightly less interested in these aspects of design because ultimately they are and will always be subjective. Lately I’ve been more interested in what our interfaces are comprised of and how we can construct design systems in a more methodical way", Brad Frost.
Due it's component based architecture, it is very easy to achieve Atomic Design in Angular. In fact, some of the Angular best-practices that encourage reuse, maintainability and componentization fit naturally into the Atomic Design paradigm.
Here is how parallels can be drawn between Atomic Design and Angular.
The quoted definitions are taken from the "official source": http://atomicdesign.bradfrost.com/chapter-2/
Atoms
[A]toms include basic HTML elements like form labels, inputs,
buttons, and others that can’t be broken down any further
without ceasing to be functional.
In Angular, you will make use the basic HTML elements, like the ones listed in the quote above, in your component templates.
Molecules
[M]olecules are relatively simple groups of UI elements functioning
together as a unit
Angular best-practices encourage creation of small components that can be reused across the application (or even shared with different applications). If you look at the Angular Material component library, there many examples of premade components, which can be considered "molecules" in Atomic Design.
Organisms
Organisms are relatively complex UI components composed of groups of
molecules and/or atoms and/or other organisms.
In your Angular application you will often have reusable containers or components. Page headers and footers, navigation menus, product preview boxes, etc. are some examples. Those container are made up of smaller components ("molecules"), and are re-used across the application (or even several applications).
Templates
Templates are page-level objects that place components into a layout
and articulate the design’s underlying content structure.
The definition above, with some minor edits, could as-well be something describing Angular's template system. To create the pages, you place your components ("organisms", "molecules", "atoms") to create the structure of a page.
Pages
Pages are specific instances of templates that show what a UI looks
like with real representative content in place.
This is essentially the rendered output of Angular component templates in the browser - the final product of an Angular project so to say.
As you can see, the Atomic Design can be applied to an Angular project. Moreover, there is a lot of overlap between Angular's component architecture and Atomic Design.
I know it is bad practice to have the DOM manipulation in anywhere other than directive. but I do not understand why is it a bad practice to have the DOM manipulation in the service/factory as we can reuse them.
I have searched online and also found the same question on stackoverflow
stackoverflow question
but still not clear with the answers.
Angular follows declarative principle which means
a style of building the structure and elements of computer
programs—that expresses the logic of a computation without describing
its control flow
At the same time services in angular were introduced to contain business logic. If business flow is complex - imperative approach suites better.
In such a way if you have DOM manipulation in the service you probably violate separation of concerns principle, as you are coupling UI and business layers. And coupling itself eventually ends up in spagetti-code when this "reusable" components (according to new requirements) should look a bit different in the modules where they were integrated
Directives, by definition, are always attached to a DOM node. So when we create a directive, it either expands or replaces the DOM node.
services are engaged with directives so we are able to manipulate view of an app through directives. however, there are cases where you might need to manipulate DOM element(s) via a service, like in a modal window.
I have a rule of thumb for situations like this. can DOM manipulation be done directly with the attached node? and answer to this question tells me if I need to use a directive (yes) or a service (no) but overall it depends on complexity of your project as well.
Could anyone explain me what is the pourpuse of create new modules in angularjs application, I have already read the documentation, but we are not quite sure about when is appropiate to create a new module or use our own application module when you create a new service, directive, etc..
I would like to add some thoughts after reading a bit more about the subject:
JAndy, you are right in the general concept, but to be more specific in when do you have to use angularjs modules I think I got a clear answer in this post
Basically we have 3 ways of structuring our angularjs projects:
angular-seed
Yeoman
Structure the project in Modules
Depending of how big is your project you can take one aproach or another.
Basically writing new modules in angularjs helps you to pack functionalities that are related, one of the advantages of this approach is if a new developer comes into your team he can get a general overview and find things easier than if you only have one module, another one is to reuse functionality accross other projects.
I'd like to answer this question in a more general style than being specific.
Why was the ISS not build as one gigantic station instead of multiple independent modules ? The reason behind modules is to separate responsibilities, decouple a construction, etc. In terms of programming it means to have logic, spread over multiple small modules. That way, you not only know exactly where to look if anything goes wrong or you need to extend some functionality, it'll also guarantee that your whole ISS( your application ) will not entirely fail if one of your modules fails. This of course, also requires certain aspects of
programming styles, most important in this context, to hold module interaction and communication loosely coupled (which I just assume).
So whenever you want to implement new stuff, which does not fit in any other existent code or module, you should create a new, independent module, which is specialized to fulfill a certain task.
Even if I'm not using AngularJS on regular bases, I'm sure the same idea of modularization will fit in there.
I have up to 63 elements that get updated when one changes, do I need a View for each one?
What is the correct way to handle this?
I have a tree structure in my html, where nodes are related to other nodes at different levels.
I wrote js code to handle checking and updating, but that was pre-backbone. I can write the code, I just don't know if I need a different view for each element and what the best practice is.
Each view in Backbone is an abstraction of an visual interface unit, backed by business data(model/collection). Wrapping each responsive element as a view is possible, but rarely the best decision, for that generally means the granularity of abstraction is too fine, which may cause the degradation of efficiency and maintainability.
To effectively benefit from Backbone, designer should think in a big picture first. Many people tend to design/write static HTML code first, then inject dynamic JavaScript later. I don't think that's a good approach. It's better to partition your complex system into several relatively simple and well-defined modules, wrapping visual parts into views and business data parts into models/collections. As for DOM elements, they are just (views') implementation details and will naturally follow the definition of views.
To sum up, rather than decide how to map pre-existing DOM elements with views, decide how to implement pre-designed views with DOM elements.
I am looking to do some granular control on what happens to each view based on user interaction. In addition, what happens to each view also depends on what other views are currently doing, thus the need to keep all views in one array. Based on the simple examples I find online, the controller seems to be intended to manage sets of models? Currently, I am extending the concept to views by have a 'viewController' of sort. This solution doesn't appear egregious to me although I am not really sure.
Please note though, this appears to be a very general question since there's no one right answer, and what is right is different in each case. However, keeping in mind of Ember's opinionated ways, I am simply asking if the people making Ember had one particular way in mind that I have yet been clued to, and build Ember so that this 'one way' has the most functionalities.
The primary responsibility of controllers in Ember apps are to present data to the view to render.
A good solution for managing dynamic collections of views is to subclass Ember.ContainerView and have it update it's childViews property in response to properties changing on the controller. You can look at the source code for Ember.CollectionView for an example.
I did a talk where I've laid out the responsibilities of the various classes of objects in Ember apps and how they work together. You can check it out here: http://www.lukemelia.com/blog/archives/2012/08/23/architecting-ember-js-apps/