Downloaded 17 times
![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](https://image.slidesharecdn.com/buildingmodularenterprisescaleangularjsapplications-151102024709-lva1-app6892/75/Building-modular-enterprise-scale-angular-js-applications-33-2048.jpg)
![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](https://image.slidesharecdn.com/buildingmodularenterprisescaleangularjsapplications-151102024709-lva1-app6892/75/Building-modular-enterprise-scale-angular-js-applications-51-2048.jpg)
![[Y001] - One component per file Code Consistency ● Export a single AngularJS function Benefits ● Small focused functionality ● Maintenance / readability ● Debugging ● Portability](https://image.slidesharecdn.com/buildingmodularenterprisescaleangularjsapplications-151102024709-lva1-app6892/75/Building-modular-enterprise-scale-angular-js-applications-52-2048.jpg)
![[Y001] - One component per file Code Consistency ● Export a single AngularJS function Benefits ● Small focused functionality ● Maintenance / readability ● Debugging ● Portability](https://image.slidesharecdn.com/buildingmodularenterprisescaleangularjsapplications-151102024709-lva1-app6892/75/Building-modular-enterprise-scale-angular-js-applications-53-2048.jpg)
Uploaded byJonathan Fontanez
Building modular enterprise scale angular js applications
This document discusses designing modular AngularJS applications. It recommends structuring components based on features rather than AngularJS functions for scalability. Components should be loaded automatically using CommonJS and testing should be done by importing components. Components can be extended and packaged as independent npm modules for distribution, versioning, and maintenance. Future enhancements may involve AngularJS2 and ES6.
Building modular enterprise scale angular js applications
- 1. Building modular enterprise scaleAngularJS applications Jonathan Fontanez @jonfontanez
- 2. Topics Modularity Architecture Problem statement Designing modular AngularJSproject Extending Packaging Maintaining Future
- 3.
- 7. “The degree towhich a system’s components may be separated and recombined” - wikipedia
- 8. Node Modules ClientModules
- 9. Expectations ● Small modularpieces ● Loosely coupled ● Highly cohesive ● Easily modified
- 10. Reality Modular pieces Not wellintegrated Difficult to locate and append modules
- 11.
- 12. Straight from theAngularJS docs!
- 13. Key Takeaways fromdoc ● Best practice for application structure ● AngularJS styleguide by John Papa (the missing styleguide)
- 15. Problem statement AngularJS providesan MVVM framework. It does not natively include the capability to build scalable and maintainable software
- 16.
- 18. Designing a Googlelike API explorer Working example available on github.com/tato123/angular-modules-presentation
- 20. ● Built withGWT ● Browse rest services and their operations ● Extensible Things to note
- 21. ● List services BrowseServices
- 22. ● List services ●Register a set of APIs Browse Services
- 23. ● List operationsfor a given service Browse Operations
- 24. ● List operationsfor 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 anAngularJS 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 sampleapplications focus on grouping by functionality Controller Services Views etc…
- 28. Structuring components AngularJS sampleapplications 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 functionbased 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.
- 33. Structuring components LIFT [STYLEY140] 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 maincomponent browse service browse logic operations operations browse logic registry provider to register services api-foo mock service
- 36. Structuring Components ● Flatdirectory structure ● Names represent feature ● Nothing angular so far ● No file name dependency ● Identifies content ● Features encapsulated
- 37. Value from structuredfeatures Loading Components
- 38.
- 39.
- 40. Loading Components ● index.htmlmerge 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 dowe want?
- 42. Loading Components ● Reducemerge 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 ● Supportsnpm modules ● Supports our features
- 44.
- 45.
- 46.
- 47.
- 48. Loading Components Remember thatpesky index.html...
- 49.
- 50.
- 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] - Onecomponent per file Code Consistency ● Export a single AngularJS function Benefits ● Small focused functionality ● Maintenance / readability ● Debugging ● Portability
- 53. [Y001] - Onecomponent per file Code Consistency ● Export a single AngularJS function Benefits ● Small focused functionality ● Maintenance / readability ● Debugging ● Portability
- 54. Code Consistency Registry ● AngularJSProvider ● Allows services to dynamically register ● CommonJS export
- 55. Significantly easier withmodules 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 Considerco-locating your test or spec files with each of your components
- 58.
- 59. Extending Packaging ● Components representisolated 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 npmmodule package.json component B my-new-module
- 61. Extending Packaging ● Pull inmodules from local and remote repositories (i.e. artifactory) ● Independent testing as modules ● Support distributed development ● Independent versioning Benefits
- 62. Extending Maintenance and versioning ● Separationof core and supporting modules ○ Independently testable ○ Independently versioned ● Focus on smaller concise modules Benefits
- 63. Extending ● Export anew api service ● Plain npm module Adding a new API
- 64. Extending APP Core Source node_modules echoapi CommonJS
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.