一切前端概念，都是纸老虎（附送书的抽奖结果

let b = 10;function compare(a) {

return a >= b;}

这个函数也有副作用，就是依赖外部的环境，b 在别处被改变了，返回值对于相同的 a 就有可能不一样。

而 Reducer 是一个纯函数，对于相同的输入，永远都只会有相同的输出，不会影响外部的变量，也不会被外部变量影响，不得改写参数。它的作用大概就是这样，根据应用的状态和当前的 action 推导出新的 state：

(previousState, action) => newState

类比 Flux，Flux 有些像：

(state, action) => state

为什么叫做 Reducer 呢？reduce 是一个函数式编程的概念，经常和 map 放在一起说，简单来说，map 就是映射，reduce 就是归纳。映射就是把一个列表按照一定规则映射成另一个列表，而 reduce 是把一个列表通过一定规则进行合并，也可以理解为对初始值进行一系列的操作，返回一个新的值。

比如 Array 就有一个方法叫 reduce，Array.prototype.reduce(reducer, ?initialValue)，把 Array 整吧整吧弄成一个 newValue。

const array1 = [1, 2, 3, 4];const reducer = (accumulator, currentValue) => accumulator + currentValue;// 1 + 2 + 3 + 4

console.log(array1.reduce(reducer));// expected output: 10// 5 + 1 + 2 + 3 + 4

console.log(array1.reduce(reducer, 5));// expected output: 15

看起来和 Redux 的 Reducer 是不是好像好像，Redux 的 Reducer 就是 reduce 一个列表（action的列表）和一个 initialValue（初始的 State）到一个新的 value（新的 State）。

把上面的概念连起来，举个例子：

下面的代码声明了 reducer：

const defaultState = 0;const reducer = (state = defaultState, action) => {

switch (action.type) {

case ‘ADD’:

return state + action.payload;

default:

return state;

}};

createStore接受 Reducer 作为参数，生成一个新的 Store。以后每当store.dispatch发送过来一个新的 Action，就会自动调用 Reducer，得到新的 State。

import { createStore } from ‘redux’;const store = createStore(reducer);

createStore 内部干了什么事儿呢？通过一个简单的 createStore 的实现，可以了解大概的原理（可以略过不看）：

const createStore = (reducer) => {

let state;

let listeners = [];

const getState = () => state;

const dispatch = (action) => {

state = reducer(state, action);

listeners.forEach(listener => listener());

};

const subscribe = (listener) => {

listeners.push(listener);

return () => {

listeners = listeners.filter(l => l !== listener);

}

};

dispatch({});

return { getState, dispatch, subscribe };};

Redux 有很多的 Reducer，对于大型应用来说，State 必然十分庞大，导致 Reducer 函数也十分庞大，所以需要做拆分。Redux 里每一个 Reducer 负责维护 State 树里面的一部分数据，多个 Reducer 可以通过 combineReducers 方法合成一个根 Reducer，这个根 Reducer 负责维护整个 State。

import { combineReducers } from ‘redux’;// 注意这种简写形式，State 的属性名必须与子 Reducer 同名const chatReducer = combineReducers({

Reducer1,

Reducer2,

Reducer3})

combineReducers 干了什么事儿呢？通过简单的 combineReducers 的实现，可以了解大概的原理（可以略过不看）：

const combineReducers = reducers => {

return (state = {}, action) => {

return Object.keys(reducers).reduce(

(nextState, key) => {

nextState[key] = reducers[key](state[key], action);

return nextState;

},

{}

);

};};

流程

再回顾一下刚才的流程图，尝试走一遍 Redux 流程：

1、用户通过 View 发出 Action：

store.dispatch(action);

2、然后 Store 自动调用 Reducer，并且传入两个参数：当前 State 和收到的 Action。Reducer 会返回新的 State 。

let nextState = xxxReducer(previousState, action);

3、State 一旦有变化，Store 就会调用监听函数。

store.subscribe(listener);

4、listener可以通过 store.getState() 得到当前状态。如果使用的是 React，这时可以触发重新渲染 View。

function listerner() {

let newState = store.getState();

component.setState(newState);

}

对比 Flux

和 Flux 比较一下：Flux 中 Store 是各自为战的，每个 Store 只对对应的 View 负责，每次更新都只通知对应的View：

Redux 中各子 Reducer 都是由根 Reducer 统一管理的，每个子 Reducer 的变化都要经过根 Reducer 的整合：

简单来说，Redux有三大原则：单一数据源：Flux 的数据源可以是多个。State 是只读的：Flux 的 State 可以随便改。* 使用纯函数来执行修改：Flux 执行修改的不一定是纯函数。

Redux 和 Flux 一样都是单向数据流。

中间件

刚才说到的都是比较理想的同步状态。在实际项目中，一般都会有同步和异步操作，所以 Flux、Redux 之类的思想，最终都要落地到同步异步的处理中来。

在 Redux 中，同步的表现就是：Action 发出以后，Reducer 立即算出 State。那么异步的表现就是：Action 发出以后，过一段时间再执行 Reducer。

那怎么才能 Reducer 在异步操作结束后自动执行呢？Redux 引入了中间件 Middleware 的概念。

其实我们重新回顾一下刚才的流程，可以发现每一个步骤都很纯粹，都不太适合加入异步的操作，比如 Reducer，纯函数，肯定不能承担异步操作，那样会被外部IO干扰。Action呢，就是一个纯对象，放不了操作。那想来想去，只能在 View 里发送 Action 的时候，加上一些异步操作了。比如下面的代码，给原来的 dispatch 方法包裹了一层，加上了一些日志打印的功能：

let next = store.dispatch;

store.dispatch = function dispatchAndLog(action) {

console.log(‘dispatching’, action);

next(action);

console.log(‘next state’, store.getState());}

既然能加日志打印，当然也能加入异步操作。所以中间件简单来说，就是对 store.dispatch 方法进行一些改造的函数。不展开说了，所以如果想详细了解中间件，可以点这里。

Redux 提供了一个 applyMiddleware 方法来应用中间件：

const store = createStore(

reducer,

applyMiddleware(thunk, promise, logger));

这个方法主要就是把所有的中间件组成一个数组，依次执行。也就是说，任何被发送到 store 的 action 现在都会经过thunk，promise，logger 这几个中间件了。

处理异步

对于异步操作来说，有两个非常关键的时刻：发起请求的时刻，和接收到响应的时刻（可能成功，也可能失败或者超时），这两个时刻都可能会更改应用的 state。一般是这样一个过程：

请求开始时，dispatch 一个请求开始 Action，触发 State 更新为“正在请求”状态，View 重新渲染，比如展现个Loading啥的。

请求结束后，如果成功，dispatch 一个请求成功 Action，隐藏掉 Loading，把新的数据更新到 State；如果失败，dispatch 一个请求失败 Action，隐藏掉 Loading，给个失败提示。

显然，用 Redux 处理异步，可以自己写中间件来处理，当然大多数人会选择一些现成的支持异步处理的中间件。比如 redux-thunk 或 redux-promise 。

Redux-thunk

thunk 比较简单，没有做太多的封装，把大部分自主权交给了用户：

const createFetchDataAction = function(id) {

return function(dispatch, getState) {

// 开始请求，dispatch 一个 FETCH_DATA_START action

dispatch({

type: FETCH_DATA_START,

payload: id

})

api.fetchData(id)

.then(response => {

// 请求成功，dispatch 一个 FETCH_DATA_SUCCESS action

dispatch({

type: FETCH_DATA_SUCCESS,

payload: response

})

})

.catch(error => {

// 请求失败，dispatch 一个 FETCH_DATA_FAILED action

dispatch({

type: FETCH_DATA_FAILED,

payload: error

})

})

}}//reducerconst reducer = function(oldState, action) {

switch(action.type) {

case FETCH_DATA_START :

// 处理 loading 等

case FETCH_DATA_SUCCESS :

// 更新 store 等

case FETCH_DATA_FAILED :

// 提示异常

}}

缺点就是用户要写的代码有点多，可以看到上面的代码比较啰嗦，一个请求就要搞这么一套东西。

Redux-promise

redus-promise 和 redux-thunk 的思想类似，只不过做了一些简化，成功失败手动 dispatch 被封装成自动了：

const FETCH_DATA = ‘FETCH_DATA’//action creatorconst getData = function(id) {

return {

type: FETCH_DATA,

payload: api.fetchData(id) // 直接将 promise 作为 payload

}}//reducerconst reducer = function(oldState, action) {

switch(action.type) {

case FETCH_DATA:

if (action.status === ‘success’) {

// 更新 store 等处理

} else {

// 提示异常

}

}}

刚才的什么 then、catch 之类的被中间件自行处理了，代码简单不少，不过要处理 Loading 啥的，还需要写额外的代码。

其实任何时候都是这样：封装少，自由度高，但是代码就会变复杂；封装多，代码变简单了，但是自由度就会变差。redux-thunk 和 redux-promise 刚好就是代表这两个面。

redux-thunk 和 redux-promise 的具体使用就不介绍了，这里只聊一下大概的思路。大部分简单的异步业务场景，redux-thunk 或者 redux-promise 都可以满足了。

上面说的 Flux 和 Redux，和具体的前端框架没有什么关系，只是思想和约定层面。下面就要和我们常用的 Vue 或 React 结合起来了：

Vuex

Vuex 主要用于 Vue，和 Flux，Redux 的思想很类似。

Store

每一个 Vuex 里面有一个全局的 Store，包含着应用中的状态 State，这个 State 只是需要在组件中共享的数据，不用放所有的 State，没必要。这个 State 是单一的，和 Redux 类似，所以，一个应用仅会包含一个 Store 实例。单一状态树的好处是能够直接地定位任一特定的状态片段，在调试的过程中也能轻易地取得整个当前应用状态的快照。

Vuex通过 store 选项，把 state 注入到了整个应用中，这样子组件能通过 this.\$store 访问到 state 了。

const app = new Vue({

el: ‘#app’,

// 把 store 对象提供给 “store” 选项，这可以把 store 的实例注入所有的子组件

store,

components: { Counter },

template: `

`})const Counter = {

template: <div>{{ count }}</div>,

computed: {

count () {

return this.$store.state.count

}

}}

State 改变，View 就会跟着改变，这个改变利用的是 Vue 的响应式机制。

Mutation

显而易见，State 不能直接改，需要通过一个约定的方式，这个方式在 Vuex 里面叫做 mutation，更改 Vuex 的 store 中的状态的唯一方法是提交 mutation。Vuex 中的 mutation 非常类似于事件：每个 mutation 都有一个字符串的 事件类型 (type) 和 一个 回调函数 (handler)。

const store = new Vuex.Store({

state: {

count: 1

},

mutations: {

increment (state) {

// 变更状态

state.count++

}

}})

触发 mutation 事件的方式不是直接调用，比如 increment(state) 是不行的，而要通过 store.commit 方法：

store.commit(‘increment’)

注意：mutation 都是同步事务。

mutation 有些类似 Redux 的 Reducer，但是 Vuex 不要求每次都搞一个新的 State，可以直接修改 State，这块儿又和 Flux 有些类似。具尤大的说法，Redux 强制的 immutability，在保证了每一次状态变化都能追踪的情况下强制的 immutability 带来的收益很有限，为了同构而设计的 API 很繁琐，必须依赖第三方库才能相对高效率地获得状态树的局部状态，这些都是 Redux 不足的地方，所以也被 Vuex 舍掉了。

到这里，其实可以感觉到 Flux、Redux、Vuex 三个的思想都差不多，在具体细节上有一些差异，总的来说都是让 View 通过某种方式触发 Store 的事件或方法，Store 的事件或方法对 State 进行修改或返回一个新的 State，State 改变之后，View 发生响应式改变。

Action

到这里又该处理异步这块儿了。mutation 是必须同步的，这个很好理解，和之前的 reducer 类似，不同步修改的话，会很难调试，不知道改变什么时候发生，也很难确定先后顺序，A、B两个 mutation，调用顺序可能是 A -> B，但是最终改变 State 的结果可能是 B -> A。

对比Redux的中间件，Vuex 加入了 Action 这个东西来处理异步，Vuex的想法是把同步和异步拆分开，异步操作想咋搞咋搞，但是不要干扰了同步操作。View 通过 store.dispatch(‘increment’) 来触发某个 Action，Action 里面不管执行多少异步操作，完事之后都通过 store.commit(‘increment’) 来触发 mutation，一个 Action 里面可以触发多个 mutation。所以 Vuex 的Action 类似于一个灵活好用的中间件。

Vuex 把同步和异步操作通过 mutation 和 Action 来分开处理，是一种方式。但不代表是唯一的方式，还有很多方式，比如就不用 Action，而是在应用内部调用异步请求，请求完毕直接 commit mutation，当然也可以。

Vuex 还引入了 Getter，这个可有可无，只不过是方便计算属性的复用。

Vuex 单一状态树并不影响模块化，把 State 拆了，最后组合在一起就行。Vuex 引入了 Module 的概念，每个 Module 有自己的 state、mutation、action、getter，其实就是把一个大的 Store 拆开。

总的来看，Vuex 的方式比较清晰，适合 Vue 的思想，在实际开发中也比较方便。

对比Redux

Redux：view——>actions——>reducer——>state变化——>view变化（同步异步一样）

Vuex：view——>commit——>mutations——>state变化——>view变化（同步操作） view——>dispatch——>actions——>mutations——>state变化——>view变化（异步操作）

React-redux

Redux 和 Flux 类似，只是一种思想或者规范，它和 React 之间没有关系。Redux 支持 React、Angular、Ember、jQuery 甚至纯 JavaScript。

但是因为 React 包含函数式的思想，也是单向数据流，和 Redux 很搭，所以一般都用 Redux 来进行状态管理。为了简单处理 Redux 和 React UI 的绑定，一般通过一个叫 react-redux 的库和 React 配合使用，这个是 react 官方出的（如果不用 react-redux，那么手动处理 Redux 和 UI 的绑定，需要写很多重复的代码，很容易出错，而且有很多 UI 渲染逻辑的优化不一定能处理好）。

Redux将React组件分为容器型组件和展示型组件，容器型组件一般通过connect函数生成，它订阅了全局状态的变化，通过mapStateToProps函数，可以对全局状态进行过滤，而展示型组件不直接从global state获取数据，其数据来源于父组件。

如果一个组件既需要UI呈现，又需要业务逻辑处理，那就得拆，拆成一个容器组件包着一个展示组件。

因为 react-redux 只是 redux 和 react 结合的一种实现，除了刚才说的组件拆分，并没有什么新奇的东西，所以只拿一个简单TODO项目的部分代码来举例：

入口文件 index.js，把 redux 的相关 store、reducer 通过 Provider 注册到 App 里面，这样子组件就可以拿到 store 了。

import React from 'react’import { render } from 'react-dom’import { Provider } from 'react-redux’import { createStore } from 'redux’import rootReducer from './reducers’import App from './components/App’const store = createStore(rootReducer)

render(

,

document.getElementById(‘root’))

actions/index.js，创建 Action：

let nextTodoId = 0export const addTodo = text => ({

type: ‘ADD_TODO’,

id: nextTodoId++,

text})export const setVisibilityFilter = filter => ({

type: ‘SET_VISIBILITY_FILTER’,

filter})export const toggleTodo = id => ({

type: ‘TOGGLE_TODO’,

id})export const VisibilityFilters = {

SHOW_ALL: ‘SHOW_ALL’,

SHOW_COMPLETED: ‘SHOW_COMPLETED’,

SHOW_ACTIVE: ‘SHOW_ACTIVE’}

reducers/todos.js，创建 Reducers：

const todos = (state = [], action) => {

switch (action.type) {

case ‘ADD_TODO’:

return [

…state,

{

id: action.id,

text: action.text,

completed: false

}

]

case ‘TOGGLE_TODO’:

return state.map(todo =>

todo.id === action.id ? { …todo, completed: !todo.completed } : todo

)

default:

return state

}}export default todos

reducers/index.js，把所有的 Reducers 绑定到一起：

import { combineReducers } from 'redux’import todos from './todos’import visibilityFilter from './visibilityFilter’export default combineReducers({

todos,

visibilityFilter,

…})

containers/VisibleTodoList.js，容器组件，connect 负责连接React组件和Redux Store：

import { connect } from 'react-redux’import { toggleTodo } from '…/actions’import TodoList from '…/components/TodoList’const getVisibleTodos = (todos, filter) => {

switch (filter) {

case ‘SHOW_COMPLETED’:

return todos.filter(t => t.completed)

case ‘SHOW_ACTIVE’:

return todos.filter(t => !t.completed)

case ‘SHOW_ALL’:

default:

return todos

}}// mapStateToProps 函数指定如何把当前 Redux store state 映射到展示组件的 props 中const mapStateToProps = state => ({

todos: getVisibleTodos(state.todos, state.visibilityFilter)})// mapDispatchToProps 方法接收 dispatch() 方法并返回期望注入到展示组件的 props 中的回调方法。const mapDispatchToProps = dispatch => ({

toggleTodo: id => dispatch(toggleTodo(id))})export default connect(

mapStateToProps,

mapDispatchToProps)(TodoList)

简单来说，react-redux 就是多了个 connect 方法连接容器组件和UI组件，这里的“连接”就是一种映射：mapStateToProps 把容器组件的 state 映射到UI组件的 props mapDispatchToProps 把UI组件的事件映射到 dispatch 方法

Redux-saga

刚才介绍了两个Redux 处理异步的中间件 redux-thunk 和 redux-promise，当然 redux 的异步中间件还有很多，他们可以处理大部分场景，这些中间件的思想基本上都是把异步请求部分放在了 action creator 中，理解起来比较简单。

redux-saga 采用了另外一种思路，它没有把异步操作放在 action creator 中，也没有去处理 reductor，而是把所有的异步操作看成“线程”，可以通过普通的action去触发它，当操作完成时也会触发action作为输出。saga 的意思本来就是一连串的事件。

redux-saga 把异步获取数据这类的操作都叫做副作用（Side Effect），它的目标就是把这些副作用管理好，让他们执行更高效，测试更简单，在处理故障时更容易。

在聊 redux-saga 之前，需要熟悉一些预备知识，那就是 ES6 的 Generator。

如果从没接触过 Generator 的话，看着下面的代码，给你个1分钟傻瓜式速成，函数加个星号就是 Generator 函数了，Generator 就是个骂街生成器，Generator 函数里可以写一堆 yield 关键字，可以记成“丫的”，Generator 函数执行的时候，啥都不干，就等着调用 next 方法，按照顺序把标记为“丫的”的地方一个一个拎出来骂（遍历执行），骂到最后没有“丫的”标记了，就返回最后的return值，然后标记为 done: true，也就是骂完了（上面只是帮助初学者记忆，别喷~）。

function* helloWorldGenerator() {

yield ‘hello’;

yield ‘world’;

return ‘ending’;}var hw = helloWorldGenerator();

hw.next() // 先把 ‘hello’ 拎出来，done: false 代表还没骂完// { value: ‘hello’, done: false } next() 方法有固定的格式，value 是返回值，done 代表是否遍历结束

hw.next() // 再把 ‘world’ 拎出来，done: false 代表还没骂完// { value: ‘world’, done: false }

hw.next() // 没有 yield 了，就把最后的 return ‘ending’ 拎出来，done: true 代表骂完了// { value: ‘ending’, done: true }

hw.next() // 没有 yield，也没有 return 了，真的骂完了，只能挤出来一个 undefined 了，done: true 代表骂完了// { value: undefined, done: true }

这样搞有啥好处呢？我们发现 Generator 函数的很多代码可以被延缓执行，也就是具备了暂停和记忆的功能：遇到yield表达式，就暂停执行后面的操作，并将紧跟在yield后面的那个表达式的值，作为返回的对象的value属性值，等着下一次调用next方法时，再继续往下执行。用 Generator 来写异步代码，大概长这样：

function* gen(){

var url = ‘https://api.github.com/users/github’;

var jsonData = yield fetch(url);

console.log(jsonData);}var g = gen();var result = g.next();

// 这里的result是 { value: fetch(‘https://api.github.com/users/github’), done: true }// fetch(url) 是一个 Promise，所以需要 then 来执行下一步

result.value.then(function(data){

return data.json();}).then(function(data){

// 获取到 json data，然后作为参数调用 next，相当于把 data 传给了 jsonData，然后执行 console.log(jsonData);

g.next(data);});

再回到 redux-saga 来，可以把 saga 想象成开了一个以最快速度不断地调用 next 方法并尝试获取所有 yield 表达式值的线程。举个例子：

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：前端）

总结一下

面试前要精心做好准备，简历上写的知识点和原理都需要准备好，项目上多想想难点和亮点，这是面试时能和别人不一样的地方。

还有就是表现出自己的谦虚好学，以及对于未来持续进阶的规划，企业招人更偏爱稳定的人。

万事开头难，但是程序员这一条路坚持几年后发展空间还是非常大的，一切重在坚持。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

为了帮助大家更好更高效的准备面试，特别整理了《前端工程师面试手册》电子稿文件。

前端面试题汇总

到现在。**

深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

[外链图片转存中…(img-sctdOzFJ-1710708781438)]
[外链图片转存中…(img-TQWM9VTQ-1710708781439)]
[外链图片转存中…(img-ljxxzY2x-1710708781439)]
[外链图片转存中…(img-IzsS9INF-1710708781439)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注：前端）
[外链图片转存中…(img-mUUrG7WZ-1710708781440)]

总结一下

面试前要精心做好准备，简历上写的知识点和原理都需要准备好，项目上多想想难点和亮点，这是面试时能和别人不一样的地方。

还有就是表现出自己的谦虚好学，以及对于未来持续进阶的规划，企业招人更偏爱稳定的人。

万事开头难，但是程序员这一条路坚持几年后发展空间还是非常大的，一切重在坚持。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

为了帮助大家更好更高效的准备面试，特别整理了《前端工程师面试手册》电子稿文件。

前端面试题汇总