关于前端:用Algeb这个新轮子管理前端数据请求资源

7次阅读

共计 4836 个字符，预计需要花费 13 分钟才能阅读完成。

一个前端我的项目须要治理一堆前端数据申请，古代前端利用，简直没见过将数据申请间接写在业务代码中，大部分时候，咱们都会将这些申请逻辑从业务代码中抽出来，集中管理。但随着业务开发的重复进行，咱们会逐步发现一些景象，咱们对后端吐给咱们的数据开始提出一些具体细节上的要求，就我集体而言，我总结出如下要求：

如何防止同一个申请被屡次发动？
如何在某处发动申请，当数据回来后，另外一处应用了该申请数据的组件自动更新？
如何在第一次渲染的时候就能够失常渲染？
如何提供更优良的编程体验和治理形式？

我在几年前写过一个库 databaxe，提出一种新型的数据源理念，这种理念让咱们能够写同步代码，把申请过程和数据进行拆散，对前端而言，申请自身是不可见的。前端只须要从仓库中读取数据即可。但过后采纳了具名形式规定每一个数据源的名称，获取参数对应关系比较复杂，须要监听，而且内置了 axios 作为数据申请器，对开发者而言是不凋谢的。

为了持续实际这种写同步代码的形式，同时使数据申请自身更凋谢，我写了 algeb 这个库

gitee.com/frustigor/algebgitee.com

它的源码比 databaxe 少了 n 倍，应用办法简略了 n 倍。让咱们来看看，我是如何做到的。

咱们大多状况下是通过申请后端 API 获取数据，但 API 并不是惟一的数据源，在前端编程中，客户端长久化数据（例如存在 indexedDB 中的数据），websocket 推送的数据，都是重要的数据起源。因而，咱们要寻找一种编程形式，能够兼容不同模式的数据源，将不同模式起源的数据，通过一套形式进行治理。

Algeb 的形式是，将数据源和数据应用进行隔离，如何从数据源获取数据不在 Algeb 的管辖范畴内，然而开发者须要将一个函数托管给它，这个函数从数据源失去该数据源的数据。也就是说，它不关怀获取的过程，只关怀后果，也就是这个函数的返回值就是我须要的最终数据。

import {source} from 'algeb'

const Some = source(function() {// ... 获取数据的函数，返回值即为被管辖的数据源数据}, {
  name: '',
  age: 0,
})

然而有一个十分常见的问题，咱们管辖一个数据源，却可能通过不同参数取得不同对象。例如：

async function getBook(id) {return fetch(`/api/v2/books/${id}`).then(res => res.json()).then(body => body.data)
}

这是咱们常见的一个用于获取一本书详细信息的函数。咱们常常会传入 id 来决定获取哪一本书的信息。而面对这种状况，咱们怎么去用 Algeb 治理呢？难道要为每一本书建设一个源？

当然不须要，Algeb 所认为的数据源，并非指繁多数据，而是获取模式雷同数据的办法（也就是这个函数），并且以该函数的参数作为标记记录该源所有被应用到的具体数据颗粒。这个逻辑是外部实现的，开发者不须要关怀，只须要记住一点，数据源函数参数最好越简略越好，这样有利于对参数进行计算，作为辨认具体数据的根据。

const Book = source(getBook, { 
  title: '',
  price: 0,
})

source函数的第二个参数是该源的默认值，我所崇尚的同步代码书写形式要求代码在执行一开始就是 OK 的，不报错的，所以，这个默认值十分要害，同时，通过这个默认值，也能够通知团队其余成员理解一个数据源将获取到的数据的根本格局。

你可能会问，websockt 推送的数据怎么办呢？因为 algeb 只关怀获取数据的后果，所以开发者怎么从 websockt 获取数据咱们并不关怀。我本人想到一种形式是，用一个全局变量保存不同数据源来自 websockt 的数据，而后在数据源函数中，读取该全局变量上的属性返回。

通常状况下，咱们现有的数据源管理器只是简略的读写逻辑，并没有规定数据缓存的逻辑。我心愿通过更形象的形式，让开发者本人来规定数据再次申请的逻辑。通过 Algeb 的 compose 办法，能够组合一个或多个数据源，并附增非凡逻辑进去。

import {compose, query, affect} from 'algeb'

const Order = compose(function(bookId, photoId) {const [book, refetchBook] = query(Book, bookId)
  const [photo, refetchPhoto] = query(Photo, photoId)
  
  affect(function() {const timer = setInterval(() => {refetchBook()
      refetchPhoto()}, 5000)
    return () => clearInterval(timer)
  }, [book, photo])
  
  const total = book.price + photo.price
  
  return {book, photo, total}
})

这是 compose 的一个例子。它通过组合 book 和 photo 两个对象，并附加算出这个订单的总价格，作为一个新的数据源返回。从“数据源”的定义上，Book, Photo, Order 都是数据源，实质雷同，只是类型不同而已。

有一个约定，尽管 compose 的返回值能够是任意的，然而它肯定是同步执行完后返回，所以 compose 不承受 async 函数。

但但凡数据源，就能够在环境中（compose/setup）应用 query 读取，query 函数接管第一个参数为一个数据源对象，前面的参数将作为数据源函数的参数进行透传。它的返回值是一个两个元素的数组，第一个元素是数据源依据该参数返回的值，第二个参数是刷新数据源数据的触发器（非申请器）。

在环境中，还能够应用 affect 等 hooks 函数，这些函数在环境中执行，例如下面这段代码中，通过 affect 规定了 Order 这个数据源一旦被查问，就会每隔 5 秒钟再查一次。这样，咱们通过 compose，实际上定义了一个不仅能够获取值的数据源，还定义了该数据源刷新数据的形式。

compose让咱们能够在获取一个值的同时，还会触发其余源的更新。这在一些场景下极其好用。例如，咱们有 A、B 两个源，当咱们提交对 A 的更新后，须要同时从新拉取 A、B 的新值。咱们能够通过 compose 来解决。

const UpdateBook = compose(function(bookId, data, photoId) {const [book, refetchBook] = query(Book, bookId)
  const [_, refetchPhoto] = query(Photo, photoId)
  
  affect(function() {updateBook(bookId, data).then(() => {refetchBook() // 从新获取该书信息
      refetchPhoto() // 从新获取图像信息})
  })
})

这个组合源只用于发送数据到服务端，发送胜利后会同时抓取两个数据源的新数据。一旦新数据获取胜利，所有依赖于对应数据颗粒（Book:bookId, Photo:photoId）的环境，全副都会被更新。

响应式利用框架的特色是主动将数值的变动反馈为界面的变动。但如果你仔细观察我上述形容，就会发现，怎么实现响应式呢？这波及到咱们怎么去设计当数据源发生变化时，将这一变动产生的副作用即时反馈。

和常见的“观察者模式”不同，我借鉴的是 react hooks 的响应式计划，即基于代数效应的依赖响应。咱们看 react 的 functional 组件，你会发现，它的响应式副作用，是“再算一次”！

再算一次！也就是组件 function 再执行一次，每次 state 被更新时，组件 function 被再次执行，失去新的组件树。神奇的“再算一次”特效，实践上会耗费更多性能，却让咱们能够像撰写同步代码一样，从顶向底书写逻辑，并通过 useEffect 来执行副作用。

在 Algeb 中，我也是基于这种思路，但因为这是一个通用库，它不依赖框架，要去适应不同框架的差别，因而，我提供了一个 setup 提供执行上下文。

import {setup} from 'algeb'

setup(function() {const [some, refetchSome] = query(Some)
  
  affect(function() {console.log(some.price)
  }, [some.price])
  
  render(`<div>${some.price}</div>`)
})

setup是所有 algeb 利用的入口，在 setup 之外应用 algeb 定义的源没有意义，甚至会报错。它接管的函数被成为执行宿主，这个宿主函数会被重复执行，它外部肯定是会有副作用的，例如，下面这段代码，副作用就是 render。当被query 的数据颗粒取得新数据时，宿主函数会被再次执行，这样，就会产生新的副作用，从而反馈到界面上。

数据颗粒是指基于 query 参数的数据源状态之一，比方后面的 Book 这个源，每一个 bookId 会对应一个数据颗粒，每个数据颗粒保留着以后时刻该 bookId 的 book 的实在信息，一旦有任何一个中央触发了数据更新，那么就会让源函数再次执行，去取得新的数据，新数据回来之后，通过外部比照发现数据产生了变动，宿主函数就会再次执行，从而副作用失效。

如此周而复始，就会给人一种响应式的编程的感觉，而这种感觉，和传统的通过观察者模式实现的响应式具备十分大的感官差别，而这个差别，就是 react 践行的代数效应所带来的。

为了适应不同框架中更好的联合应用，我在库中提供了不同框架的应用。

React 中应用

import {useQuery} from 'algeb/react'

function MyComponent(props) {const { id} = props
  const [some, fetchSome] = useQuery(SomeSource, id)
  // ...
}

Vue 中应用

import {useQuery} from 'algeb/vue'

export default {setup(props) {const { id} = props
    const [someRef, fetchSome] = useQuery(SomeSource, id)
    const some = someRef.value
    // ...
  }
}

Angularjs 中应用

const {useQuery} = require('algeb/vue')

module.exports = ['$scope', '$stateParams', function($scope, $stateParams) {const { id} = $stateParams
  const [someRef, fetchSome] = useQuery(SomeSource, id)($scope)
  $scope.some = someRef // {value}
  // ...
}]

Angular 中应用

import {Algeb} from 'algeb/angular' // ts

@Component()
class MyComponent {@Input() id

  constructor(private algeb:Algeb) {const [someRef, fetchSome] = this.algeb.useQuery(SomeSource, this.id)
    this.some = someRef // {value}
  }
}

在前端应用层和后端、长久化存储、websockt 等原始数据交互时，对于前端而言，这种交互过程都是没有必要的，是和业务自身无关的副作用。Algeb 这个库，试图用代数效应，参考 react hooks 的应用办法，实现前后端两头服务层的形象。通过对数据源的定义和组合，以 setup 提供宿主，实现另一种格调的响应式。如果你认为这种形象能激发起你一点点趣味，无妨到仓库中一起探讨，写码。

正文完