redux有什么毛病

  • 一个组件所须要的数据，必须由父组件传过来，而不能像flux中间接从store取。
  • 当一个组件相干数据更新时，即便父组件不须要用到这个组件，父组件还是会从新render，可能会有效率影响，或者须要写简单的shouldComponentUpdate进行判断。

React-Router的路由有几种模式？

React-Router 反对应用 hash（对应 HashRouter）和 browser（对应 BrowserRouter） 两种路由规定， react-router-dom 提供了 BrowserRouter 和 HashRouter 两个组件来实现利用的 UI 和 URL 同步：

  • BrowserRouter 创立的 URL 格局：xxx.com/path
  • HashRouter 创立的 URL 格局：xxx.com/#/path

（1）BrowserRouter

它应用 HTML5 提供的 history API（pushState、replaceState 和 popstate 事件）来放弃 UI 和 URL 的同步。由此能够看出，BrowserRouter 是应用 HTML 5 的 history API 来管制路由跳转的：

<BrowserRouter    basename={string}    forceRefresh={bool}    getUserConfirmation={func}    keyLength={number}/>

其中的属性如下：

  • basename 所有路由的基准 URL。basename 的正确格局是后面有一个前导斜杠，但不能有尾部斜杠；
<BrowserRouter basename="/calendar">    <Link to="/today" /></BrowserRouter>

等同于

<a href="/calendar/today" />
  • forceRefresh 如果为 true，在导航的过程中整个页面将会刷新。个别状况下，只有在不反对 HTML5 history API 的浏览器中应用此性能；
  • getUserConfirmation 用于确认导航的函数，默认应用 window.confirm。例如，当从 /a 导航至 /b 时，会应用默认的 confirm 函数弹出一个提醒，用户点击确定后才进行导航，否则不做任何解决；
// 这是默认的确认函数const getConfirmation = (message, callback) => {  const allowTransition = window.confirm(message);  callback(allowTransition);}<BrowserRouter getUserConfirmation={getConfirmation} />
须要配合<Prompt> 一起应用。
  • KeyLength 用来设置 Location.Key 的长度。

（2）HashRouter

应用 URL 的 hash 局部（即 window.location.hash）来放弃 UI 和 URL 的同步。由此能够看出，HashRouter 是通过 URL 的 hash 属性来管制路由跳转的：

<HashRouter    basename={string}    getUserConfirmation={func}    hashType={string}  />

其参数如下：

  • basename, getUserConfirmation 和 BrowserRouter 性能一样；

  • hashType window.location.hash 应用的 hash 类型，有如下几种：

    • slash - 前面跟一个斜杠，例如 #/ 和 #/sunshine/lollipops；
    • noslash - 前面没有斜杠，例如 # 和 #sunshine/lollipops；
    • hashbang - Google 格调的 ajax crawlable，例如 #!/ 和 #!/sunshine/lollipops。

对于store的了解

Store 就是把它们分割到一起的对象。Store 有以下职责：

  • 维持利用的 state；
  • 提供 getState() 办法获取 state；
  • 提供 dispatch(action) 办法更新 state；
  • 通过 subscribe(listener)注册监听器;
  • 通过 subscribe(listener)返回的函数登记监听器

React中的状态是什么？它是如何应用的

状态是 React 组件的外围，是数据的起源，必须尽可能简略。基本上状态是确定组件出现和行为的对象。与props 不同，它们是可变的，并创立动静和交互式组件。能够通过 this.state() 拜访它们。

React申明组件有哪几种办法，有什么不同？

React 申明组件的三种形式：

  • 函数式定义的无状态组件
  • ES5原生形式React.createClass定义的组件
  • ES6模式的extends React.Component定义的组件

（1）无状态函数式组件 它是为了创立纯展现组件，这种组件只负责依据传入的props来展现，不波及到state状态的操作
组件不会被实例化，整体渲染性能失去晋升，不能拜访this对象，不能拜访生命周期的办法

（2）ES5 原生形式 React.createClass // RFC React.createClass会自绑定函数办法，导致不必要的性能开销，减少代码过期的可能性。

（3）E6继承模式 React.Component // RCC 目前极为举荐的创立有状态组件的形式，最终会取代React.createClass模式；绝对于 React.createClass能够更好实现代码复用。

无状态组件绝对于于后者的区别： 与无状态组件相比，React.createClass和React.Component都是创立有状态的组件，这些组件是要被实例化的，并且能够拜访组件的生命周期办法。

React.createClass与React.Component区别：

① 函数this自绑定

  • React.createClass创立的组件，其每一个成员函数的this都有React主动绑定，函数中的this会被正确设置。
  • React.Component创立的组件，其成员函数不会主动绑定this，须要开发者手动绑定，否则this不能获取以后组件实例对象。

② 组件属性类型propTypes及其默认props属性defaultProps配置不同

  • React.createClass在创立组件时，无关组件props的属性类型及组件默认的属性会作为组件实例的属性来配置，其中defaultProps是应用getDefaultProps的办法来获取默认组件属性的
  • React.Component在创立组件时配置这两个对应信息时，他们是作为组件类的属性，不是组件实例的属性，也就是所谓的类的动态属性来配置的。

③ 组件初始状态state的配置不同

  • React.createClass创立的组件，其状态state是通过getInitialState办法来配置组件相干的状态；
  • React.Component创立的组件，其状态state是在constructor中像初始化组件属性一样申明的。

React.Component 和 React.PureComponent 的区别

PureComponent示意一个纯组件，能够用来优化React程序，缩小render函数执行的次数，从而进步组件的性能。

在React中，当prop或者state发生变化时，能够通过在shouldComponentUpdate生命周期函数中执行return false来阻止页面的更新，从而缩小不必要的render执行。React.PureComponent会主动执行 shouldComponentUpdate。

不过，pureComponent中的 shouldComponentUpdate() 进行的是浅比拟，也就是说如果是援用数据类型的数据，只会比拟不是同一个地址，而不会比拟这个地址外面的数据是否统一。浅比拟会疏忽属性和或状态渐变状况，其实也就是数据援用指针没有变动，而数据产生扭转的时候render是不会执行的。如果须要从新渲染那么就须要从新开拓空间援用数据。PureComponent个别会用在一些纯展现组件上。

应用pureComponent的益处：当组件更新时，如果组件的props或者state都没有扭转，render函数就不会触发。省去虚构DOM的生成和比照过程，达到晋升性能的目标。这是因为react主动做了一层浅比拟。

参考 前端进阶面试题具体解答

React Hook 的应用限度有哪些？

React Hooks 的限度次要有两条：

  • 不要在循环、条件或嵌套函数中调用 Hook；
  • 在 React 的函数组件中调用 Hook。

那为什么会有这样的限度呢？Hooks 的设计初衷是为了改良 React 组件的开发模式。在旧有的开发模式下遇到了三个问题。

  • 组件之间难以复用状态逻辑。过来常见的解决方案是高阶组件、render props 及状态治理框架。
  • 简单的组件变得难以了解。生命周期函数与业务逻辑耦合太深，导致关联局部难以拆分。
  • 人和机器都很容易混同类。常见的有 this 的问题，但在 React 团队中还有类难以优化的问题，心愿在编译优化层面做出一些改良。

这三个问题在肯定水平上妨碍了 React 的后续倒退，所以为了解决这三个问题，Hooks 基于函数组件开始设计。然而第三个问题决定了 Hooks 只反对函数组件。

那为什么不要在循环、条件或嵌套函数中调用 Hook 呢？因为 Hooks 的设计是基于数组实现。在调用时按程序退出数组中，如果应用循环、条件或嵌套函数很有可能导致数组取值错位，执行谬误的 Hook。当然，本质上 React 的源码里不是数组，是链表。

这些限度会在编码上造成肯定水平的心智累赘，老手可能会写错，为了防止这样的状况，能够引入 ESLint 的 Hooks 查看插件进行预防。

React.forwardRef是什么？它有什么作用？

React.forwardRef 会创立一个React组件，这个组件可能将其承受的 ref 属性转发到其组件树下的另一个组件中。这种技术并不常见，但在以下两种场景中特地有用：

  • 转发 refs 到 DOM 组件
  • 在高阶组件中转发 refs

React 废除了哪些生命周期？为什么？

被废除的三个函数都是在render之前，因为fber的呈现，很可能因为高优先级工作的呈现而打断现有工作导致它们会被执行屡次。另外的一个起因则是，React想束缚使用者，好的框架可能让人不得已写出容易保护和扩大的代码，这一点又是从何谈起，能够从新减少以及行将废除的生命周期剖析动手

1) componentWillMount

首先这个函数的性能齐全能够应用componentDidMount和 constructor来代替，异步获取的数据的状况下面曾经阐明了，而如果抛去异步获取数据，其余的即是初始化而已，这些性能都能够在constructor中执行，除此之外，如果在 willMount 中订阅事件，但在服务端这并不会执行 willUnMount事件，也就是说服务端会导致内存透露所以componentWilIMount齐全能够不应用，但使用者有时候不免因为各 种各样的状况在 componentWilMount中做一些操作，那么React为了束缚开发者，罗唆就抛掉了这个API

2) componentWillReceiveProps

在老版本的 React 中，如果组件本身的某个 state 跟其 props 密切相关的话，始终都没有一种很优雅的解决形式去更新 state，而是须要在 componentWilReceiveProps 中判断前后两个 props 是否雷同，如果不同再将新的 props更新到相应的 state 下来。这样做一来会毁坏 state 数据的繁多数据源，导致组件状态变得不可预测，另一方面也会减少组件的重绘次数。相似的业务需要也有很多，如一个能够横向滑动的列表，以后高亮的 Tab 显然隶属于列表本身的时，依据传入的某个值，间接定位到某个 Tab。为了解决这些问题，React引入了第一个新的生命周期：getDerivedStateFromProps。它有以下的长处∶

  • getDSFP是静态方法，在这里不能应用this，也就是一个纯函数，开发者不能写出副作用的代码
  • 开发者只能通过prevState而不是prevProps来做比照，保障了state和props之间的简略关系以及不须要解决第一次渲染时prevProps为空的状况
  • 基于第一点，将状态变动（setState）和低廉操作（tabChange）辨别开，更加便于 render 和 commit 阶段操作或者说优化。

3) componentWillUpdate

与 componentWillReceiveProps 相似，许多开发者也会在 componentWillUpdate 中依据 props 的变动去触发一些回调 。 但不论是 componentWilReceiveProps 还 是 componentWilUpdate，都有可能在一次更新中被调用屡次，也就是说写在这里的回调函数也有可能会被调用屡次，这显然是不可取的。与 componentDidMount 类 似， componentDidUpdate 也不存在这样的问题，一次更新中 componentDidUpdate 只会被调用一次，所以将原先写在 componentWillUpdate 中 的 回 调 迁 移 至 componentDidUpdate 就能够解决这个问题。

另外一种状况则是须要获取DOM元素状态，然而因为在fber中，render可打断，可能在wilMount中获取到的元素状态很可能与理论须要的不同，这个通常能够应用第二个新增的生命函数的解决 getSnapshotBeforeUpdate(prevProps, prevState)

4) getSnapshotBeforeUpdate(prevProps, prevState)

返回的值作为componentDidUpdate的第三个参数。与willMount不同的是，getSnapshotBeforeUpdate会在最终确定的render执行之前执行，也就是能保障其获取到的元素状态与didUpdate中获取到的元素状态雷同。官网参考代码：

class ScrollingList extends React.Component {  constructor(props) {    super(props);    this.listRef = React.createRef();  }  getSnapshotBeforeUpdate(prevProps, prevState) {    // 咱们是否在 list 中增加新的 items ？    // 捕捉滚动地位以便咱们稍后调整滚动地位。    if (prevProps.list.length < this.props.list.length) {      const list = this.listRef.current;      return list.scrollHeight - list.scrollTop;    }    return null;  }  componentDidUpdate(prevProps, prevState, snapshot) {    // 如果咱们 snapshot 有值，阐明咱们刚刚增加了新的 items，    // 调整滚动地位使得这些新 items 不会将旧的 items 推出视图。    //（这里的 snapshot 是 getSnapshotBeforeUpdate 的返回值）    if (snapshot !== null) {      const list = this.listRef.current;      list.scrollTop = list.scrollHeight - snapshot;    }  }  render() {    return (      <div ref={this.listRef}>{/* ...contents... */}</div>    );  }}

state 和 props 触发更新的生命周期别离有什么区别？

state 更新流程： 这个过程当中波及的函数：

  1. shouldComponentUpdate: 当组件的 state 或 props 产生扭转时，都会首先触发这个生命周期函数。它会接管两个参数：nextProps, nextState——它们别离代表传入的新 props 和新的 state 值。拿到这两个值之后，咱们就能够通过一些比照逻辑来决定是否有 re-render（重渲染）的必要了。如果该函数的返回值为 false，则生命周期终止，反之持续；
留神：此办法仅作为性能优化的形式而存在。不要希图依附此办法来“阻止”渲染，因为这可能会产生 bug。应该思考应用内置的 PureComponent 组件，而不是手动编写 shouldComponentUpdate()
  1. componentWillUpdate：当组件的 state 或 props 产生扭转时，会在渲染之前调用 componentWillUpdate。componentWillUpdate 是 React16 废除的三个生命周期之一。过来，咱们可能心愿能在这个阶段去收集一些必要的信息（比方更新前的 DOM 信息等等），当初咱们齐全能够在 React16 的 getSnapshotBeforeUpdate 中去做这些事；
  2. componentDidUpdate：componentDidUpdate() 会在UI更新后会被立刻调用。它接管 prevProps（上一次的 props 值）作为入参，也就是说在此处咱们依然能够进行 props 值比照（再次阐明 componentWillUpdate 的确鸡肋哈）。

props 更新流程： 绝对于 state 更新，props 更新后惟一的区别是减少了对 componentWillReceiveProps 的调用。对于 componentWillReceiveProps，须要晓得这些事件：

  • componentWillReceiveProps：它在Component承受到新的 props 时被触发。componentWillReceiveProps 会接管一个名为 nextProps 的参数（对应新的 props 值）。该生命周期是 React16 废除掉的三个生命周期之一。在它被废除前，能够用它来比拟 this.props 和 nextProps 来从新setState。在 React16 中，用一个相似的新生命周期 getDerivedStateFromProps 来代替它。

React-Router怎么设置重定向？

应用<Redirect>组件实现路由的重定向：

<Switch>  <Redirect from='/users/:id' to='/users/profile/:id'/>  <Route path='/users/profile/:id' component={Profile}/></Switch>

当申请 /users/:id 被重定向去 '/users/profile/:id'：

  • 属性 from: string：须要匹配的将要被重定向门路。
  • 属性 to: string：重定向的 URL 字符串
  • 属性 to: object：重定向的 location 对象
  • 属性 push: bool：若为真，重定向操作将会把新地址退出到拜访历史记录外面，并且无奈回退到后面的页面。

如何将两个或多个组件嵌入到一个组件中？

能够通过以下形式将组件嵌入到一个组件中：

class MyComponent extends React.Component{    render(){        return(                      <div>                <h1>Hello</h1>                <Header/>            </div>        );    }}class Header extends React.Component{    render(){        return            <h1>Header Component</h1>      };}ReactDOM.render(    <MyComponent/>, document.getElementById('content'));

在React中如何防止不必要的render？

React 基于虚构 DOM 和高效 Diff 算法的完满配合，实现了对 DOM 最小粒度的更新。大多数状况下，React 对 DOM 的渲染效率足以业务日常。但在个别简单业务场景下，性能问题仍然会困扰咱们。此时须要采取一些措施来晋升运行性能，其很重要的一个方向，就是防止不必要的渲染（Render）。这里提下优化的点：

  • shouldComponentUpdate 和 PureComponent

在 React 类组件中，能够利用 shouldComponentUpdate或者 PureComponent 来缩小因父组件更新而触发子组件的 render，从而达到目标。shouldComponentUpdate 来决定是否组件是否从新渲染，如果不心愿组件从新渲染，返回 false 即可。

  • 利用高阶组件

在函数组件中，并没有 shouldComponentUpdate 这个生命周期，能够利用高阶组件，封装一个相似 PureComponet 的性能

  • 应用 React.memo

React.memo 是 React 16.6 新的一个 API，用来缓存组件的渲染，防止不必要的更新，其实也是一个高阶组件，与 PureComponent 非常相似，但不同的是， React.memo只能用于函数组件。

React如何获取组件对应的DOM元素？

能够用ref来获取某个子节点的实例，而后通过以后class组件实例的一些特定属性来间接获取子节点实例。ref有三种实现办法:

  • 字符串格局：字符串格局，这是React16版本之前用得最多的，例如：<p ref="info">span</p>
  • 函数格局：ref对应一个办法，该办法有一个参数，也就是对应的节点实例，例如：<p ref={ele => this.info = ele}></p>
  • createRef办法：React 16提供的一个API，应用React.createRef()来实现 　　　　　　

在React中组件的this.state和setState有什么区别？

this.state通常是用来初始化state的，this.setState是用来批改state值的。如果初始化了state之后再应用this.state，之前的state会被笼罩掉，如果应用this.setState，只会替换掉相应的state值。所以，如果想要批改state的值，就须要应用setState，而不能间接批改state，间接批改state之后页面是不会更新的。

react router

import React from 'react'import { render } from 'react-dom'import { browserHistory, Router, Route, IndexRoute } from 'react-router'import App from '../components/App'import Home from '../components/Home'import About from '../components/About'import Features from '../components/Features'render(  <Router history={browserHistory}>  // history 路由    <Route path='/' component={App}>      <IndexRoute component={Home} />      <Route path='about' component={About} />      <Route path='features' component={Features} />    </Route>  </Router>,  document.getElementById('app'))render(  <Router history={browserHistory} routes={routes} />,  document.getElementById('app'))

React Router 提供一个routerWillLeave生命周期钩子，这使得 React组件能够拦挡正在产生的跳转，或在来到route前提醒用户。routerWillLeave返回值有以下两种：

return false 勾销此次跳转
return 返回提示信息，在来到 route 前提醒用户进行确认。

对虚构 DOM 的了解？虚构 DOM 次要做了什么？虚构 DOM 自身是什么？

从实质上来说，Virtual Dom是一个JavaScript对象，通过对象的形式来示意DOM构造。将页面的状态形象为JS对象的模式，配合不同的渲染工具，使跨平台渲染成为可能。通过事务处理机制，将屡次DOM批改的后果一次性的更新到页面上，从而无效的缩小页面渲染的次数，缩小批改DOM的重绘重排次数，进步渲染性能。

虚构DOM是对DOM的形象，这个对象是更加轻量级的对DOM的形容。它设计的最后目标，就是更好的跨平台，比方node.js就没有DOM，如果想实现SSR，那么一个形式就是借助虚构dom，因为虚构dom自身是js对象。 在代码渲染到页面之前，vue或者react会把代码转换成一个对象（虚构DOM）。以对象的模式来形容实在dom构造，最终渲染到页面。在每次数据发生变化前，虚构dom都会缓存一份，变动之时，当初的虚构dom会与缓存的虚构dom进行比拟。在vue或者react外部封装了diff算法，通过这个算法来进行比拟，渲染时批改扭转的变动，原先没有产生扭转的通过原先的数据进行渲染。

另外古代前端框架的一个根本要求就是毋庸手动操作DOM，一方面是因为手动操作DOM无奈保障程序性能，多人合作的我的项目中如果review不严格，可能会有开发者写出性能较低的代码，另一方面更重要的是省略手动DOM操作能够大大提高开发效率。

为什么要用 Virtual DOM：

（1）保障性能上限，在不进行手动优化的状况下，提供过得去的性能

上面比照一下批改DOM时实在DOM操作和Virtual DOM的过程，来看一下它们重排重绘的性能耗费∶

  • 实在DOM∶ 生成HTML字符串＋ 重建所有的DOM元素
  • Virtual DOM∶ 生成vNode＋ DOMDiff＋必要的DOM更新

Virtual DOM的更新DOM的筹备工作消耗更多的工夫，也就是JS层面，相比于更多的DOM操作它的生产是极其便宜的。尤雨溪在社区论坛中说道∶ 框架给你的保障是，你不须要手动优化的状况下，我仍然能够给你提供过得去的性能。 （2）跨平台 Virtual DOM实质上是JavaScript的对象，它能够很不便的跨平台操作，比方服务端渲染、uniapp等。

在 React 中，refs 的作用是什么

Refs 能够用于获取一个 DOM 节点或者 React 组件的援用。何时应用 refs 的好的示例有治理焦点/文本抉择，触发命令动画，或者和第三方 DOM 库集成。你应该防止应用 String 类型的 Refs 和内联的 ref 回调。Refs 回调是 React 所举荐的。

React中能够在render拜访refs吗？为什么？

<>  <span id="name" ref={this.spanRef}>{this.state.title}</span>  <span>{     this.spanRef.current ? '有值' : '无值'  }</span></>

不能够，render 阶段 DOM 还没有生成，无奈获取 DOM。DOM 的获取须要在 pre-commit 阶段和 commit 阶段：

**

React 与 Vue 的 diff 算法有何不同？

diff 算法是指生成更新补丁的形式，次要利用于虚构 DOM 树变动后，更新实在 DOM。所以 diff 算法肯定存在这样一个过程：触发更新 → 生成补丁 → 利用补丁。

React 的 diff 算法，触发更新的机会次要在 state 变动与 hooks 调用之后。此时触发虚构 DOM 树变更遍历，采纳了深度优先遍历算法。但传统的遍历形式，效率较低。为了优化效率，应用了分治的形式。将繁多节点比对转化为了 3 种类型节点的比对，别离是树、组件及元素，以此晋升效率。

  • 树比对：因为网页视图中较少有跨层级节点挪动，两株虚构 DOM 树只对同一档次的节点进行比拟。
  • 组件比对：如果组件是同一类型，则进行树比对，如果不是，则间接放入到补丁中。
  • 元素比对：次要产生在同层级中，通过标记节点操作生成补丁，节点操作对应实在的 DOM 剪裁操作。

以上是经典的 React diff 算法内容。自 React 16 起，引入了 Fiber 架构。为了使整个更新过程可随时暂停复原，节点与树别离采纳了 FiberNode 与 FiberTree 进行重构。fiberNode 应用了双链表的构造，能够间接找到兄弟节点与子节点。整个更新过程由 current 与 workInProgress 两株树双缓冲实现。workInProgress 更新实现后，再通过批改 current 相干指针指向新节点。

Vue 的整体 diff 策略与 React 对齐，尽管不足工夫切片能力，但这并不意味着 Vue 的性能更差，因为在 Vue 3 初期引入过，前期因为收益不高移除掉了。除了高帧率动画，在 Vue 中其余的场景简直都能够应用防抖和节流去进步响应性能。