在 React 应用中使用 Redux

和 Flux 类似,Redux 也是需要注册一个回调函数 store.subscribe(listener) 来获取 State 的更新,然后我们要在 listener 里面调用 setState() 来更新 React 组件。

Redux 官方提供了 react-redux 来简化 React 和 Redux 之间的绑定,不再需要像 Flux 那样手动注册/解绑回调函数。

接下来看一下是怎么做到的,react-redux 只有两个 API

<Provider>

<Provider> 作为一个容器组件,用来接受 Store,并且让 Store 对子组件可用,用法如下:

import { render } from 'react-dom';
import { Provider } from 'react-redux';
import App from './app';

render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

这时候 <Provider> 里面的子组件 <App /> 才可以使用 connect 方法关联 store。

<Provider> 的实现很简单,他利用了 React 一个(暂时)隐藏的特性 ContextsContext 用来传递一些父容器的属性对所有子孙组件可见,在某些场景下面避免了用 props 传递多层组件的繁琐,要想更详细了解 Contexts 可以参考这篇文章

Connect

connect() 这个方法略微复杂一点,主要是因为它的用法非常灵活:connect([mapStateToProps], mapDispatchToProps], [mergeProps], [options]),它最多接受4个参数,都是可选的,并且这个方法调用会返回另一个函数,这个返回的函数来接受一个组件类作为参数,最后才返回一个和 Redux store 关联起来的新组件,类似这样:

class App extends Component { ... }

export default connect()(App);

这样就可以在 App 这个组件里面通过 props 拿到 Store 的 dispatch 方法,但是注意现在的 App 没有监听 Store 的状态更改,如果要监听 Store 的状态更改,必须要指定 mapStateToProps 参数。

先来看它的参数:

  • [mapStateToProps(state, [ownProps]): stateProps]: 第一个可选参数是一个函数,只有指定了这个参数,这个关联(connected)组件才会监听 Redux Store 的更新,每次更新都会调用 mapStateToProps这个函数,返回一个字面量对象将会合并到组件的 props 属性。 ownProps 是可选的第二个参数,它是传递给组件的 props,当组件获取到新的 props 时,ownProps 都会拿到这个值并且执行 mapStateToProps 这个函数。
  • [mapDispatchProps(dispatch, [ownProps]): dispatchProps]: 这个函数用来指定如何传递 dispatch给组件,在这个函数里面直接 dispatch action creator,返回一个字面量对象将会合并到组件的 props属性,这样关联组件可以直接通过 props 调用到 action, Redux 提供了一个 bindActionCreators() 辅助函数来简化这种写法。 如果省略这个参数,默认直接把 dispatch 作为 props 传入。ownProps 作用同上。

剩下的两个参数比较少用到,更详细的说明参看官方文档,其中提供了很多简单清晰的用法示例来说明这些参数。

一个具体一点的例子

Redux 创建 Store,Action,Reducer 这部分就省略了,这里只看 react-redux 的部分。

import React, { Component } from 'react';
import someActionCreator from './actions/someAction';
import * as actionCreators from './actions/otherAction';

function mapStateToProps(state) {
  return {
    propName: state.propName
  };
}

function mapDispatchProps(dispatch) {
  return {
    someAction: (arg) => dispatch(someActionCreator(arg)),
    otherActions: bindActionCreators(actionCreators, dispatch)
  };
}

class App extends Component {
  render() {
    // `mapStateToProps` 和 `mapDispatchProps` 返回的字段都是 `props`
    const { propName, someAction, otherActions } = this.props;
    return (
      <div onClick={someAction.bind(this, 'arg')}>
        {propName}
      </div>
    );
  }
}

export default connect(mapStateToProps, mapDispatchProps)(App);

如前所述,这个 connected 的组件必须放到 <Provider> 的容器里面,当 State 更改的时候就会自动调用 mapStateToProps 和 mapDispatchProps 从而更新组件的 props。 组件内部也可以通过 props 调用到 action,如果没有省略了 mapDispatchProps,组件要触发 action 就必须手动 dispatch,类似这样:this.props.dispatch(someActionCreator('arg'))

表单

表单不同于其他 HTML 元素,因为它要响应用户的交互,显示不同的状态,所以在 React 里面会有点特殊。

状态属性

表单元素有这么几种属于状态的属性:

  • value,对应 <input> 和 <textarea> 所有
  • checked,对应类型为 checkbox 和 radio 的 <input> 所有
  • selected,对应 <option> 所有

在 HTML 中 <textarea> 的值可以由子节点(文本)赋值,但是在 React 中,要用 value 来设置。

表单元素包含以上任意一种状态属性都支持 onChange 事件监听状态值的更改。

针对这些状态属性不同的处理策略,表单元素在 React 里面有两种表现形式。

受控组件

对于设置了上面提到的对应“状态属性“值的表单元素就是受控表单组件,比如:

render: function() {
    return <input type="text" value="hello"/>;
}

一个受控的表单组件,它所有状态属性更改涉及 UI 的变更都由 React 来控制(状态属性绑定 UI)。比如上面代码里的 <input> 输入框,用户输入内容,用户输入的内容不会显示(输入框总是显示状态属性 value的值 hello),这有点颠覆我们的认知了,所以说这是受控组件,不是原来默认的表单元素了。

如果你希望输入的内容反馈到输入框,就要用 onChange 事件改变状态属性 value 的值:

getInitialState: function() {
    return {value: 'hello'};
},
handleChange: function(event) {
    this.setState({value: event.target.value});
},
render: function() {
    var value = this.state.value;
    return <input type="text" value={value} onChange={this.handleChange} />;
}

使用这种模式非常容易实现类似对用户输入的验证,或者对用户交互做额外的处理,比如截断最多输入140个字符:

handleChange: function(event) {
    this.setState({value: event.target.value.substr(0, 140)});
}

非受控组件

和受控组件相对,如果表单元素没有设置自己的“状态属性”,或者属性值设置为 null,这时候就是非受控组件。

它的表现就符合普通的表单元素,正常响应用户的操作。

同样,你也可以绑定 onChange 事件处理交互。

如果你想要给“状态属性”设置默认值,就要用 React 提供的特殊属性 defaultValue,对于 checked 会有 defaultChecked<option> 也是使用 defaultValue

为什么要有受控组件?

引入受控组件不是说它有什么好处,而是因为 React 的 UI 渲染机制,对于表单元素不得不引入这一特殊的处理方式。

在浏览器 DOM 里面是有区分 attribute 和 property 的。attribute 是在 HTML 里指定的属性,而每个 HTML 元素在 JS 对应是一个 DOM 节点对象,这个对象拥有的属性就是 property(可以在 console 里展开一个 DOM 节点对象看一下,HTML attributes 只是对应其中的一部分属性),attribute 对应的 property 会从 attribute 拿到初始值,有些会有相同的名称,但是有些名称会不一样,比如 attribute class 对应的 property 就是 className。(详细解释:.prop.prop() vs .attr()

回到 React 里的 <input> 输入框,当用户输入内容的时候,输入框的 value property 会改变,但是 value attribute 依然会是 HTML 上指定的值(attribute 要用 setAttribute 去更改)。

React 组件必须呈现这个组件的状态视图,这个视图 HTML 是由 render 生成,所以对于

render: function() {
    return <input type="text" value="hello"/>;
}

在任意时刻,这个视图总是返回一个显示 hello 的输入框。

<select>

在 HTML 中 <select> 标签指定选中项都是通过对应 <option> 的 selected 属性来做的,但是在 React 修改成统一使用 value

所以没有一个 selected 的状态属性。

<select value="B">
    <option value="A">Apple</option>
    <option value="B">Banana</option>
    <option value="C">Cranberry</option>
</select>

你可以通过传递一个数组指定多个选中项:<select multiple={true} value={['B', 'C']}>

玩转 React 服务器端渲染

React 提供了两个方法 renderToString 和 renderToStaticMarkup 用来将组件(Virtual DOM)输出成 HTML 字符串,这是 React 服务器端渲染的基础,它移除了服务器端对于浏览器环境的依赖,所以让服务器端渲染变成了一件有吸引力的事情。

服务器端渲染除了要解决对浏览器环境的依赖,还要解决两个问题:

  • 前后端可以共享代码
  • 前后端路由可以统一处理

React 生态提供了很多选择方案,这里我们选用 Redux 和 react-router 来做说明。

Redux

Redux 提供了一套类似 Flux 的单向数据流,整个应用只维护一个 Store,以及面向函数式的特性让它对服务器端渲染支持很友好。

2 分钟了解 Redux 是如何运作的

关于 Store:

  • 整个应用只有一个唯一的 Store
  • Store 对应的状态树(State),由调用一个 reducer 函数(root reducer)生成
  • 状态树上的每个字段都可以进一步由不同的 reducer 函数生成
  • Store 包含了几个方法比如 dispatchgetState 来处理数据流
  • Store 的状态树只能由 dispatch(action) 来触发更改

Redux 的数据流:

  • action 是一个包含 typepayload } 的对象
  • reducer 函数通过 store.dispatch(action) 触发
  • reducer 函数接受 (state, action) 两个参数,返回一个新的 state
  • reducer 函数判断 action.type 然后处理对应的 action.payload 数据来更新状态树

所以对于整个应用来说,一个 Store 就对应一个 UI 快照,服务器端渲染就简化成了在服务器端初始化 Store,将 Store 传入应用的根组件,针对根组件调用 renderToString 就将整个应用输出成包含了初始化数据的 HTML。

react-router

react-router 通过一种声明式的方式匹配不同路由决定在页面上展示不同的组件,并且通过 props 将路由信息传递给组件使用,所以只要路由变更,props 就会变化,触发组件 re-render。

假设有一个很简单的应用,只有两个页面,一个列表页 /list 和一个详情页 /item/:id,点击列表上的条目进入详情页。

可以这样定义路由,./routes.js

import React from 'react';
import { Route } from 'react-router';
import { List, Item } from './components';

// 无状态(stateless)组件,一个简单的容器,react-router 会根据 route
// 规则匹配到的组件作为 `props.children` 传入
const Container = (props) => {
  return (
    <div>{props.children}</div>
  );
};

// route 规则:
// - `/list` 显示 `List` 组件
// - `/item/:id` 显示 `Item` 组件
const routes = (
  <Route path="/" component={Container} >
    <Route path="list" component={List} />
    <Route path="item/:id" component={Item} />
  </Route>
);

export default routes;

从这里开始,我们通过这个非常简单的应用来解释实现服务器端渲染前后端涉及的一些细节问题。

Reducer

Store 是由 reducer 产生的,所以 reducer 实际上反映了 Store 的状态树结构

./reducers/index.js

import listReducer from './list';
import itemReducer from './item';

export default function rootReducer(state = {}, action) {
  return {
    list: listReducer(state.list, action),
    item: itemReducer(state.item, action)
  };
}

rootReducer 的 state 参数就是整个 Store 的状态树,状态树下的每个字段对应也可以有自己的
reducer,所以这里引入了 listReducer 和 itemReducer,可以看到这两个 reducer
的 state 参数就只是整个状态树上对应的 list 和 item 字段。

具体到 ./reducers/list.js

const initialState = [];

export default function listReducer(state = initialState, action) {
  switch(action.type) {
  case 'FETCH_LIST_SUCCESS': return [...action.payload];
  default: return state;
  }
}

list 就是一个包含 items 的简单数组,可能类似这种结构:[{ id: 0, name: 'first item'}, {id: 1, name: 'second item'}],从 'FETCH_LIST_SUCCESS' 的 action.payload 获得。

然后是 ./reducers/item.js,处理获取到的 item 数据

const initialState = {};

export default function listReducer(state = initialState, action) {
  switch(action.type) {
  case 'FETCH_ITEM_SUCCESS': return [...action.payload];
  default: return state;
  }
}

Action

对应的应该要有两个 action 来获取 list 和 item,触发 reducer 更改 Store,这里我们定义 fetchList 和 fetchItem 两个 action。

./actions/index.js

import fetch from 'isomorphic-fetch';

export function fetchList() {
  return (dispatch) => {
    return fetch('/api/list')
        .then(res => res.json())
        .then(json => dispatch({ type: 'FETCH_LIST_SUCCESS', payload: json }));
  }
}

export function fetchItem(id) {
  return (dispatch) => {
    if (!id) return Promise.resolve();
    return fetch(`/api/item/${id}`)
        .then(res => res.json())
        .then(json => dispatch({ type: 'FETCH_ITEM_SUCCESS', payload: json }));
  }
}

isomorphic-fetch 是一个前后端通用的 Ajax 实现,前后端要共享代码这点很重要。

另外因为涉及到异步请求,这里的 action 用到了 thunk,也就是函数,redux 通过 thunk-middleware 来处理这类 action,把函数当作普通的 action dispatch 就好了,比如 dispatch(fetchList())

Store

我们用一个独立的 ./store.js,配置(比如 Apply Middleware)生成 Store

import { createStore } from 'redux';
import rootReducer from './reducers';

// Apply middleware here
// ...

export default function configureStore(initialState) {
  const store = createStore(rootReducer, initialState);
  return store;
}

react-redux

接下来实现 <List><Item> 组件,然后把 redux 和 react 组件关联起来,具体细节参见 react-redux

./app.js

import React from 'react';
import { render } from 'react-dom';
import { Router } from 'react-router';
import createBrowserHistory from 'history/lib/createBrowserHistory';
import { Provider } from 'react-redux';
import routes from './routes';
import configureStore from './store';

// `__INITIAL_STATE__` 来自服务器端渲染,下一部分细说
const initialState = window.__INITIAL_STATE__;
const store = configureStore(initialState);
const Root = (props) => {
  return (
    <div>
      <Provider store={store}>
        <Router history={createBrowserHistory()}>
          {routes}
        </Router>
      </Provider>
    </div>
  );
}

render(<Root />, document.getElementById('root'));

至此,客户端部分结束。

Server Rendering

接下来的服务器端就比较简单了,获取数据可以调用 action,routes 在服务器端的处理参考 react-router server rendering,在服务器端用一个 match 方法将拿到的 request url 匹配到我们之前定义的 routes,解析成和客户端一致的 props 对象传递给组件。

./server.js

import express from 'express';
import React from 'react';
import { renderToString } from 'react-dom/server';
import { RoutingContext, match } from 'react-router';
import { Provider } from 'react-redux';
import routes from './routes';
import configureStore from './store';

const app = express();

function renderFullPage(html, initialState) {
  return `
    <!DOCTYPE html>
    <html lang="en">
    <head>
      <meta charset="UTF-8">
    </head>
    <body>
      <div id="root">
        <div>
          ${html}
        </div>
      </div>
      <script>
        window.__INITIAL_STATE__ = ${JSON.stringify(initialState)};
      </script>
      <script src="/static/bundle.js"></script>
    </body>
    </html>
  `;
}

app.use((req, res) => {
  match({ routes, location: req.url }, (err, redirectLocation, renderProps) => {
    if (err) {
      res.status(500).end(`Internal Server Error ${err}`);
    } else if (redirectLocation) {
      res.redirect(redirectLocation.pathname + redirectLocation.search);
    } else if (renderProps) {
      const store = configureStore();
      const state = store.getState();

      Promise.all([
        store.dispatch(fetchList()),
        store.dispatch(fetchItem(renderProps.params.id))
      ])
      .then(() => {
        const html = renderToString(
          <Provider store={store}>
            <RoutingContext {...renderProps} />
          </Provider>
        );
        res.end(renderFullPage(html, store.getState()));
      });
    } else {
      res.status(404).end('Not found');
    }
  });
});

服务器端渲染部分可以直接通过共用客户端 store.dispatch(action) 来统一获取 Store 数据。另外注意 renderFullPage生成的页面 HTML 在 React 组件 mount 的部分(<div id="root">),前后端的 HTML 结构应该是一致的。然后要把 store 的状态树写入一个全局变量(__INITIAL_STATE__),这样客户端初始化 render 的时候能够校验服务器生成的 HTML 结构,并且同步到初始化状态,然后整个页面被客户端接管。

最后关于页面内链接跳转如何处理?

react-router 提供了一个 <Link> 组件用来替代 <a> 标签,它负责管理浏览器 history,从而不是每次点击链接都去请求服务器,然后可以通过绑定 onClick 事件来作其他处理。

比如在 /list 页面,对于每一个 item 都会用 <Link> 绑定一个 route url:/item/:id,并且绑定 onClick 去触发 dispatch(fetchItem(id)) 获取数据,显示详情页内容。

更多参考

我们的未来

1、脑电波带来的第n次信息技术革命,彻底改变了人类传统的沟通方式。无言的交流。
2、重新定义人类。人类的进化,会从基因层面上,吸收其他物种的优秀基因,可以有选择地长出其他物种的器官。人类也不再千篇一律的相似,一个牛头马面的人不再罕见。满世界形形色色的人类,人类不再局限于两只手脚,一个脑袋,直立行走。也不再局限于陆地生活。那时人类将重新定义自己。那时人与人的区别,就像现在不同服装的区别。
人类可以通过基因制造出和目前各类电子设备功能相同的器官,如无线电收发器、显示器。

人类可以适应更高的温度,更低的寒冷。

数字化的人类,人类的生死,把一个人的思维意识记忆等数字化,人类的死亡也仅仅只是身体的报废。通过把数字化的意识记忆复制到新的躯体大脑中,满血复活。
一个人的消亡,是意识记忆的消亡。保存意识记忆的U盘丢失或损坏。把一个人的意识记忆的数字带到世界的另一端
起死回生。
人类指导下的有目的的进化,代替自然选择。人类设计师,生物在自然界缓慢进化。人类设计师可以快速设计出更优秀的自己。

3、交通

4、能源

5、政治

6、思想

7、外星生物

8、人类能否完全认知整个世界,把整个宇宙搞明白。
大道至简,我们的认知过程,总是从一个大的特定到一个小的特定。就如果洋葱,我们被包裹在最里层,想知道外面的宇宙。我们只有一层一层的向外认知。

无言的世界

未来也许
沟通不再依赖电话,交流不再依赖眼,嘴,耳,理解甚至不再依赖语言,文字。进入一个无言的世界。当我想与你沟通时,我的思维通过某种介质,传递到你的大脑中,你就能理解我的想法。人与人是在思维意识层次上的交流,是大脑与大脑的交流。省去思维意识到语言 语言到思维意识的转换。世界上不再需要语言。所有的动物,甚至植物相互都能进行精确的,无障碍交流。
人类的历史不再用文字记录,而直接能进入大脑的思维意识。
在某种层次上,人类的大脑与其他生物的大脑工作原理是一致的,可以理解相同的某种信号信息。在这种层次上,可以建立人与其它生物的沟通。
世界上不再有显示器,广播音响。街边的大型广告不在存在,取而代之的是一个思维意识发射器。所有通过的人都能感受到其发出的信息。

言语不是人类固有的,是人类依据自身发明的交流沟通的工具。如果言语只是一个工具,这一点被认同的话,那么,既然是工具,总是有可能会被替代的。如果一个工具不被替代,那也只是在一定的历史的,生产力的,技术的环境中不会被替代,如果这些都变化了,那么言语这个工具也将被替代。这一工具在一定的历史条件下十分有用。如果有更好的工具,言语可能会被替代。
心灵与心灵的直接沟通,酣畅淋漓。更直接,更准确。

Redis 为什么使用单进程单线程方式也这么快

Redis 采用的是基于内存的采用的是单进程单线程模型的 KV 数据库,由 C 语言编写。官方提供的数据是可以达到100000+的 qps。这个数据不比采用单进程多线程的同样基于内存的 KV 数据库 Memcached 差。

Redis 快的主要原因有:

完全基于内存;
数据结构简单,对数据操作也简单;
使用多路 I/O 复用模型;
继续阅读Redis 为什么使用单进程单线程方式也这么快

那年夏天

那年夏天,我漫步街头,心里一直在思念,思念着你。
那年夏天,我孤舟漂流,想起我们的曾经,泪水不停地流啊流。潸然泪下,泪水连连。

One summer’s day,I am drawing along the feeling,coughing,coughing by my deep sorrow.
那年夏天,我画笔零乱,思绪万千,咳声连连。
那年夏天,我想着你的话语,渐渐入眠,深夜里,一次又一次梦见你微笑的脸。

又有 谁能告诉我
又有谁能了解我
当初的决定是那么的恰当,似乎一切都是那样的理所当然。
如果一切都没有错,难道是我的感受。。。
And who can tell me
And who can understand me
My choice is the most appropriate and everything seems right.
Everything appears ok but my own feeling……
And then
On one summer’s night,I stop walking,I stop to look up to see the beautiful darkblue sky and the lovely stars.
On one summer’s night,I stop driving,I stop to listen to the whisper of the river and sing with her.
On one summer’s night,I stop drawing,I stop to make myself a drawing,with health look in my eye.
On one summer’s night,I stop sleeping,I stop to thy to forget all the beautiful memories about you all the night.
And I am waiting for the first sunshine to give me a hug and warm.
I am waiting,waiting ,and what I have to do is waiting.
And I felt asleep not very soon.
I felt asleep in the dream about you.
I choose to talk with you in the dream and nobody knows that so I felt easy.
I choose to laugh around you in the midnight and you don’t konw so I felt comfortable.
I finally choose to keep the feeling,keep the lovely feeling,in the opposite of the realistic world.
I finally choose to smile,smiling when you passing by.
I finally choose to be honest when I’m alone but a lier when I’m in the crowd.
And today,is one of the nice summer’s day and you have paid some visit to my imagination.
And tomorrow,will be a same day,and forever……
To be strong and be happy with the feeling forever
Can I ,can I ?
To live a happy life and forget our story
Can you, can you ?
If,I never come to the world and haven’t come across our story, then I never live, I think.
If,I haven’t happened to hear your song and never felt some courage form you,I never live,I think.
But and if ,they are part of my life and of course yours,but no one knows they can believe.
But ,if I believe,my world will be different.
One summer’s day,just like anyother day of the four seasons.
And my little story is so short but my feeling and thinking is so long.
One summer’s day is so beautiful but I must forget,forget that,I’m in the fall,and winter is drawing near……
and the last word of my heart
may you have a sound sleep and a happy life
that’s all ……