# 实战篇 06：消息通知设计

本节参考代码： react-boilerplate-pro

在传统的企业管理系统中一个经常被忽略掉的细节就是对于用户操作的反馈。一方面是因为复杂的业务流程边界条件太多，每一个分支都给予适当的反馈是一件非常烦琐的事情。另一方面往往是因为系统架构设计得不够灵活，只是显示一个操作成功或失败的通知就要写大量重复的逻辑代码，导致专注于业务流程的开发者不愿意花时间去处理操作反馈这一“可有可无”的需求。

在操作反馈通知（Notification）之外，完善的企业管理系统还需要一个全局的消息系统以方便系统管理员向某些或全部成员发送系统消息（Notice），即应用页眉中的通知栏，如 ant-design-pro 中的例子。

# 全局通知栏与应用初始化

与前端主导的通知系统不同，系统消息更依赖后端的实现。这里我们假设后端提供了获取当前用户未读消息的接口 /notices，创建相应的 redux action 为：

const getNotices = () => (
  createAsyncAction('APP_GET_NOTICES', () => (
    api.get('/notices')
  ))
);

@前端进阶之旅: 代码已经复制到剪贴板

# 应用数据初始化

在实现系统消息之前，我们首先要解决应用数据初始化的问题。以系统消息为例，用户在登录系统后点击应用页眉中的通知栏就应当立刻可以看到当前的未读消息。但获取用户未读消息是一个异步的过程，这里的异步请求应该在什么时候发出呢？

最简单的解决方案当然是在用户点击通知栏时发出，但这样做的弊端是用户在阅读消息前需要等待时间，没有充分利用到用户登录系统后但未点击通知栏这段空闲时间，而且如果用户频繁点击通知栏的话还会导致大量的冗余异步请求被发送至后端。

另一个解决方案就是在用户成功登录后发送请求去取得最新的未读消息：

const login = (username, password) => (
  createAsyncAction('APP_LOGIN', () => (
    api.post('/login', {
      username,
      password,
    })
  ))
);

const loginUser = (username, password) => {
  const action = login(username, password);

  return dispatch => (
    action(dispatch)
      .then(((callbackAction) => {
        if (callbackAction.type === 'APP_LOGIN_SUCCESS') {
          return getNotices()(dispatch);
        }
        return null;
      }))
  );
};

@前端进阶之旅: 代码已经复制到剪贴板

但这样做会有一个例外就是因为系统会记录用户的登录状态，在鉴权过期前用户刷新页面是不需要重新登录的。这时我们就需要在系统初始化时，判断如果用户已经登录就发送获取系统消息的请求。

const initClient = (dispatch) => {
  const commonActions = [
    dispatch(appAction.getLocale()),
  ];

  const isLogin = !isNil(Cookie.get('user'));

  if (isLogin) {
    commonActions.push(dispatch(appAction.getNotices()));
  }

  return commonActions;
};

@前端进阶之旅: 代码已经复制到剪贴板

并在应用的入口文件中将 redux 的 dispatch 方法传入 initClient：

const { store, history } = createStore(createBrowserHistory(), {});
const application = createApp(store, history);

initClient(store.dispatch);
ReactDOM.render(application, window.document.getElementById('app'));

@前端进阶之旅: 代码已经复制到剪贴板

按照同样的逻辑，我们可以将这一解决方案拓展到更多的需求，如在应用初始化时获取用户信息、国家时区信息等。

# 更新消息列表

在解决了数据获取的问题后，我们的布局组件就可以直接访问 redux store 中 app reducer 下的 notices 数据了。这里关于把 notices 存在哪个 reducer 中可能会有争议，比如它可以属于 app 的 reducer，即存放全局数据的地方，也可以单独创建一个 basicLayout 的 reducer 来存放布局组件所需要的数据，两种方案都是可行的。

接下来我们要实现的需求是在用户点击某一条消息后将其从消息列表中删除，因为系统消息列表是由后端控制的，所以这时我们需要向后端发送一个 DELETE 的请求以删除当前用户点击的某条消息。这时又会出现一个分歧是，后端在接收到 DELETE 请求后会不会将最新的消息列表再返回给前端。如果后端能够返回的话，我们只需要在 reducer 中替换掉原先的消息列表即可，但如果后端只返回操作成功或失败的话，我们还需要再发送一遍 getNotices 请求去拉取最新的消息列表。

最后，我们还需要处理无未读消息时的情况。

# 全局通知

回到一开始提到的操作反馈部分。

如果系统中的每个页面都需要独立去处理操作反馈的话，可以预见的是 <Notification /> 组件几乎会出现在所有的页面。这样的解决方案不仅非常烦琐而且不利于统一处理通用的逻辑。

既然通知组件可以使用绝对定位的方式出现在不同页面的同一位置，那么我们能不能将它的显示和隐藏逻辑也放在全局的层面上进行处理呢？

在回答这个问题前，我们先来写一个简单的基于绝对定位、支持自动隐藏的 UI 通知组件。

class Notification extends Component {
  componentDidMount() {
    this.timeout = setTimeout(this.props.onDismiss, this.props.timeout);
  }

  componentWillUnmount() {
    clearTimeout(this.timeout);
  }

  render() {
    const {
      prefixCls,
      title,
      content,
      onDismiss,
    } = this.props;

    return (
      <div className={prefixCls}>
        <Icon className={`${prefixCls}-close`} type="close" onClick={onDismiss} />
        <div className={`${prefixCls}-title`}>{title}</div>
        <div>{content}</div>
      </div>
    );
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

从上述代码中可以看出，onDismiss 回调就是为使用者隐藏全局通知时准备的。为了在全局的层面上解决通知的问题，让我们在 app reducer 中为通知提供一个存放数据的位置，暂且称为 notification，其中包含 title 及 content 两个字段。

// app reducer
const defaultState = () => ({
  isLogin: false,
  user: {},
  notification: {
    title: '',
    content: '',
  },
});

// app action
const updateNotification = notification => ({
  type: 'APP_UPDATE_NOTIFICATION',
  payload: notification,
});

const resetNotification = () => ({
  type: 'APP_RESET_NOTIFICATION',
});

// app reducer
const updateNotification = (state, action) => ({
  ...state,
  notification: action.payload,
});

const resetNotification = state => ({
  ...state,
  notification: {
    title: '',
    content: '',
  },
});

@前端进阶之旅: 代码已经复制到剪贴板

再将通知的渲染逻辑添加到 BasicLayout 布局组件中：

renderNotification = () => {
  const { notification: { title, content }, resetNotification } = this.props;
  if (isEmpty(title) && isEmpty(content)) {
    return null;
  }
  return (
    <Notification title={title} content={content} onDismiss={resetNotification} />
  );
}

@前端进阶之旅: 代码已经复制到剪贴板

即如果 notification 的 title 和 content 字段都不为空的话，就显示全局通知。同时我们也将重置通知的 action 配置给了 Notification 组件的 onDismiss 回调，即关闭通知相当于重置 notification 字段为空对象。

等这些准备工作都做好后，在具体的页面中显示通知就变得非常容易了：

const mapDispatchToProps = {
  updateNotification: appAction.updateNotification,
};

<Button
  type="primary"
  onClick={() => this.props.updateNotification({
    title: 'Notification Title',
    content: 'Notification will dismiss after 4.5s.',
  })}
>
>
</Button>

@前端进阶之旅: 代码已经复制到剪贴板

将 app action 中的 updateNotification 函数 connect 至相应的页面组件即可。然后在这个页面中，使用者就可以直接调用 this.props.updateNotification 来显示相应的通知了。又因为通知组件本身就支持自动隐藏的功能，使用者也不再需要去处理隐藏的逻辑。

# 知识点：数据驱动视图

全局通知这个例子很好地为我们诠释了「数据驱动视图」的含义，即根据数据中心是否存在 notification 对象来决定是否渲染通知组件。这打破了原先显示或隐藏通知这样命令式的代码逻辑，让每一次的用户操作从执行命令变为了修改数据，然后再由更新后的新数据去驱动视图进行相应的更新。

熟悉 React 的朋友一定看过下面这个公式：

view = f(state)

@前端进阶之旅: 代码已经复制到剪贴板

即视图是由当前应用状态推导而来。我们再尝试将 redux 也包含进来，在这个公式的基础上进行一下拓展。

根据

view = f1(state) && nextState = f2(currentState, action)

@前端进阶之旅: 代码已经复制到剪贴板

可以推导出

view = f1(f2(currentState, action))

@前端进阶之旅: 代码已经复制到剪贴板