学不动系列:新前端框架 Nautil,哇~

基于 react 的除了 Next.js 其他的所谓框架我都只想说,鸡你太美!React 实在太香了,但是实战开发起来却又不怎么好弄。让我们来看最新的 roadmap:

来自:react-developer-roadmap

我就想写个网页,何必这么残忍?面对这个画面,我都有贴大哥表情包的冲动。但是我忍住,毕竟我还是想写代码来丰富我的人生的。

在 react 的生态中,我们不难发现非常优秀的项目。例如,跨组件的通信怎么办?来 redux 吧!redux 组织好复杂?上 redux-saga 吧!异步咋解决呢?来 redux-thunk 真香!使用特定 state 也挺麻烦?搞 reselect 如何!哎呀呀,还是来 rematch 或来套国产的 dva 也行……

你让我写个应用,我除了要花精力去解决打包编译工具的问题之外,还要来纠结到底要用哪个方案。真的很烦唉!其实,就像当年用 jquery 用爽了,扛起 backbone 或更狠上 angular 就开干。我写了这么多年 react,想要的是一套框架,拿过来就开撸的那种。

从 roadmap 中,我们看这个区域,也就是 react 生态的状态管理和表单数据管理这个部分。是不是复杂!很复杂!那是因为 MobX 还没有扩展开来聊。害得我又想贴表包……

我们能不能简化 react 应用中的状态管理?能不能把数据请求这块处理的更加优雅?能不能提供更靠谱的 form 模型?有的。

Nautil 框架来了!!!

一款基于 react 的 js 前端框架。在我看来,一个前端框架需要具备应用开发中必不可少的部件。而且要好用,方便开发者理解和写代码。Nautil 一次性提供体验超爽,而且还有趣的:

  • UI 渲染
  • 路由
  • 状态管理
  • 数据仓库
  • 数据类型检查
  • 跨端开发解决方案
  • 多语言国际化

让我们来举个例子,就拿复杂的 state 管理来开刀吧。想想你在以往经验里面使用 redux 是怎么用的,有没有在准备方案阶段就很纠结和心累?如果你用 Nautil,不需要纠结,因为你没得选,只有一种全局的状态管理方案。

import { Component, Store, ObservableProvider } from 'nautil'
import { Section, Text } from 'nautil/components'

// create a store
const store = new Store({
   name: 'tomy',
   age: 10,
})

class App extends Component {
  render() {
    return (
      <ObservableProvider
        name="$store" value={store}
        subscribe={dispatch => store.watch('*', dispatch)} dispatch={this.update}
      >
        <Page1></Page1>
      </ObservableProvider>
    )
  }
}

class Page1 extends Component {
  static injectProviders = {
    $store: true,
  }
  render() {
    const { state } = this.$store
    return <Section>
      <Text>Hi, I am {state.name}, and I am {state.age} years old.</Text>
    </Section>
  }
}复制代码

啥?你没看到怎么管理状态的?不怪你,因为它实在实在是太方便了,因为在 Nautil 里面,你可以没有全局的状态管理,但是你一定会有某个数据是全局的(准确的说是跨组件),你只需要用 ObservableProvider 这个组件去提供就可以了。然后在很深的组件里面去使用 injectProviders 来注入这个被提供的数据。恰巧的是,Nautil 提供的 Store 是一个可被观察的数据容器,使用 store.watch 来监听它的数据的变化,并在变化的时候触发更新操作。

还没明白?

这里的 store 就是你的状态管理器了啊!!!store 里面存着整个应用被共享的 state,你可以在任何地方去,任何地方改,任何地方删,都会通过 store.watch 的部分触发应用更新。也许你没听明白我的意思。我的意思是,你甚至可以在 react 应用之外去修改数据都是可以的,只要你在任何地方执行一下:

store.state.age ++复制代码

你的界面就会发生变化。是的,即使把你的 nautil 应用和 angular 应用混在一起,共享一个 store,也是可以的。同时,你还可以通过 watch 来收集每一次数据的变化,在必要时,把收集起来的数据通过 store.update 来复原数据。

它是不是完全超出了你对 react 状态管理的理解?没关系,还有一个东西会超出你的理解,那就是从后台 api 拉取数据。

你有没有想过,为什么那么优秀的 redux 会变得那么臃肿?因为数据是前端应用的命啊,一个不需要从后台 api 取数据的前端应用,除非是工具或游戏,否则就是没有灵魂的应用啊!所以,redux 出来之后,包括 react 本身,都必须面临异步数据请求的问题。以 react 本身而言,它一开始完全没有机制去处理,一个数据必然存在两种状态:数据还没有从后台拉回来的状态,已经拉回来的状态。在数据没有拉回来的时候,把界面显示出来,等数据回来了,再闪一下,哦豁,用户都可以化身产品经理给开发提 bug 了。

Nautil 怎么解决?

import { Component, ObservableProvider, Depository, Prepare } from 'nautil'
import { Text } from 'nautil/components'

// set data sources information
const datasources = [
  {
    id: 'articles',
    url: '/api/articles',
  },
  {
    id: 'tag',
    url: '/api/tags/{tag}',
  },
]

// create a data depository
const depo = new Depository({
   expire: 10000,
})

// register data sources into depository
depo.register(datasources)

class App extends Component {
  render() {
    return (
      <ObservableProvider
        name="$depo" value={depo}
        subscribe={dispatch => depo.subscribe('articles', dispatch).subscribe('tag', dispatch)}
        dispatch={this.update}
      >
        <Page1></Page1>
      </ObservableProvider>
    )
  }
}

class Page1 extends Component {
  static injectProviders = {
    $depo: true,
  }

  render() {
    const depo = this.$depo
    const some = depo.get('tag', { tag: 'some name' })

    return (
      <Prepare isReady={some} loadingComponent={<Text>loading...</Text>}>
        <Text>{some.name}</Text>
      </Prepare>
    )
  }
}复制代码

创建一个数据仓库来管理从后台 api 接口拉取的数据。在业务代码和后台 api 之间,不要直接打交道,而是通过数据仓库整合。业务代码,只需要从仓库中 get 数据即可,这个 get 是同步操作,不需要等待。同时,仓库是可观察的,通过一个 subscribe 方法对仓库进行观察,如果发现对应的数据发生变化,那么立即更新界面。对于仓库中还没有对应的数据时,使用 Prepare 组件来提供一个 loading 效果。

听上去好像还挺顺的对不对?但是,等等!!!我什么时候发 ajax 去请求数据?

你真的不需要关心 ajax 的问题,真的!你只要 get, get, get~ 我能理解你理解不了,只是现在。只要你用用,什么 thunk, saga, action, dispatch 统统一边去耍吧。不需要异步的好吗。

话说回来,即使有异步操作,我们还有 store,随时随地,时时刻刻,想改就改,毫无限制。

如果你再去了解一下 Nautil 的路由,你会发现一个规律:

Nautil 就是 react,nautil 不只是 react。

说的这么玄乎,意思是,它完全兼容 react 应用。比如你在其他地方写了一些纯 UI 的 react 组件,没关系,拿过来直接用。或者你想在其他的 react 应用中使用 nautil 编写的组件,没关系,直接拿去用。

你会发现,nautil 中强调“可观察的”这样一个概念。简单说就是有一个办法知道发生了变化。nautil 内置的 Observer 组件用于监听这些变化,并且在变化发生时执行传入的逻辑(一般是更新界面)。所以,在 nautil 中,数据、状态、路由都是“可观察的”对象,被注入到应用中。但本质上,它们是完全独立的,意思是,你可以在 react 应用之外的任何场景使用这些“可观察的”对象,也可以将整个体系之外的“可观察的”对象拿到 nautil 中直接使用。这也可以说是“渐进式”,可用可不用,当然,作为框架,你必须这样用才符合我写 nautil 的初衷。

不开源的都是耍流氓。

很遗憾,Nautil 到现在还没有发布。但你可以通过 github 关注或贡献代码。你也可以从 github 克隆下来跑跑看,也许会喜欢上呢~

github

最后补充一句。Nautil 还提供了内置的 Model,拥有结构化、数据校验、格式化、类型检查、可观察等特性,在表单开发时可能是你正在寻找的最好的解决方案,之一。

作者:否子戈
链接:https://juejin.im/post/5d20ce44f265da1ba328e6f7
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。