# AngularJS - components

# I - guides

Jun 3, 2016

$onInit
Using $onInit

$onInit + “require”

Real world $onInit + “require”

$postLink
Using $postLink

Real world $postLink

What $postLink is not

$onChanges
What calls $onChanges?

Using $onChanges

Cloning “change” hashes for “immutable” bindings

One-way dataflow + events

Is two-way binding through “=” syntax dead?

Using isFirstChange()

$onDestroy
Using $onDestroy

One-way data-binding in Angular 1.5 : toddmotto.com

With a parent / child relation ship between component where the parent pass data to the child, it is the practice of binding uni-directionnal instead of bi-directionnal.

bi-directionnal (two way) is bindings: { obj: '=' } uni-directionnal (one way) is bindings: { obj: '<' }

Using one way binding break the link with the parent scope. So the child cannot mutate the parent state.

/!\ If an object reference is bound to the child from the parent, if the child mutate a property it will work like two way binding.

Another way to exprime difference between two-way and one-way bindings is :

One way binding is binding the data from the model to the view.

Two way binding is binding the data from the model to the view and the view to the model. (Also called MVVM)

# II - best practices

# A - Todd Motto best practices

Todd Motto best practices

one-way data flow
- data goes from the top level component to the lower levels.
- child components modifications on bindings doesn't reflect on parents components.
- callback function are used to handle events, they are used to update the parents components data modified by children.
stateful components
- referred to as smart/container components
- how things work
- fetches state (through API, so no bindings)
- does not directly mutate state
- renders child components that mutate state
- the classic case is a view component for example an entity list
stateless components
- referred to as dumb/presentational components
- how things look
- has defined inputs and outputs using bindings: {}
- data enters the component through attribute bindings (inputs)
- data leaves the component through events (outputs)
- mutates state, passes data back up on-demand (such as a click or submit event)
- doesn't care where data comes from - it's stateless
- are highly reusable components

So TLDR is :

the webapp is a tree of components
theses components are stateful or stateless
views are stateful
stateful components fetches and store data (it is the state)
stateful components are an aggregation of stateless components
stateless components renders data only, so they are reusables

See section component design section in inter-component communication part for this design flaws.

# B - Components types

The 3 component categories in Angular

Presentational and Container Components : Dan Abramov (ReactJS team, Redux author)

View Components (or Routing components) (or Stateful components for Todd Motto)
Container Components (or Smart components) (or Stateful components for Todd Motto)
Dumb Components (or Stateless components for Todd Motto)

Responsabilities table

Responsabilities per component	View Comp.	Container Comp.	Dumb Comp.
Read route parameters	YES	NO	NO
Uses stores and data services	NO	YES	NO
Display and styling	NO	NO	YES

# III - feedback

# A - NG 1.5 from the trenches at velesin.io

1/7 Starting a new app in Angular 1.5 – does it make sense?
2/7 Angular 1.5 app as a tree of components
3/7 Communication between Angular 1.5 components (and with the API)
4/7 A flexible Angular 1.5 project structure (the "fractal" architecture)
5/7 Writing Angular 1.5 project in ES6/ES2015
6/7 Unit testing Angular 1.5 components – a detailed guide
7/7 E2E testing of component-oriented Angular 1.5 app [COMING SOON]

# IV - inter-component communication

# A - angular 2 parent & child communication via service

Parent and children communicate via a service : angular.io

# B - practices overview

src Angular 1.5. Components communication. Best practice : stackoverflow.com

I'm using Angular 1.5.9.

Right now I have two components which need to communicate. If I change something in the first one (for example choose item in the list) => second one needs to be changed (item that was chosen needs to be displayed) and vice versa (changing in the second one => change in the first one) I have read about a lot of approaches, so I can manage this in few ways:

Communication via shareable Service

Using two way data binding ("=" option in component bindings). Example

Using one way data binding with input/output approach. Example

Using "require" (some parent component to share data). Example

Maybe I miss something? What is the best practice?

Thank you.