Flutter第5期 状态管理

一提起flutter，有一个东西一定不陌生。就是状态管理。网上的教程例子🌰也有很多。这里我谈谈自己对于状态管理的理解。那么状态管理管理的是什么？可能很多人觉得这个问题很可笑，状态管理啊，当然管理的是状态。那么状态又是指什么呢？比如我们设想一个场景。这个场景就是最简单的输入用户名密码点击登陆然后登陆成功显示相关信息。

假设我们所有的基础协议都已经完善了，我们只是填写一个表单，然后通过网络层发送并取得最终的返回值。在这个case里，你只要考虑两个事情

1. 有没有网络
2. 网络返回的值是否正确

————————————————————分割线————————————————————

好了，现在要加需求了，在点击login的时候我们发现，由于我们没有控制，用户可能在短时间内点击两次login按钮，于是我们想在点击登陆的时候判断是否在登陆中并且增加一个loading动画。于是我们应该引入一个变量来记录当前状态。并且在网络请求产生结果的时候消失掉当前的loading动画。

boolean isLoading;​

void onClick(){  
  if (isLoading) {    
    // return  
  } else {    
    // 执行login    
    isLoading = true;  
  }
}​

void onCallBack(){  
  if (isLoading){    
    loading = false;    
    // 停止动画  
  }
}

————————————————————分割线————————————————————

上面的例子中，我们使用了一个isloading作为很多行为的判断依据，随着需求的增加我们可能还会引入其它变量。比如

boolean isSuccessful;
boolean isFailed;
boolean isFinished;

在我们一开始构建应用的时候，也许很简单。我们有一些状态，直接把他们映射成视图就可以了。这种简单应用可能并不需要状态管理。但是随着功能的增加，你的应用程序将会有几十个甚至上百个状态。而随着我们这些变量的引入，势必会造成一种结果，庞大的if else判断。这样的代码不易于阅读和维护。状态越多，产生的组合分支也就越多。我们很难再清楚的测试维护我们的状态，因为它看上去实在是太复杂了！而且还会有多个页面共享同一个状态，例如当你进入一个文章点赞，退出到外部缩略展示的时候，外部也需要显示点赞数，这时候就需要同步这两个状态。这时候，我们便迫切的需要一个架构来帮助我们理清这些关系，状态管理框架应运而生。

————————————————————分割线————————————————————

对于像app这种需要用户输入事件作为驱动的程序来说，我们还有另外一个问题要解决。就是根据不同的状态要显示不同的UI的需求。往往实际的业务逻辑并没有多少，而UI页面不同元素的更新等特别的厚重。比如上图的密码处的小眼睛，点击后显示明文密码，再次点击隐藏。这个需求和后台数据没有任何关系。仅仅是UI层面的。而我们开发的过程中这样的需求也非常的多。我们能不能将一个这个过程拆分，将一个复杂的场景拆分成简单的场景呢。在绞尽脑汁想了一番之后，我注意到了facebook推出的flux框架，正好符合我们的预期。感兴趣的同学可以自行查阅，这里只说明其中的思路。

结构和数据流

用户操作view 产生Action --> 到达dispatcher处理 --> 分发到store处理 --> 返回到view Flux是单向数据流的思维模式，在UI端产生了 Action 之后，又Dispatcher发送到Store，然后将数据结果返回到View进行刷新操作。从这个模型来看，View端产生数据需求而且并不知道由哪个Store来处理，但是返回的数据是符合预期的。也就是说行为的结果可预测，而且不用考虑由哪个Store来处理。比如你的电脑坏了，你带着你的电脑去售后维修（产生了Action），到了售后将电脑交给售后小姐姐（Dispatch）并且说明了情况，售后小姐姐将你的电脑按着放到了维修部，维修部的工程师谁能休谁有空谁就来，而你并不需要知道谁来处理只需要等待就好了。当修理完毕，维修部通知你取电脑，一个流程完毕。

————————————————————分割线————————————————————

上面这个模式解决了逻辑状态互相缠绕在一起的复杂问题，我们将上面flux的思路稍做修改，由dispatcher处理分发并且处理当前Action的发起回调。数据状态在Store中做缓存处理，当detail中的请求数据返回显示在ui，并且产生了数据的修改，当回到list页面中，相关数据在Store中做了修改和缓存那么list页面中的数据也就随之更新。

使用此种模式，可以是数据逻辑与ui逻辑相分离，这样当需求发生变更，我们可以直接对ui部分进行修改，而数据逻辑的部分基本不会有太大的变化，维护性和可阅读性带来的提升显而易见。