Arrange

What's Code First

Mon, 27 May 2019 22:51:00 GMT

一个月前第一次看到 code first 这个关键字. 因为我一直在抄写的 nestjs 文档例子中突然多出来了这么个东西. 我偶尔看到 prisma.io 这个服务商的网站有个界面挺漂亮的博客, 里面出现了 code first 的描述.

在我习惯的网站 zhihu juejin 中, 搜索了下 code first, 要么 4 年前的回答, 要么没有.

或者试一下 quora 中搜索 ⁵

起点

nestjs 文档多出来了 code first 部分 [Nestjs:doc Graphql#code-first][^1]
Primsa Blog 三连发
1. [The Problems of “Schema-First” GraphQL Server Development][^2]
2. [Introducing GraphQL Nexus: Code-First GraphQL Server Development][^3]
3. [Using GraphQL Nexus with a Database][^4]

起手

先动手实践一下再翻译吧

所用到的核心工具 npm 包: GraphQL Nexus、type-graphql

基本操作之 mutation 之后更新 Apollo Client 缓存

Tue, 07 May 2019 22:21:00 GMT

3 个多月之前的原文: How to update the Apollo Client’s cache after a mutation

自问自疑: 怎么分页? 变量标示页面参数. 怎么处理分页缓存? 全部重置?!
期望: 了解新的分页场景处理方式.

简要译文:

The Apollo Client and its cache

Apollo Client 能对接各种 GraphQL server 取数据, 体积小, 有很多 awesome feature, 如客户端的自动缓存数据.

Apollo Client 为你自动审查 querys, mutations 的数据传递, 缓存最新的数据, 保证本地缓存最新.

A Simple update

例子, 查询所有文章

query articles {
  articles {
    id
    title
    published
    author {
      name
    }
  }
}

得到返回数据:

{
  data: {
    articles: [
      {
        id: "xxx",
        title: "TTT",
        published: true,
        author: {
          name: "yo",
        },
      },
    ]
  }
}

然后,发起一个 mutation 更改标题

// UPDATE_ARTICLE.gql
mutation updateArticle($id: ID!, $title: String) {
    updateArticle(id: $id, title: $title) {
        id
        title
        published
        author {
            name
        }
    }
}

this.$apollo.mutate({
    mutation: UPDATE_ARTICLE
    variables: {
        id: 'xxx',
        title: 'a new title'
    }
})

得到结果:

articles: [
  {
    id: "xxx",
    title: "a new title",
    published: true,
    author: {
      name: "John Doe",
    },
  },
]

mutation 成功之后, 缓存会自动更新,

因为:
1. 响应数据包含了 article id
2. 响应数据包含了 title

保持 mutation result 中有所有的用于更新缓存的必要字段, 就能自动更新缓存.
在最佳实践中, 使用 fragment 来在相关的 query、mutation 的进行定义, 正是利用了这个特性.

但, 在上例中, 更新 author name 并不能达到同样的效果. 因为 author name 没有平级的 id.
令自动 cache 特性生效, 更改 fragment 为

id
title
published
author {
    id
    name
}

Extended use cases

上面这是个理想化的场景(剧本中的场景), 实际场景远不够, 确实有很多场景,自动 cache 不能覆盖到,

如:
1. 文章创建
2. 文章删除
3. 按条件过滤的文章列表

等更多.

任何需要更新 cache 的场景, 都依赖当前的 cache.
所以有两种的方式更新缓存:

mutation 之后刷新浏览器
使用 update 方法直接操作 local cache

默认采取缓存优先策略, Apollo 推荐使用 update 方式.

Use of the update function

update 方法能任意操作 cache, 想怎么改怎么改, 改坏了没办法, 改动的逻辑有复杂度.

(PS: 的确有复杂度. 查询第 5 页,突然发起了个更新第一页某条数据的 mutation 怎么破. 不依靠自动更新缓存,apollo client 设计的操作只能在手动找到缓存的操作基础上,抽取公共操作,并不能消除操作距离. 或者有绝妙的组织方式 )

这一招很有诱惑——关闭 apollo client 默认开启的缓存, 但这绕过问题, 没正面刚, 不爽.

一起来认真对待下这个普遍存在每个人都会面对的的挑战吧

Use always a try/catch block

所有可见例子,包括 Apollo 文档, 都长得像这样:

const query = gql`{ todos { ... } }`

export default graphql(
  gql`
    mutation ($text: String!) {
        createTodo(text: $text) { ... }
    }
`,
  {
    options: {
      update: (proxy, { data: { createTodo } }) => {
        const data = proxy.readQuery({ query })
        data.todos.push(createTodo)
        proxy.writeQuery({ query, data })
      },
    },
  }
)(MyComponent)

这看起来很棒, 但还没取数据的时候会怎样, 缓存还没如预期的已存在? proxy.readQuery 会抛错,让应用挂掉.

保证理想中的代码安全执行,加个 try/catch :

update: (proxy, { data: { createTodo } }) => {
  try {
    // ...
    proxy.writeQuery({ query, data })
  } catch (error) {
    console.error(error)
  }
}

不然, 就保证查询必然存在.

这里的话,最好不要作任何假设,就像丹总(Dan Abramov)博客里写的:

We can’t predict the exact user interactions and their order. At any point in time, our app may be in one of a mind-boggling number of possible states. We do our best to make the result predictable and limited by our design. We don’t want to look at a bug screenshot and wonder “how did that happen.

我们无法预言精准的用户交互动作及交互顺序. 任何时候,我们的应用都可能在一个让我们完全蒙圈的状态. 我们尽最大努力做到结果可预测,设计引用限制可能的结果. 我们不想看到bug截图,并好奇“为什么这样”.

(PS:这段说的应该是排bug时认为我的应用绝对不可能这样的那种难以置信感)

记心里, proxy.readQuery, proxy.writeQuery 都可能抛错.
比如, 从 cache 中读一个 query 不抛错, 而写 cache 时可能因为少了一个字段抛错了. 经常漏了 __typename 抛错.

Always define the variables used in the query

设想现在需要个 mutation 创建一个被标记为已发布的 article.

通常, 基础例子有一个单 query 索取所有 article, 然后过滤出来已发布的.(比如, articles.filter(article => article.published))

简化下需求, 先假定我们有个 query 只查询已发布的 articles.

这个点上, mutation 添加新文章后, 我们需要用 published: true 读写 cache, 来匹配之前的查询:

update: proxy, { data: { createPublishedArticles } } => {
    try {
        const data = proxy.readQuery({ query, variables: {
            published: true
        }})
        data.articles.push(createPublishedArticles);
        proxy.writeQuery({ query, variables: { published: true }, data });
    } catch(error) {
        console.error(error)
    }
}

就酱, 这样的场景还可控, 因为我们只有一个 Boolean 变量. 一旦有更复杂的用例, 包括多个查询和变量, 就棘手了.

( 以上, 也是我已经体验过的东西, 希望下边能学到新东西)

Increasing complexity

目前为止,覆盖了基本场景. 开发任何应用缓存管理很快就越来越复杂.

的确, 实际写应用时, 用 apollo client 更新本地缓存几何倍变复杂, 包括多查询或涉及 apollo 内部更新不及时场景时:

对列表进行添加/删除
列表中的一条数据移动到另一个列表
更新列表筛选条件

( ~~ 分页的缓存就是更改筛选条件这个场景 )

Updating more than one query after a mutation

一般, 发起一个 mutation 之后需要更新的会是不只一条 query. 比如, 回想下我们在 dashboard 中索取了所有文章, 已发布的和未发布的在两个列表中.

Apollo client 不只把每个 query 写到 cache 中,查询变量不同,每个存一份 cache.比如:

// query 1
query articles {
    articles {
        id
        title
        published
        author {
            name
        }
    }
}

// query 2
query articles($where: JSON) {
    articles(where: $where)  {
        id
        title
        published
        author {
            name
        }
    }
}

/* 缓存里将存俩:
articles({"where": {"published": true, "sort": "asc"}})

应用变量时:
{ variables: { where: { published: true, sort: "asc" }}}
*/

预期的 query 在缓存中可能这么有两份. 当我们想查未发布 article 列表时,需要用变量额外应用 query 2, where: {published: false, sort: 'asc'}

这么做就三个缓存项了:

articles
articles({"where":{"published":true,"sort":"asc"}})
articles({"where":{"published":false,"sort":"asc"}})

为什么这么做,有必要吗?如果我们想添加一个新文章,然后想更新本地缓存,就需要读取不只一个 query,而且每个条件一遍,每套变量一遍.
像这样:

// STEP #1
// update 'articles'
try {
    const dataQuery = proxy.readQuery({
        query: getArticles
    })
    dataQuery.articles.push(newArticle);
    proxy.writeQuery({
        query: getArticles,
        data: dataQuery
    })
} catch() {}

// STEP #2
// articles({"where":{"published":true,"sort":"asc}})
try {
    const dataQuery = proxy.readQuery({
        query: getArticles,
        variables: {
            where: {
                published: true,
                sort: "asc"
            }
        }
    })
    dataQuery.articles.push(newArticle);
    proxy.writeQuery({
        query: getArticles,
        variables: {
            where: {
                published: true,
                sort: "asc
            }
        },
        data: dataQuery
    })
} catch() {}

// STEP #3 抄不下去了我
// articles({"where":{"published":false,"sort":"asc"}})
try {
    const dataQuery=proxy.readQuery){
        query: getArticles,
        variables: {
            where: {
                published: false,
                sort: "asc"
            }
        }
    }
    dataQuery.articles.push(newArticle)
    proxy.writeQuery({
        query: getArticles,
        variables: {
            where: {
                published: false,
                sort: "asc"
            }
        },
        data: dataQuery
    })
} catch(error) {}

已经看到了,这样做给每个 query/variables 组合加模样差不多的代码, 很多.

Variables’ order and values

注意下每个变量的顺序很重要.

这两个查询被认为是不同的,在 cache 中会分开存.

// calling a query
export default graphql(gql`
    query ($width: Int!, $height: Int!) {
        dimensions(width: $width, height: $height) {
            ...
        }
        ...
    }
`, {
    options: props => ({
        variables: {
            width: props.size,
            height: props.size
        }
    })
})(MyComponent)

// Calling the same query above, but different order
export default graphql(gql`
    query ($width: Int!, $height: Int!) {
        dimensions(width: $width, height: $height) {
            ...
        }
        ...
    }
`, { options: props => ({
    variables: {
        height: props.size,
        width: props.size
    }
    })
})(MyComponent)

这将造成缓存里存两份:

dimensions({"width":600,"height":600})
dimensions({"height":600,"width":600})

重新调用同样的参数,将得到另外一条缓存

dimensions({"width":600,"height":600})
dimensions({"height":600,"width":600})
dimensions({"height":100,"width":100})

要炸了,哈哈? 你看这么 naively 的就超出控制了

Edge cases

如果这还不够,再来点. 当你定义一个常规的带 variablse 的 query 时, 想一下下边场景:

query articles($sort: String, $limit: Int) {
  articles(sort: $sort, limit: $limit) {
    _id
    title
    published
    flagged
  }
}

很有可能这么用

export default graphql(
  gql`
    ${ABOVE_QUERY}
  `,
  {
    options: props => ({
      variables: {
        sort: props.sort,
        limit: props.limit,
      },
    }),
  }
)(MyComponent)

但当另外一个根本没有 variables 的对象或者空 variables,比如 variables: {}传入时. 操作变量传入可能会这样:

export default graphql(
  gql`
    ${ABOVE_QUERY}
  `,
  {
    options: props => ({
      variables: props.varObj, // props.varObj 可能为控对象
    }),
  }
)(MyCompoennt)

在缓存中这么存 articles({"sort":null,"limit":null})

当

export default graphql(gql`${ABOVE_QUERY}`)(MyComponent)

缓存中存 articles({})

上述极端场景远不是想要的场景. 举这样的例子来深化缓存的存储规则.

Moving items between cached queries

也有这样的场景:我们想 unpublish 一篇 article, 即将数据从已发布查询的缓存中移到未发布中.

一般操作,我们先保存已发布的列表,然后移除一条,最后把这一条添加到未发布中. 实现代码如下:

const elementToMoveId = '1'
let elementToMove
try {
    const dataQueryFrom = proxy.readQuery( ...已发布 )
    elementToMove = dataQueryFrom.articles.filter(item => item.id === elementToMoveId)[0]
    dataQueryFrom.articles = dataQueryFrom.articles.filter(item => item.id !== elementToMoveId)
    proxy.writeQuery(...覆写dataQueryFrom)
} catch() {}
if (elementToMove) {
    try {
        const dataQueryTo = proxy.readQuery(...未发布)
        dataQuery.to.articles.push(elementToMove)
        proxy.writeQuery(...覆写dataQuery)
    } catch() {}
}

Apollo Cache Updater

看, 覆盖常规的场景需要这么复杂的操作.

得写特别多代码, 而且很容易出错.

针对这场景, 发布了包 Apollo Cache Updater, 零配置的. 帮我管理缓存时能神志清楚.

通过 update 变量配置 mutation 结果的缓存行为.

目标是覆盖上述所有场景.

用不同的查询条件分页条件执行了多个 query 之后, 迭代传入 ROOT_QUERY 中的每个对象

Conclusions

任何语言中管理缓存都很麻烦. Apollo Client 给出很多优势, 任何场景都能手动操作. Apollo Cache Updater 缓和了下这个痛处. 期待官方给更加易用的方案.

简直了, 把我知道的苦的场景描述了一遍, 我还是不知道怎么解决

Apollo Client

Tue, 07 May 2019 22:00:00 GMT

试用了 nestjs prisma server + apollo client 的基本操作, 发现默认的 cache 阻碍了我刷新数据.
以及携带分页时, 手动更新 InMemory 数据, 以我能想象到到思路难以忍受.
想来标准到使用流程上定然有个优雅的方法, 一定有的.

Start: Cache、 Pagination

刷新到的体验一: nodeConnections, pageInfo, edges 形式存储分页信息

边阅读边点击链接:

cache

浏览方式: 快速浏览关键点:

reset cache
cache persistence
pagination
article in blog, 翻译到: 更新 Apollo Client 缓存

针对文章中的各种缓存管理复杂场景, 使用 fetchMore 能解决问题

使用 fetchMore, 按照定义的变量,将已有的缓存续起来.

根据分页机制具体做法不同

Offset-based 分页机制

通过 offset、 limit 控制分页范围

例子:

const FEED_QUERY = gql`
  query Feed($type: FeedType!, $offset: Int, $limit: Int) {
    currentUser {
      login
    }
    feed(type: $type, offset: $offset, limit: $limit) {
      id
      # ...
    }
  }
`

await this.$apollo.query({
    query: FEED_QUERY,
    variables: {...},
})

this.$apollo.queries.feed.fetchMore({
    variables: {
        offset: data.feed.length
    },
    updateQuery: (prev, { fetchMoreResult }) => {
        if (!fetchMoreResult) return prev;
        return Object.assign({}, prev, {
            feed: [...prev.feed, ...fetchMoreResult.feed]
        })
    }
})

列表中删除或者插入一个新的项时, 会造成已有分页俩表缺一条活着渲染两次. 用 cursor-base 模式能避免

Cursor-based 分页机制

就那样…

Relay-style cursor pagination

可以用到指令 @connection.

指令是什么? 我在 graphql.cn 上没看到过 @connection 呀. 哦,有指令,应该是自定义的一个指令

阅读 Apollo-Vue 中 fetchMore 部分

总结

解决了加载更多的场景, 然后跳转后两页时呢. 不考虑了

Lary's NoteBook

Tue, 07 May 2019 22:00:00 GMT

Stash

完成了基本的查询和新增操作.

部署 Docker 方式

想到了持续化集成涉及的即使,提交完代码之后,就提交完代码了
持续化部署, 又是啥? 代码提交之后,自动 build docker image?

拆分一下,

提交代码到重新 build docker image 算是持续集成
image 更新一下,算是持续化部署

持续化集成工具

jenkins
travis CI 添加 badge 的感觉真爽终端真好
netlify 终端真漂亮
circleci 终端真好构建真快

React + Apollo 2rd

Sun, 31 Mar 2019 11:40:00 GMT

prisma api 已备好

Step 1

参照之前的 hacker news 教程, 添加 graphql 相关文件

安装依赖
包裹
添加 login signup Resolver

Step 2

使用 Antd 创建登陆页面

页面组件导出变更形式,添加:

withApollo
withRouter

Step 3 Upgrade Auth

nestjs 自带有 auth 实践, 将之前教程中简单的校验更改为 nestjs 的实践

常规 auth 技巧:

Auth Service 中有一个 validateUser 用于在 guard 中检查用户是否合法

nest g guard guard/jwt-auth
nest g module auth
nest g service
nest g guard auth/jwt-auth

How to Read Document

Sun, 31 Mar 2019 11:34:00 GMT

每次使用 React 都想自己写一下自己的总结. 然而基本上自己的总结都无法超过官方文档.
该怎么办?

访问的便利性

克隆静态站点, 部署到自己可以快速访问的位置.

可行性不高, 现有网站开启 PWA 的情况下, 设备上的缓存已经足够快.

所以, 快速了解到官方文档, 是主要的起点

如何记录个人心得

个人新的应与原文档结合来看. 然后就有了这两个场景:

刻舟求剑, 通过 chrome 插件方式, 为页面添加自定义标注脚注
个人脚注管理站点,能够总揽自己的脚注. 可以在其他位置, 引用自己的脚注

Nestjs + Prisma

Sun, 31 Mar 2019 00:12:00 GMT

使用 nestjs 如何获取 prisma generate 的功能呢 ?

创建 nestjs serv 项目

nest new server

yarn add apollo-server-express @nestjs/graphql prisma-binding

touch .graphqlconfig.yml

.graphqlconfig.yml 内容:

projects:
  database:
    schemaPath: src/prisma/prisma-types.graphql
    extensions:
      endpoints:
        default: http://localhost:6644
      codegen:
        - generator: prisma-binding
          language: typescript
          output:
            binding: src/prisma/prisma.binding.ts

生成文件

graphql get-schema --project database
graphql codegen --project database

添加 graphql Module

app.module.ts 中添加

GraphQLModule.forRootAsync({
  useClass: GraphqlOptions,
})

graphql.options.ts 中定义要生成的 schema 文件路径

return {
  typePaths: ["./**/*.graphql"],
  path: "/",
  // ...
  definitions: {
    path: join(process.cwd(), "src/graphql.schema.d.ts"),
    outputAs: "class",
  },
}

添加 prisma module & resolver

nest g module prisma
nest g service prisma

nest g module posts
nest g resolver posts

nest g module users
nest g resolver users

其中,

prisma.module 添加 exports [service]
prisma service 应 extends prisma.binding#Prisma

Start to use Prisma

Sat, 30 Mar 2019 00:00:00 GMT

Booklets

Prisma Doc

Basic

基本使用

1. cli prepare

npm i prisma -g

2. docker-compose.yml

version: "3.1"
services:
  prisma:
    image: prismagraphql/prisma:1.29
    restart: always
    ports:
      - "6644:6644"
    environment:
      PRISMA_CONFIG: |
        port: 6644
        databases:
          default:
            connector: postgres
            host: db
            port: 5432
            user: postgres
            password: ******
            database: ary-serv
            migrations: true

networks:
  default:
    external:
      name: multi-compose

其中自定义了一些配置

使用了 postgres
- 自定义了端口
- 设置了数据库名
- 设置了 extenal network

启动:

docker-compose up -d

3. init prisma

prisma init --endpoint http://localhost:6644

将生成 datamodel.prisma、 prisma.yml 文件

4. deploy

prisma deploy

将连接数据库,创建数据表.

5. view

可访问 Graphql IDE (http://localhost:6644)
和 Prisma Admin (http://localhost:6644/_admin)

prisma 提供的 admin 面板,能够更方便的显示、添加、修改数据

Datamodel

Prisma 数据模型机制

1. 更改 `datamode.prisma` 文件

type User {
  id: ID! @unique
  email: String @unique
  name: String!
  posts: [Post!]!
}

type Post {
  id: ID! @unique
  title: String!
  published: Boolean! @default(value: "false")
  author: User
}

通过 posts, author 将两表进行关联.

2. 更新表结构

重新执行 prisma deploy, 即可

3. 生成客户端代码, 使用 prisma api

执行 prisma generate, 将自动生成客户端代码

4. 体验 datamodel

对比自己写的 resolver, 体验 prisma 中不同场景处理, 其处理方式有很多可学习之处. (elegance)

4.1 关联创建时, 如何处理?

mutation {
  createPost(
    data: {
      title: "风乎舞雩"
      published: true
      author: { connect: { email: "songlairui@qq.com" } }
    }
  ) {
    id
    title
    published
    author {
      name
    }
  }
}

其中 author 字段为 Post 表关联的 User 表数据字段, 此处有 create, connect 两个传入属性, 对应,关联创建数据和关联已有数据的场景

4.2 更改数据

mutation modify {
  updateUser(
    data: { email: "songlairui@qq.com" }
    where: { id: "cjtstpc2h000m0760km52wmyv" }
  ) {
    id
    email
  }
}

其中, payload 中定义 data where 两个属性, 分离数据与条件

4.3 支持嵌套数据?

{
  users {
    name
    posts {
      author {
        name
        posts {
          title
        }
      }
    }
  }
}

默认支持, 观察创建的数据表, 多出了多个下划线开头的表, 记录了关联关系

思考

:::
prisma 自带了一个 prisma generate
那么,在 nestjs 中,这个generate 代码怎么使用呢?
:::

start react-apollo tutorial

Sun, 24 Mar 2019 00:00:00 GMT

关联:

TODO: MicroSoft TODO Item
StickyNote: MicroSoft StickyNote Item

教程网址: https://www.howtographql.com/react-apollo/1-getting-started/

Steps

安装依赖
配置后端, Prisma docker 文档
- 配置本地 postgres docker
- 配置 prisma docker
- 运行 yarn prisma deplpy
  出现交互提示

如何自己做一个命令行交互提示? 得到使用的库之后, 如何使用得到的配置?

… fail to record my acivity

Finished the tutorial

I learned:

Query 查询
- List 数据列表
- Search 根据条件查询数据
Mutation 变更
- Create 创建数据
Authentic 认证
React
- Routing 前端路由
- withApollo 包裹组件
Pagination 分页
apollo-client cache 客户端缓存
Docker
- prisma deploy
pgsql
- psql
- schema: default$default
graphql-server
- resolver

我的提交记录:

16aef65 (HEAD -> master) update local cache update
45024ff 添加分页
9ccedcf ignore webpack global version
f77ba36 添加 subscription
9d22def 添加 filter
cd8347c 添加 Votes Mutation 以及本地 updateStore
80d9680 add apollo-client auth header
3e94ad0 add login & signup
117fdeb add login dom
1e7055b link after action
a3d405e add route
c912baf react query links, create links
8423958 Initial commit from Create React App

个人感想

此前看 graphql 官方教程,看完了一遍,缺少实践,难以融会. 跟着教程走完一遍, 会用新轮子了.

坚持使用, 会自然而然得到更多领悟.

再一次回顾

安装依赖

based on create-react-app

yarn add apollo-boost \
         apollo-cache-inmemory \
         apollo-link-ws \
         apollo-link-context \
         graphql \
         graphql-tag \
         react-apollo \
         react-router \
         react-router-dom \
         subscriptions-transport-ws \
         antd

包裹 `<App/>`

ReactDOM.render(
  <BrowserRouter>
    <ApolloProvider client={client}>
      <App />
    </ApolloProvider>
  </BrowserRouter>,
  document.getElementById("root")
)

其中 client 的 link 参数,传入了 api 来源

split[‘wsLink’, [‘authLink’, ‘httpLink’]]

To Use Lerna

Wed, 20 Mar 2019 00:00:00 GMT

npm set registry https://registry-npm.mypaas.com.cn
npm adduser —registry https://registry-npm.mypaas.com.cn

target 1: side depends

Resolve with alias within symlink

Tue, 19 Mar 2019 00:00:00 GMT

Excertps

moduleA.js and moduleB.js has the same content as below, but located in different symlinked dir.

import Vue from "vue"

export default Vue

Then, import the two module in one file as below, the dest module is 'vue'.

assert

import a from "moduleA"
import b from "moduleB"

console.log(a === b) // false

The result is false

This is euqal to

import a from "/home/me/projectA/node_modules/vue"
import b from "/home/me/projectB/node_modules/vue"

console.assert(a === b, "the two vue not equal")

Use Gatsby

Sat, 16 Mar 2019 00:00:00 GMT

trying to be ac with Graphql and React

targets

react eco pkgs

following

Interesting Nodes
zhihu
hashnode

commands

gatsby new blog
ossutilmac64 cp -r oss://xxx
certbot renew

deployment

what strategy to choose for site deployment

now:

static files with index.html on ali-oss
apis no
deploy flow: laptop

Since the domain was redirected to oss, no api address would be provided by the main domain, then all the api will use in the main page should have a cros header.

the flow was stucked several seconds, for the ossutilmac64 executing.

But, this strategy would give me the most speed for visiting the site Content.

wanna to trace

a short video saw
- https://www.youtube.com/watch?v=v-01hEYF-RQ
- https://www.youtube.com/watch?v=ka2AwSuOTpI
a open course saw
- https://open.163.com//movie/2018/8/Q/R/MDPBV80UO_MDPBVMKQR.html
- a TED
a good answer
- https://www.zhihu.com/question/314500394/answer/618136109
my comments,
- on juejin
- on zhihu
my game achievement
- mobile PUBG

configurable

with antd
- custom style All vars in default.less, theme customize

{
  "@line-height-base": "1.75",
  "@font-size-base": "16",
  "@font-family": "'Merriweather','Georgia',serif",
  "primary-color": "#639",
  "link-color": "#537",
  "border-radius-base": "2px",
  "@text-color": "rgba(0, 0, 0, .9)"
}