Scribd
Upload
79 views

Angular Best Practices 20180412

The document outlines several Angular best practices for application architecture, code organization, and coding standards. It recommends splitting applications into core, shared, and feature modules. It provides guidelines for organizing imports, file structure, naming conventions, single responsibility components, and proper use of lifecycle hooks. It also details best practices for TypeScript, JavaScript, HTML, CSS/Sass coding.

Uploaded by

vicvaldon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
79 views

Angular Best Practices 20180412

The document outlines several Angular best practices for application architecture, code organization, and coding standards. It recommends splitting applications into core, shared, and feature modules. It provides guidelines for organizing imports, file structure, naming conventions, single responsibility components, and proper use of lifecycle hooks. It also details best practices for TypeScript, JavaScript, HTML, CSS/Sass coding.

Uploaded by

vicvaldon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 33

Angular

Best Practices
Architecture
• Split application into at least three different modules:
• CoreModule
• All services which have to have one and only one instance per application
• Includes: Singleton services such as user service, authentication service
• SharedModule
• All the “dumb” components and pipes
• Doesn’t have any dependency to the rest of the application.
• FeatureModule(s)
• Multiple feature modules for every independent feature
• Feature modules should only import services from CoreModule
Aliases
• Use aliases for cleaner imports
Aliases
• Add baseUrl and paths properties to our tsconfig.json file
Organize Imports
• Arrange your imports based on scope
1. 3rd party libraries
2. Globally accessible app code (in every feature module)
3. Locally accessible feature module code, always use relative path
Organize Imports
• Member sequence
• Properties up top followed by methods.
• Private members after public members, alphabetized
Relative path: ./<path>
• A component relative URL requires no change when you move the
component files, as long as the files stay together.
Use Sass
• Use a style preprocessor to save your
life
• Allows you to use variables, functions,
mixins
Single responsibility
• Make the code more reusable, easier to read, and less mistake prone
• How:
• One component per file
• Small functions as a primary means of abstraction
• Extract templates and styles into a separate file, when more than 3 lines.
ßAvoid
ßPrefer
Consistency
• File structure conventions
• Naming: feature.type.ts

• Try not to abbreviate. Be descriptive and unambiguous


Consistency
• Use a consistent and predictable style files
• UpperCamelCase for classes (i.e. components, services and pipes definitions)
• lowerCamelCase for variables, function names, class instances, directive
selectors, property bindings, event bindings, template variables and template
element attributes
• lower-kebab-case for component selectors, CSS classes
Logic
• Templates
• View structure only

• Components (I will do it for you)


• View manipulation, presentation logic
• Subscriptions to Observables

• Services (Let me do it for you)


• Processes which are long-running or may take time
• Complex logic
• “Data massagers”
• Shared methods or state
Lifecycle Hooks
• Implement the lifecycle hook interfaces correctly
• Do not misspell
• Make sure to add `implements` on class declaration
Lifecycle Hooks
• Use ngDoCheck() as a last resort. Use ngOnChanges() for variables
with @Input decorator
• Unsubscribe and dispose your subscriptions in ngOnDestroy() to
prevent memory leaks.
• Use lifecycle hooks instead of defining setTimeout()
Classes vs Interfaces
Classes vs Interfaces
Use classes…
• When? You need custom logic initialization
• Why? A class alone is less code than a class-plus-interface
• Why? A class can act as an interface
• But…
Coding Standards: JavaScript
• Use strict comparison operators: "===" and "!==" instead of "==" and
"!="
• Use let or const vs var
• Avoid nested if statements
Coding Standards: JavaScript
• Use for-of loop over elements of an array
Coding Standards: JavaScript
• forEach()
• + Shorter than for loop
• - Can’t break out of this loop using a break statement or return
• for-in
• Index in this code are the strings "0", "1", "2"
• Designed to work on plain old Objects with string keys. Not so great with Arrays
• for-of
• Avoids pitfalls of for-in
• Unlike forEach(), it works with break, continue, and return!
• Works on most array-like objects, like DOM NodeLists, Maps, Sets
• Does not work with plain old Objects
Coding Standards: JavaScript
• Passing arguments to a
function
Coding Standards: JavaScript
• Use ES5 iterators
• every (stops looping the first time the iterator returns false or something
falsey)
• some (stops looping the first time the iterator returns true or something
truthy)
• filter (creates a new array including elements where the filter function
returns true and omitting the ones where it returns false)
• map (creates a new array from the values returned by the iterator function)
• reduce (builds up a value by repeated calling the iterator, passing in previous
values; see the spec for the details; useful for summing the contents of an
array and many other things)
• reduceRight (like reduce, but works in descending rather than ascending
order)
Coding Standards: TypeScript
• Declare data types
• If no data type is available, create custom models for them.
• Not only on variables but also for functions
• Why? It catches data structure mismatch early (i.e. during development)
Coding Standards: Angular
• When declaring
component inputs
and outputs, prefer
the decorator
version
Coding Standards: Angular
• Never use two Angular directives in one element
• Use ng-container and/or ng-template instead of adding another div
Coding Standards: HTML
• Avoid putting logic in templates. Use functions instead to return
evaluated values
• Do not use inline styles
• Use HTML5 semantic elements
Coding Standards: S/CSS
• Create custom scss files to override 3rd party base styles
• Use classes over IDs as selectors
• Create variables for values
• Never nest styles more than 3 levels deep.
• Do not use !important
• Ensure cross-browser compatibility

You might also like