<web/F>

Structuring with Angular A first step toward maintainability

<web/F> <web/F>

Why is structuring important ?

• Maintainability

• Scalability

• Easy Debugging

<web/F> <web/F>

Techniques to structure Angular apps

• Tradition MVC structure

• Scaffolding tool like Yeoman

• Angular Seed

• DIY – Do it yourself

• Custom structure

<web/F> <web/F>

Angular with MVC Structuring angular app with MVC analogy

<web/F> <web/F>

Traditional MVC

C

M

V

<web/F> <web/F>

Traditional MVC

• Ill suited for Angular MVC

• Again, Angular is not really MVC

• It is not even MV*

• It is just V**

<web/F> <web/F>

Problems with traditional MVC

• Hard to find factories, services & directive

• Services/factories becomes models

• Directives are inside others

• Too flattened architecture leads to long files in

a single folder.

<web/F> <web/F>

Immediate improvement is Angularly MVC

<web/F> <web/F>

Angularly MVC

<web/F> <web/F>

Improved but still…

• Still too flattened

• Third party libraries

• Model/service distinction

<web/F> <web/F>

Scaffolding tools Using yeoman angular generator

<web/F> <web/F>

Yeoman generator

• Node based scaffolding tool

• Just do

• npm install -g bower yo generator-angular

• yo angular

• One of the fastest way to get started

• Quite popular ~ 4000 GitHub stars

<web/F> <web/F>

Yeoman generated structure

<web/F> <web/F>

Yeoman generated structure

• 3 major components of web are scripts, html

templates and styles.

• Yeoman makes separation of these

components

• Additionally it sets up the grunt task runner,

package manager and karma test runner

<web/F> <web/F>

Yeoman – positives and negatives

• Super easy to setup end to end workflow

• Task runner, test runner, package manager

• Good for small but may not scale for all the

applications especially larger once

• Suffers from shotgun surgery syndrome

• Changes at multiple places

<web/F> <web/F>

Angular seed Literally a seed for thousands of angular projects

<web/F> <web/F>

Angular seed

• Similar to yeoman

• Sets up Task runner, test runner, package manager

• Hugely popular

• ~10,000 GitHub stars

<web/F> <web/F>

Angular seed

• Again V** implementation

• Idea of components

• Ambiguous definition of components

• Tests combined with Sources

• Testing related code should be separate

• Shotgun surgery syndrome exists

<web/F> <web/F>

Angular seed is redefined further

<web/F> <web/F>

Shared code base structure

• Complex but quite scalable

• App divided into three parts

• Assets

• Shared

• Components

<web/F> <web/F>

Shared code base structure

• But still some semantic issues

• Idea of components

• Is it module/Web

Component/service/factory/directive?

• Is it business/functional component?

• How component inside component?

• Doesn’t speak well for cascaded modules

<web/F> <web/F>

DIY – Do it yourself Build your own structure

<web/F> <web/F>

Your own structure

We need better folder structure

Because folder structure decides if we can scale our

code base

<web/F> <web/F>

What we need

• Semantically accurate

• Encourage parallel development

• Reduce subversion conflicts

• Loosely coupled yet centralized control

• Support angular module cascade

<web/F> <web/F>

Store pattern (Rich object model pattern)

S

E

R

V

E

R

C

L

I

E

N

T

VIE

WS

CO

NTR

OLL

ERS

STORES FA

CTO

RIE

S (F

AC

AD

E)

Entities Services (Logic less)

<web/F> <web/F>

Scalable structure – top view

• vendor/node_modules/bower_components for third party

• src – for all the source code

• dist – deployable output of build step (grunt, gulp, npm, etc.)

• test – for unit testing & end to end.

<web/F> <web/F>

Scalable structure – test & vendor

• Inside test

• unit for unit testing

• e-2-e for automation (protractor or

selenium)

• Vendor

• Some custom code that doesn’t fit into

source

<web/F> <web/F>

Scalable structure – src

• Only code that you own/write

• commons for come common stuff

• CSS/Less/Scss for stylesheet

• (color palette, common classes & styles)

• js for some other common js

• directive for directives

• api-factories/factories for angular factories

• services for Angular services

<web/F> <web/F>

Scalable structure – src

• Modules is interesting

• Either mini angular module or some business

view

• Module can contain any other module

(recursion allowed)

• No concept of Chinese-whisper component

• Deliberately avoided

<web/F> <web/F>

Scalable structure – src

• Entities folder

• For domain entities like User

• Plain JS Objects

• Stores folder

• Manage domain entities collection

• Used by controllers of different views/modules

• If need, implement caching

• Provide semantic errors

• Typical CRUD calls around Entities

<web/F> <web/F>

Scalable structure – src

• Factories/api-factories (facades)

• Provide backend/API data to controller

• Handle response inconsistency

• Normalizing response

• Like backend may have “first_name” but on UI, we may

have “firstName” as key

• Handle timeouts & validations (HTTP 409, 422)

• Use ng-resource or $http to get the required data

• Handle network level errors (400, 401, 403)

<web/F> <web/F>

Scalable structure – src

• Services

• Something that are actually services

• Queuing service

• Dialog/notification service

<web/F> <web/F>

Key points

• Controllers never speak to factories/ api-factories

• All logic nested inside stores

• Stores are the most heavyweight components

• Can extended further

• Filters

• Recursive structure

• Separation of Concerns, maintainable and scalable architecture

Direct implication of ROM to avoid Shotgun

Surgery problem

<web/F> <web/F>

Conclusion Ideal folder/application structure is the first step towards

maintainability. If this very foundation is problematic, then anything on

top of it is bound to be problematic.

<web/F> <web/F>

By

Snehal Mhaske

@Snehal_Mhaske

Harshal Patil

@mistyharsh