AngularJS to Angular:

Setting the Stage

Application State

• 5-6 UI developers
• Medical application
• Very dynamic, lots of configuration flags
• Deployed in customer environments
• Customer support / new features still required
• Automated Selenium tests validating logic
• Supports: IE11, FF, Chrome, iOS

Code History

• Originally built in Dojo Toolkit
• Ported to AngularJS (early 1.x)
• Minimal usage of 1.5 components
• $scope soup
• Accessible
• Translated into several languages
• Right-to-left language support

Tech/Tooling Stack

• AngularJS 1.5
• JSPM dependency management and packaging
• Custom Gulp builds
• Data provided by REST APIs
• Heavy bootstrap usage

Justifying the Conversion

Justify to the Business

• What is the value of converting?
• What are we sacrificing by converting?
• How long is this going to take?

Justify to the Business

• Everyone else is using this technology
• It will be good on my resume
• Want to try out something I just learned

Our Value Justification

• New UX flow
• New branding
• Built with application's future in mind
• Lower maintenance cost
• Pilot tech base for future products
• Sacrifices:
• Some bugs only fixed in new UX
• Limit features development in old UX

Our Plan

• Estimate: 5-6 months
• Install side-by-side with old UI
• Won't disrupt other parts of project
• UX Research
• Compare behaviors
• Angular 4 (was just released at the time)

In Place or Rewrite?

Over Promising

• Realistic expectations
• Learning
• Vacations
• Maintain existing product
• Mistakes - "learning opportunities"
• Unexpected complications

Learn / Education

Learn

• Important to spend time to learn framework
• Started with a few team members
• Share summary of learning with team
• Follow best practices (style guide)
• Learn potential pitfalls

Mob Programming

• Work as a team on a single function at same time
• Different developer 'drives' each meeting
• Learning opportunity for knowledge sharing
• Start finding potential issues right away
• 3+ times each week initially

Frontend Masters

Safari Books Online

• Books
• Video training
• Online workshops

Pluralsight / Udemy

Identifying Dependencies

Process

1. Define all 1.x dependencies
2. Are there Angular versions?
3. Validate in dependency test app

Dependency Test App

• No frills app to test libraries
• Inject all dependencies at same time
• Validate use cases
• Test AoT build

Package Checklist

• Use case validation
• IE11, FF, Chrome, iOS
• Accessibility
• Right-to-left support
• Translation support
• Acceptable license
• Works in AoT build
• Issues, contributors, activity

Reuse

Identify Potential 1.x Reuse

• Services
• Filters
• Directives
• Some controller functions
• Translations

Reusing Code

• Migrate as needed; get rid of dead code
• Update to 2+ syntax
• Update injected services
• Add types
• Decide between Promises / Observables
• Fight urge to rewrite logic

Library Projects

Library Projects

• Two libraries shared for future projects
• Publish packages via internal NPM registry
• Versioned via semver (major.minor.fix)
• Custom build for Angular package format
• Gulp
• tsc
• Rollup

Suggestion: Use angular-cli

							ng generate library my-lib

							ng build my-lib
						

API Package

• Common data used across several products
• Package contains shared:
• Services
• Interfaces / models
• Views (complex components)

Component Library

• New UX/design requiring custom styling
• Includes demo application
• Generated doc with compodoc (via JSDoc)
• Supports: right-to-left, accessibility, translation
• Source is mix of:
• Custom developed source
• Wrappers around open source

Versioning

• semver criteria
• Automatic releases via semantic-release
• Every commit/merge triggers release
• Application locks major.minor when preparing release
• Release branches only when critical issue and version advanced too far

Tooling/Process Change

Tooling/Process Change

• Source control
• Builds
• Code reviews
• Standups
• Technical meetings
• Demos

Source Control

• Better code review tooling
• More efficiently able to collaborate
• GitHub is company's direction
• Act as pilot for other projects
• Keep team up to date with industry

Builds

• Automatic branch builds
• Concurrent builds
• More developer focused
• Integration with GitHub Enterprise

Code Reviews

• Helps educate each other on Angular
• No one can push to master
• Approved PRs enforced by GitHub
• Slack channel to consolidate open PRs
• Daily Slackbot reminders

Standups

• Critical to success; need communication
• Decentralized team (3 locations)
• Standups often turned into long discussions
• Moved standup to Slack vs. phone
• Slackbot reminder at 9am for status

							/remind #channel at 9am every weekday "@here STANDUP!  Use this format:
							Y:
							> - What you did yesterday
							T:
							> - What you doing today
							B: Blockers
							"
						

Daily Technical Meetings

• Communication / sharing important
• Daily meeting for:
• Education topics
• Code walkthroughs
• Mob programming
• Planning

Demos

• Need feedback from stakeholders (new UX)
• Weekly Friday demos
• Create work items for each action
• Schedule followup discussions if needed

Pitfall:
Differing Developer Styles

Problem

• Developers have code style preferences
• Commit messages are inconsistent
• No established styles on team
• When fixing defects, often unnecessary changes made due to style
• Makes diffs very difficult to parse

Solution: Tooling

• Prettier: consistent file formatting
• commitlint: strict format for commit message
• Strict TSlint rules: Enforce team establish practices

Configuration

							// package.json
							{
							  "husky": {
							    "hooks": {
							      "pre-commit": "lint-staged",
							      "commitmsg": "commitlint -e $GIT_PARAMS"
							    }
							  },
							  "lint-staged": {
							    "*.{ts,js,json,scss}": ["prettier --write", "git add"],
							    "*.ts": ["tslint"]
							  }
							}
						

							// commitlint.config.js
							module.exports = { extends: ['@commitlint/config-conventional'] };
						

Example

Interesting TSLint Rules

Pitfall:
OnPush Change Detection

Problem

• Default change detection (CD) strategy doesn't always scale well
• Some event listers may trigger a lot of CD
• Expensive function impls will slow down CD
• Demo:
• Every mouse event is triggering CD to run
• Expensive function being called every time

Solution

• Use ChangeDetectionStrategy.OnPush
• Inject ChangeDetectorRef and manually execute CD if needed
• Treat @Input values as immutable
• Demo:
• OnPush prevents calculated-value from being re-rendered
• Ideally, OnPush should be applied everywhere

Pitfall:
Not Unsubscribing

Problem

• Very easy mistake to make
• Not always clear when unsubscribe is required
• Causes memory leaks
• Possible extra change detection cycles
• May trigger unnecessary code to run
• Unpredictable state changes

Solution

• Memory profiling to find leaks
• Utilize async pipe more often
• Auto unsubscribes
• Renders again when appropriate
• Ensure subscription is completed:
• .take(xx) completes observable
• .unsubscribe()

Pitfall:
Trying to do everything the "Angular" way

Problem

• Angular has a lot of abstraction layers
• Often frustrating/annoying to understand abstraction
• Harder for non-Angular developers to understand
• Several discussions on we should be using Angular

Solution

• Decided to use abstractions when it makes sense
• @HostListener, some Renderer2
• Just use window natively
• Ignore difficult to use abstractions
• Team knew we wouldn't be server side rendering
• Things became more simple when we didn't need to look it all up