掌握Redux：构建可预测应用的实战指南

需积分: 10 143 浏览量更新于2024-07-20 2 收藏 2.05MB PDF 举报

《开发Redux边缘》是一本专为想要深入学习JavaScript应用中的可预测状态管理器Redux的读者编写的书籍。它主要针对有一定JavaScript单页应用开发基础的中级开发者，特别是那些熟悉ES6、函数式编程和React的开发者。虽然这些技能会有所帮助，但并非必需，因为书中会逐步引导读者理解。为了跟随书中的示例，读者需要具备基本的终端操作能力，对Node.js和npm有所了解，并确保它们已经安装并可以使用。本书由Johannes Lumpe、Karl Purkhardt、Art Müller、Darío Cravero和Ezekiel Chentnik共同撰写，版权归属于BleedingEdgePress，强调所有内容未经许可不得复制或传播。作者、出版社及其分销商不对由于本书提供的信息导致的任何直接或间接损失负责。本书的ISBN号码是9781939902436，由BleedingEdgePress出版，位于加利福尼亚州圣罗莎。该书的作者们通过详尽的章节结构，帮助读者掌握Redux的核心概念和实践技巧。第1章探讨了使用Redux的原因，强调其在管理复杂应用状态时的优势，特别是对于提高代码的可维护性和一致性。接下来的章节依次深入，包括： - **Chapter 2. 核心概念**：介绍了Redux的基础架构，如store、reducer和action，以及它们如何协同工作以实现状态的集中管理和更新逻辑。 - **Chapter 3. Redux模式**：涵盖了常见Redux模式，如单一数据源、分隔模块化状态、以及高级功能如中间件和异步处理。 - **Chapter 4. 建立样例应用**：通过实际项目的构建，展示了如何将Redux应用到一个完整的项目中，包括组件化开发和API集成。 - **Chapter 5. 同步数据与服务器**：讨论了如何在Redux中处理服务器数据同步，包括fetch API和RESTful接口的整合。 - **Chapter 6. 显示请求状态给用户**：介绍如何处理请求状态，以提升用户体验，例如显示加载指示或错误处理。 - **Chapter 7. 客户端持久化状态**：讲解如何利用localStorage或浏览器的IndexedDB等技术，使应用在离线状态下仍能保持部分状态。 - **Chapter 8. 分析中间件**：深入剖析Redux的扩展性，包括用于收集分析数据的工具和最佳实践。 - **Chapter 9. 最佳实践**：提供关于编写高效、可测试和易于维护的Redux代码的实用建议。 - **Chapter 10. 走向离线**：探讨如何实现离线模式，确保应用在没有网络连接时也能提供基本的功能。最后，书的前言部分概述了编写本书的目的和目标，以及作者们的写作背景和预期读者群。整体上，《开发Redux边缘》是一本旨在帮助开发者精通Redux技术，从而提升其JavaScript应用开发能力的实用指南。

nous logic. Likewise, if you have a problem with your asynchronous logic, you can focus on

debugging it without having to worry about state.

Not only is this better for your sanity, it opens up a range of additional benefits, ranging

from improvements to developer workflows to easier unit testing. All of this due to the sep-

aration of asynchronous logic from state mutation.

Redux does more than simply separate these concerns, it also implements restrictions

on how state can be mutated, making state mutations predictable, and the state of your

application much easier to reason about.

Redux wants to give you control back, it wants you to enjoy programming again, and it’s

going to do this by providing you with an architecture that is developer friendly, predicta-

ble, and robust.

Redux background

Redux was created by Dan Abramov, who is currently a developer working on React at

Facebook. Dan created Redux while working on a talk called “Hot Reloading with Time

Travel for React Europe 2015.” In order to demonstrate these two concepts, a predictable

architecture that used a single state tree was required. It was this desire that drove the cre-

ation of Redux.

The birth of Redux

Dan initially tried to use traditional Flux, but he had many diiculties. For example, in order

to hot reload store logic, a store had to be a pure function. This wasn’t the case with tradi-

tional Flux stores that have behavior such as subscribe and register built in. As you remove

this behavior from traditional Flux stores, you end up with stateless stores, and the first

step towards Redux.

Note: In Redux we call these stateless stores reducers, and we’ll refer to them as that

from now on.

Once you have stateless stores, which we’re now calling reducers, you can hot reload

the state logic. These reducers were still tied to a dispatcher though. So, instead of having

multiple stateless reducers, a single reducer was introduced. This single reducer removed

the need for a dispatcher because actions then have a single destination.

The obvious problem with having a single reducer is that there is no separation of re-

sponsibilities. This is easily overcome by the fact that reducers are just pure functions, and

that means they can be composed of other functions. So a single reducer can be composed

of many smaller reducer functions, each one with a particular responsibility.

At this point you essentially have Redux. You have a single store and a single root reduc-

er created from a pure function. These are two of the Redux core principles. This early im-

plementation has been improved and polished, becoming the library that we know today.

CHAPTER 1: Why Use Redux?

Redux influences

Let’s examine the major Redux influencers.

Elm

Redux produces an architecture that is very similar to the architecture used in Elm - a func-

tional programming language for HTML apps. It can even be considered an almost direct

translation into JavaScript. While this is true, Redux is not simply a direct copy of Elm. Elm

is more of an indirect influence, and the fact that they are very similar is proof that great

architectures naturally arise from similar design goals.

ES6

ES6 is heavily used in Redux. You will benefit greatly from being comfortable reading and

writing ES6 code when learning Redux. Redux doesn’t use ES6 just for the sake of it, the

language features most used actually make writing Redux application code much easier.

We’re not saying that you need to stop and learn ES6 inside-out before continuing, rath-

er that you should be comfortable with it, because you’re going to see a lot of it, and you’ll

pick things up much quicker if you can focus on learning one thing at a time.

At the very least, you should be comfortable reading arrow syntax functions, and have a

good understanding of the const and let keywords, as well as the spread operators for

arrays and objects. Object spreads are currently an in-progress proposal for the JavaScript

language, and widely available through tools like babel, and useful when writing reducer

logic.

Functional programming

Redux embraces functional programming and incorporates many functional programming

concepts into its methodology. Although functional programming is not a prerequisite to

learning Redux, knowing about the core concepts of functional programming will certainly

help reduce the initial learning curve.

Immutability

Immutability is a related concept to functional programming. Immutable data is simply da-

ta that cannot be changed aer it has been created. Redux embraces immutability, since

it’s at the core of at least one of the three principles of redux: state must be read only.

Redux doesn’t enforce this, and you’re free to use mutable or immutable objects to

model your state, but you should follow the rules of immutability and ensure that you

Redux influences

don’t mutate state to benefit from the predicability that it provides. This also ensures that

scenarios like time travel debugging will work correctly, and that UI components will up-

date properly.

Flux

Redux is inspired by Flux - an application architecture for building user interfaces that uses

a unidirectional data flow. If you compare the two you will notice similarities - both help to

manage application state, and both implement mechanisms for managing how changes

are made to the state.

Although similar, there are some key dierences between the two. One key dierence is

that in Flux there is the concept of a dispatcher. A dispatcher is responsible for relaying ac-

tions to listening stores. Redux, however, eliminates the need for a dispatcher through the

use of a single reducer, pure functions, and function composition.

Another key dierence is that Flux has many stores with each store managing a sepa-

rate piece of state for a particular area of the application. In Redux there is only one store

and one single source of state - referred to as the single source of truth. You can still man-

age state for dierent areas of the application, but in Redux you use reducers, and function

composition, to achieve this.

Both approaches solve the same problem, they just do so it in slightly dierent ways.

Unidirectional data flow

With roots in functional reactive programming, unidirectional data flow has gained popu-

larity in recent years. The main principle is that data flows through your application in a

single direction, making the flow of data through your application much easier to reason

about.

With unidirectional data flow architectures like Flux and Redux, your state is contained

in stores (a single store, in Redux) and updates to the state are managed through actions

that describe how the state should be transformed. The view layer can then subscribe to

the store(s) to receive new state whenever it’s changed.

The following diagram illustrates the typical data flow in a Redux application. Here you

can see that an action is dispatched to the store, so the store then passes the existing state

and the action to the reducer, which transforms the state. The new state then flows

through to any listeners, such as views. A view can dispatch further actions, starting the

process again.

CHAPTER 1: Why Use Redux?

剩余208页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

掌握Redux：构建可预测应用的实战指南

彻底征服 React.js ＋Flux+Redux视频教程.txt

redux+react+router+node.js

react 项目index.js取redux的props

redux-thunk和redux-saga区别

谈谈你对 Redux 的理解？简要的介绍一下 Redux 的工作流程？

怎么更新redux.min.js文件

store.default.dispatch与store.dispatch的区别

redux 和 vuex的区别

mobox和redux的区别

请给出react-redux的详细使用方法

最新资源