上一篇文章介绍了我的前端数据源治理思想，其中提到了非常重要的数据源的概念。在推动团队按照这个数据源思想进行实施时，受到了不小的阻力。除了团队成员对架构、业务特性对技术的要求、长远眼光等的认识不足外，还有一点就是分层设计对直来直去的前端开发很难接受，因为要写多个文件更多代码，而且分散在不同处的代码看上去都是在为一件事服务。

在前端很少讲一些编程原则，所谓SOLID在前端根本行不通，但是，想要写出健壮的，长期可持续维护的代码，就必须去理解这些在其他编程领域通用的设计模式、原则、范式。

多态，在数据源上其实是比较容易体现的。听上去比较难理解。我认为前端应用因为和数据请求绑的太死，导致你需要通过处理异步（也就是Promise的resolved）来解决更新界面的问题。比如angular里面，你必须得注入$q来触发界面更新，在react里面，你得随时随地调用setState来更新。这使得异步动作被死死的绑定在组件中，而且你必须按照异步思维撰写组件。但在我看来，特别是react中，我们应该是同步思维，我们的天上会有一个神在观察世界的变化，然后将世界刷新成新的模样。对于身处这个世界的人，我们不需要也不能够观察这个变化，这个变化在世界之外，就像这个变化在组件之外，不应该在组件内部一样。而直接在组件内部写异步请求就是企图僭越去做神该做的事情，例如下面的代码：

function SomeComponent() {
  const [data, setData] = useState({})

  useEffect(() => {
    fetchData().then((data) => {
      setData(data)
    })
  }, [])

  return (
    <div>{data.title}</div>
  )
}

虽然代码本身没有错，但是这种写代码的意图是有问题的，这里的思维是我一进来默认是{}，然后我发起一个请求，这个请求一定会从外面得到一个数据，我要用这个数据出发一个变化。

这个思路是怎样的？这个思路一定是有一个动线的，先怎样，好暂时结束，再怎样，结束。也就是说你在这个函数里面，你是需要自己去想象一种难以理解的流动性的。

我们来看看另一种思维：

function SomeComponent() {
  const [data] = useData(someSource)

  return (
    <div>{data.title}</div>
  )
}

这里，这个组件从实际行为上，也会和前面一样被渲染两次，但是思路完全变了。对于我这个组件而言，我的动线是，拿数据，渲染，结束。虽然会被渲染两次，但是无论被渲染多少次，都是这样的一个思维方式。

你一看代码，心想，这有什么难的，不就是封装了一个hook函数吗？

但是你得到这个结论的时候，实际上是从结果反推你想要的解释。而真正理解了的人，他一定是从自己的思维开始出发，最终得到了这样的结果，实际上是完全不同的两种思维方式。即使你通过“封装”反推出“和我写的两次渲染没有差别“，也无法否定别人”拿数据，渲染，结束“这么一条动线的思维是更优秀的。

如果你能理解这一点，那么，我们就可以把这个问题想的更深。

数据从哪里来？一定是通过ajax请求吗？如果哪一天换成rpc呢？

数据的来源是多态，但是对于我们上面这个组件本身而言，我并不需要为每一种情况去做区分，我只需要统一一种处理方式即可，所以的数据来源，对我来说，我并不需要关心，我只是用它而已，而且我也知道这个data.title就是我需要的。面对这个多态，我们最好是用ts去写出它的接口，然后有不同的数据源，也就是我上面传入的someSource对象来具体实现，我们后续可以传入另一种实现someSource2，但是这并不影响我们任何的代码逻辑，只是在someSource2自己内部实现时，稍有不同而已。

有了这样的理解，我相信，逐渐的，你也会尝试自己去寻找一种在前端和数据源之间，可以有效将不同数据源进行管理起来的方式。比较幸运的是，我走的比较快一些。