Randy djyde

Conventions help you write less code

做开源项目和企业项目不同的地方在于，前者的目标是在封装的同时，尽量去保持灵活性和可扩展性。这是一种开闭原则——对实现封闭，对扩展开放。这使得开源库/组件可以适用所有场景。

然而在设计可复用的业务组件时，我们通常考虑的是，该组件在复用时能不能尽量少写代码？

这里所指的代码，就是通用的基础组件为了遵循开闭原则而留待业务方自己实现的逻辑。举个例子，我们在 ant design 基础组件的基础上，试图把 Form 和 Table 组合为一个解决「对数据进行条件查询、展示、操作」的高层业务组件。

在设计这个组件时，如果我们希望这个组件适合所有场景，我们需要使以下几点具有可扩展性：

在过去的几年，不论是面向内部的系统，还是面向外部的产品，我们都大量地使用了 Ant.Design —— 一个基于 React 的 UI 组件库。

在做内部系统时，Ant.Design 解决了几乎 60% 的问题。剩下的问题在业务逻辑和代码组织的复杂度。我见过很多内部系统因为滥用状态管理而使代码变得复杂，他们之所以使用状态管理库，并不是因为应用的状态复杂，而是因为需要一个状态树来管理网络请求的状态、接口返回的数据等等这些和接口相关的状态。

真的需要状态管理库吗？在之前，我没有信心回答这个问题。但在使用了 GraphQL (Apollo) 后，我确信，在大多数场景，你不再需要状态管理。

这篇文章的目标就是让你认识 GraphQL / Apollo, 以及在 Ant.Design 里如何高效地使用他。你不必担心 GraphQL 会给你带来负担，学习和使用 GraphQL 都是令人愉快的过程。你会发现以往让你感到厌烦的需要重复编写的逻辑，可以不必再写了。

Keep frontend code lean and straight.

$ yarn add glob

const prisma = singletonSync('prisma', () => {
  return new PrismaClient()
})

mkdir dbdata

	import cans, { inject } from 'cans'
	import { observable, action } from 'cans/mobx'
	import { BrowserRouter, Route } from 'cans/router'

	const app = cans()

	// model
	app.model({
	namespace: 'counter',
	observable: observable({

	// get current document title and url and transform to Roam

	const copyToClipboard = str => {
	const el = document.createElement('textarea');
	el.value = str;
	el.setAttribute('readonly', '');
	el.style.position = 'absolute';
	el.style.left = '-9999px';
	document.body.appendChild(el);
	el.select();