際際滷

際際滷Share a Scribd company logo
Redux in Angular
Hung Nguyen Huy / Aug 2018
Agenda
1. Introduction
2. Component-based approach
3. Introduction to Redux
4. When to use Redux?
5. Redux Principles
6. Redux Building Blocks
7. Redux in Angular (with Example)
8. Summary
Introduction
Introduction
 State management is absolutely critical in software development.
 One of the hardest aspects of a modern frontend application to get right.
 State is so complicated and use cases differ greatly across different applications.
 There are TONS of ways to manage application state.
 Two of the most popular approaches:
 Component-based approach
 Redux
Component-based approach
Component-based approach
In Angular, React and most of the modern JavaScript frameworks/libs
Components are the primary building blocks of our applications
Advantages of Component-based approach
 Reusability
 Separation of concerns
 Extensibility
 Replaceability
 Reliability
 Keep projects structure Clean and Simple
 ...
Component-based approach
Components are stateful
 Each Component maintain their own state
(properties) and logic (methods) behind the
view (HTML).
 Encapsulation principle in OOP.
What is the PROBLEM?
Case Study - Facebook chat problem
Case Study - Facebook chat problem
Component-based approach
Component-based approach
Problems with Component-based approach
How Components can be updated and communicate
to stay IN SYNC with each others?
Before Redux
Frequently solutions to handle data architecture before Redux:
1. Events
=> Spaghetti code. Hard to manage.
2. Shared Services, through Dependency Injection
=> Unpredictable.
3. Manage state in a stateful parent component
Child components are stateless (just display stuff and dont care about data flow)
Difficult to reuse components.
=> Parent components become really thick.
Refactoring happens so often, and become harder & trickier over time.
Before Redux
Shared Services through DI
Before Redux
Stateful Parent Component
With Redux
Centralized State Container
 Avoid keeping application state in UI
Component itself.
 Instead we can handle it in a Centralized State
Container - the Redux Store.
 Redux is the only one to know data and can
modify it.
With Redux
Components are now framework-agnostic
Introduction to Redux
History of Flux/Redux
 Facebook Messenger problem - 2014
=> Introduce Flux Architecture.
 Redux is simplified and lightweight
implementation of Flux Architecture.
 Redux provides a clean and elegant
solution to the problem.
What is
?
A library that helps you manage the state
of your (large) applications
in a predictable way.
When to use Redux?
When to use Redux?
Use Redux only if youre building a medium-to-large SPA with
complex views and data flow.
When to use Redux?
You may need Redux when your applications have:
 Sophisticated UI and Complex Data flow.
 Independent copies of the same data in multiple places.
 Multiple components that need to work with the same data and must be in sync.
 Data can be updated by multiple actors:
 User actions
 Server responses (Network callbacks)
 Server notifications
Redux Principles
Redux Principles
1. Single source of truth: Store
2. State is read-only
3. Changes are made with pure functions
Source: Redux documentation
Single source of truth
The entire state of the whole application
is stored in one single JS object
within a single Store.
(Since the entire state is represented in a single object,
we are able to keep track of changes over time.)
State is read-only
The only way to change the state is to dispatch an action.
(An action is a plain JS object describing what happened.)
Changes are made with pure functions
To specify how the state is transformed by actions, you write reducers.
(Reducers are pure functions that take the previous state and an action,
and return the next (new) state of the whole application.)
Redux Building Blocks
Redux building blocks
Store
 A Store is a single JS object that contains the state
of the whole application.
 There is only a single Store in a Redux app.
 We can think of the Store as a local client-side
database.
 Different components use different parts of the
state object depending on the functionality.
 Different components can use the same parts of
the state object, we dont have multiple
independent copies.
Actions
 Actions are plan JS objects describing the changes.
 By convention, an Action object must has a type property (String).
 Action objects may have additional properties related to the event just
happened.
 The application state is read-only, and can only be modified by dispatching
Actions to the Store.
Reducer
 Reducer is a PURE function that specifies how the state changes in response to
an Action.
 We can think of Reducer as an actions handler which determines how the state is changed.
 Reducer takes the previous state and the Action being dispatched, and returns
the next state of the whole application.
Reducer does NOT modify the state,
It returns the NEW state.
(Store will internally update the state)
Pure function
 A function is PURE if we give it the same input, we always get the same output. No
matter how many times we call that function.
 It must NOT have any side effects.
Impure function
Pure function
Reducer
Redux Data Flow
Redux Data Flow
Redux in Angular
Redux in Angular
Code Demo
Summary

More Related Content

Redux in Angular 2+

  • 1. Redux in Angular Hung Nguyen Huy / Aug 2018
  • 2. Agenda 1. Introduction 2. Component-based approach 3. Introduction to Redux 4. When to use Redux? 5. Redux Principles 6. Redux Building Blocks 7. Redux in Angular (with Example) 8. Summary
  • 4. Introduction State management is absolutely critical in software development. One of the hardest aspects of a modern frontend application to get right. State is so complicated and use cases differ greatly across different applications. There are TONS of ways to manage application state. Two of the most popular approaches: Component-based approach Redux
  • 6. Component-based approach In Angular, React and most of the modern JavaScript frameworks/libs Components are the primary building blocks of our applications
  • 7. Advantages of Component-based approach Reusability Separation of concerns Extensibility Replaceability Reliability Keep projects structure Clean and Simple ...
  • 8. Component-based approach Components are stateful Each Component maintain their own state (properties) and logic (methods) behind the view (HTML). Encapsulation principle in OOP. What is the PROBLEM?
  • 9. Case Study - Facebook chat problem
  • 10. Case Study - Facebook chat problem
  • 13. Problems with Component-based approach How Components can be updated and communicate to stay IN SYNC with each others?
  • 14. Before Redux Frequently solutions to handle data architecture before Redux: 1. Events => Spaghetti code. Hard to manage. 2. Shared Services, through Dependency Injection => Unpredictable. 3. Manage state in a stateful parent component Child components are stateless (just display stuff and dont care about data flow) Difficult to reuse components. => Parent components become really thick. Refactoring happens so often, and become harder & trickier over time.
  • 17. With Redux Centralized State Container Avoid keeping application state in UI Component itself. Instead we can handle it in a Centralized State Container - the Redux Store. Redux is the only one to know data and can modify it.
  • 18. With Redux Components are now framework-agnostic
  • 20. History of Flux/Redux Facebook Messenger problem - 2014 => Introduce Flux Architecture. Redux is simplified and lightweight implementation of Flux Architecture. Redux provides a clean and elegant solution to the problem.
  • 21. What is ? A library that helps you manage the state of your (large) applications in a predictable way.
  • 22. When to use Redux?
  • 23. When to use Redux? Use Redux only if youre building a medium-to-large SPA with complex views and data flow.
  • 24. When to use Redux? You may need Redux when your applications have: Sophisticated UI and Complex Data flow. Independent copies of the same data in multiple places. Multiple components that need to work with the same data and must be in sync. Data can be updated by multiple actors: User actions Server responses (Network callbacks) Server notifications
  • 26. Redux Principles 1. Single source of truth: Store 2. State is read-only 3. Changes are made with pure functions Source: Redux documentation
  • 27. Single source of truth The entire state of the whole application is stored in one single JS object within a single Store. (Since the entire state is represented in a single object, we are able to keep track of changes over time.)
  • 28. State is read-only The only way to change the state is to dispatch an action. (An action is a plain JS object describing what happened.)
  • 29. Changes are made with pure functions To specify how the state is transformed by actions, you write reducers. (Reducers are pure functions that take the previous state and an action, and return the next (new) state of the whole application.)
  • 32. Store A Store is a single JS object that contains the state of the whole application. There is only a single Store in a Redux app. We can think of the Store as a local client-side database. Different components use different parts of the state object depending on the functionality. Different components can use the same parts of the state object, we dont have multiple independent copies.
  • 33. Actions Actions are plan JS objects describing the changes. By convention, an Action object must has a type property (String). Action objects may have additional properties related to the event just happened. The application state is read-only, and can only be modified by dispatching Actions to the Store.
  • 34. Reducer Reducer is a PURE function that specifies how the state changes in response to an Action. We can think of Reducer as an actions handler which determines how the state is changed. Reducer takes the previous state and the Action being dispatched, and returns the next state of the whole application. Reducer does NOT modify the state, It returns the NEW state. (Store will internally update the state)
  • 35. Pure function A function is PURE if we give it the same input, we always get the same output. No matter how many times we call that function. It must NOT have any side effects.