redux作为大型应用的状态管理工具，如果想配合react使用，需要借助react-redux。 redux主要完成两件事情：

• 通过context从root向下传入store，保证数据的单项流动的同时也方便了子组件从store上获取数据
• 当应用状态发生变化，触发subscribe方法进行监听，实现相关逻辑

在React 16.4.0之前，React官方是不推荐使用context的，原因在于，当context中的值刷新的时候，是从上到下刷新的，如果中间有组件的shouldComponentUpdate返回了false，这个组件下面的组件就收不到更新后的值；而React-Redux实现了订阅发布的模式，保证使用了store的组件在数据更新的时候可以得到通知。
在React 16.4.0之后官方将createContext暴露出来了，以上的问题不会出现，但是是不是意味着，可以用context来替代redux呢？理论上是可以的，但是并不推荐这样做，因为在redux的发展中，其生态系统是非常繁荣的，用Redux能避免重复造轮子的窘境。
引自：http://cuteshilina.com/2019/01/19/HowReactReduxWorks/#我们为什么需要react-redux

路由的概念

路由这个概念最开始是在后端出现的，以前使用模板引擎开发页面的时候经常会看到这样的路径：

1

http://hometown.xxx.edu.cn/bbs/forum.php

有时还会有带.asp或.html的路径，这就是所谓的SSR(Server Side Render)，通过服务端渲染，直接返回页面。

概念

所谓Promise，简单说就是一个容器，里面保存着某个未来才会结束的事件（通常是一个异步操作）的结果。从语法上说，Promise 是一个对象，从它可以获取异步操作的消息。Promise 提供统一的 API，各种异步操作都可以用同样的方法进行处理。

不管是Vue框架还是React框架，在实际开发使用的过程中我们都会有很多情况下都会有状态共享的需求，这些状态共享会发生在父子组件和兄弟组件之间，我们为了维护这些状态经常会写很多非必要性的代码，这些代码一多起来，维护就会变得很困难，正是由于有这种需求，人们开发了许多相关的库，从Flux到Redux再到Vuex，这些库的大致思路都是：将共享的状态抽离出来，通过定义和隔离状态管理中的各种概念并强制遵守一定的规则，达到代码结构化和易维护的目的。

尤大在官宣Vue 2.0的时候这么说过：

渲染层基于一个轻量级的 Virtual DOM 实现进行了重写，该 Virtual DOM 实现 fork 自 snabbdom。新的渲染层相比 v1 带来了巨大的性能提升，也让 Vue 2.0 成为了最快速的框架之一。
那么对于想要深入了解Vue源码的人来说先深入了解一下snabbdom的实现是有必要的

之前在Medium上看过一篇很有意思的文章： The deepest reason why modern JavaScript frameworks exist 文章里面大概描述了这么一个事实：我们用着一系列现代开发框架(Vue、React、Angular)，但是我们却忽略了他们之所以存在的最重要的意义：

管理不断变化的 state 非常困难。如果一个 model 的变化会引起另一个 model 变化，那么当 view 变化时，就可能引起对应 model 以及另一个 model 的变化，依次地，可能会引起另一个 view 的变化。直至你搞不清楚到底发生了什么。state 在什么时候，由于什么原因，如何变化已然不受控制。 当系统变得错综复杂的时候，想重现问题或者添加新功能就会变得举步维艰。

项目背景

京晚8点作为内容平台重点打造的内容IP，通过优质的内容形式，潜移默化中让用户了解产品，建立对京东开始玩内容的心智和认知，目前这个项目已经迭代到第5期，最开始的时候我们的首页效果是一个卡片形式的时间轴，首页的背景大图会随着时间轴拖动到不同的卡片而进行切换：
从第5期开始，我们采用了一种全新的交互方式来给用户更好的体验反馈，那就是滑屏，可以先看一下效果：

“沉浸播放式”这个概念是我从Android开发里面的沉浸式引申过来的一个概念，沉浸式其实就是隐藏页面顶部的status bar和底部的navigation bar之后呈现出来的页面，一般用户很容易把沉浸式状态栏和透明化状态栏混为一谈，他们的区别如下：