Building modular enterprise scale angular js applications

1. Building modular enterprise
scale AngularJS applications
Jonathan Fontanez
@jonfontanez

2. Topics
Modularity
Architecture
Problem statement
Designing modular
AngularJS project
Extending
Packaging
Maintaining
Future

3. Why?

7. “The degree to which a system’s
components may be separated and
recombined”
- wikipedia

8. Node Modules Client Modules

9. Expectations
● Small modular pieces
● Loosely coupled
● Highly cohesive
● Easily modified

10. Reality
Modular pieces
Not well integrated
Difficult to locate and
append modules

11. What happened?

12. Straight from the AngularJS docs!

13. Key Takeaways from doc
● Best practice for application structure
● AngularJS styleguide by John Papa (the missing
styleguide)

15. Problem statement
AngularJS provides an MVVM framework. It does
not natively include the capability to build scalable
and maintainable software

16. Getting Started

18. Designing a Google like API explorer
Working example available on github.com/tato123/angular-modules-presentation

20. ● Built with GWT
● Browse rest services
and their operations
● Extensible
Things to note

21. ● List services
Browse Services

22. ● List services
● Register a set of APIs
Browse Services

23. ● List operations for a given service
Browse Operations

24. ● List operations for a given service
● Register operations for a given service
Browse Operations

25. What are our
steps?
● Structure
● Loading Components
● Code Consistency
● Testing
● Extending

26. Definitions
Component Encapsulates an AngularJS feature, defined as a unit of work that exposes a UI segment
or common utility functions exposed as a service. Manifestation of a feature
Feature Logical unit, a feature is implemented as a component (feature is the thought,
component is the representation)
Module In the context of AngularJS, a module can represent a single component or a collection
of components that provide a business function

27. Structuring components
AngularJS sample applications focus on grouping by
functionality
Controller
Services
Views
etc…

28. Structuring components
AngularJS sample applications focus on grouping
functionality
Controller
Services
Views
etc…
Great for getting started!

29. Function based structure
● Foo and bar features
● Separated by AngularJS
functionality
● Consistent naming

30. Function based structure
● Foo and bar features
● Separated by AngularJS
functionality
● Consistent naming
Challenging to scale past 4 or 5 modules

31. Problems with function based structures
● Dependent on implied coding conventions
○ Must name each feature file consistently
○ Requires concise naming up front
● Features exist only as a function of AngularJS
● Determining test coverage of an independent feature is challenging

32. Feature based structure

33. Structuring components
LIFT [STYLE Y140]
Locating our code is easy
Identify code at a glance
Flat structure as long as we can
Try to stay DRY (Don’t Repeat Yourself) or T-DRY

34. Feature based structure
● Foo and bar modules
● Feature based
● Flat structure
● No reliance on file names
● Consistent with node
projects

35. Structuring Components
app
application main component
browse
service browse logic
operations
operations browse logic
registry
provider to register services
api-foo
mock service

36. Structuring Components
● Flat directory structure
● Names represent feature
● Nothing angular so far
● No file name dependency
● Identifies content
● Features encapsulated

37. Value from structured features
Loading
Components

38. Loading Components

39. Loading Components
Script loading hell

40. Loading Components
● index.html merge conflict when working in distributed
environments
● declares the universe of scripts, not specifically what your
application is actually using
● does not tie back to components
● duplicated when unit testing using tools like Karma

41. Loading Components
What do we want?

42. Loading Components
● Reduce merge conflicts on index.html
● Use the component structure already present in our app
● Declare our dependencies
● Have it done automatically
○ Let the build tools manage it!!
What do we want?

43. ● CommonJS
● Supports npm modules
● Supports our features

44. Loading Components
app
operationsbrowse api-foo registry

45. Loading Components

46. Loading Components

47. Loading Components

48. Loading Components
Remember that pesky index.html...

49. Loading Components

50. Writing clean functionality
Code
Consistency

51. Code Consistency
[Y001] - One component per file
[Y020] - Avoid naming collisions
[Y024] - Use named instead of anonymous functions
Just a small list, implement the John Papa code style
guidelines

52. [Y001] - One component per file
Code Consistency
● Export a single AngularJS
function
Benefits
● Small focused functionality
● Maintenance / readability
● Debugging
● Portability

53. [Y001] - One component per file
Code Consistency
● Export a single AngularJS
function
Benefits
● Small focused functionality
● Maintenance / readability
● Debugging
● Portability

54. Code Consistency
Registry
● AngularJS Provider
● Allows services to dynamically
register
● CommonJS export

55. Significantly easier with modules
Testing
Components

56. Testing Components
Test Configuration
● Single import, same as index.html
● Components synchronized (app
and unit test)
Note
Bring your own test tools, doesn’t have
to be Karma or Jasmine

57. Testing Components
Optional Tip
Consider co-locating your test or spec files with each of your components

58. Extending
Modular components

59. Extending
Packaging
● Components represent isolated pieces of
functionality
● Components are loosely coupled
● Components in CommonJS syntax already
(npm ready)
● Browserify supports npm modules
What we’ve got so far

60. Extending
Packaging
Building a module
component
A
npm module package.json
component
B
my-new-module

61. Extending
Packaging
● Pull in modules from local and remote
repositories (i.e. artifactory)
● Independent testing as modules
● Support distributed development
● Independent versioning
Benefits

62. Extending
Maintenance and
versioning
● Separation of core and supporting modules
○ Independently testable
○ Independently versioned
● Focus on smaller concise modules
Benefits

63. Extending
● Export a new api service
● Plain npm module
Adding a new API

64. Extending
APP
Core Source node_modules
echo api
CommonJS

65. Extending

66. Extending

67. Extending

68. Extending

69. Extending

70. Extending

71. Future
AngularJS2 and ES6

72. Resources
Twitter
@jonfontanez
Github
github.com/tato123