React + GraphQL 技术调研
-
一切都是模块不需要手动声明导出和引入,这是 JS 的痛点
open data; let typeDef = {| type Author { id: Int! firstName: String lastName: String posts: [Post] # the list of Posts by this author } |} type resolvers = {. "posts": Js.Array.t(post)}; let resolvers { "posts": {author: Data.author} => Js.Array.filter((post) => post##authorId === author##id, posts) };
open
类似 js 中的 import,定义 graphQL 类型时,graphql-tools 允许通过[Post]的语法将文章对象关联到作者
-
reason 中,一切类型都是 immutable 的, 通过直接修改
post.votes
则会报错:Mutation: { upvotePost: (_, {postId}) => { const post = find(posts, {id: postId}); if(!post) { throw new Error(`Couldn't find post with in ${postId}`); } post.votes += 1; return post; }, },
-
可以通过
ref
告诉编译器,votes 可能是 mutable 的type post = {. "id": int, "authorId": int, "title": string, "votes"; ref(int) };
-
- 前后端沟通成本一直是个问题, 对接口查询平台的想法一直都有
- 解析后端代码,工量较大,对于字段的格式规范不友好,对于分批次接入录入方案虽然可行,但是后续代码会导致平台与实际接口不一致,有些甚至绕过接口录入导致接口游离平台之外,不利于聚合管理
- 先通过 mock 平台联调,然后再读 mock 平台数据,生成接口列表同样存在后端代码导致 mock 结构过期的问题
- 后端采用 gql 成本小,类似
apllo-server
等框架做到了 IDE 供查询实体,同时绕过接口直接暴露数据,效率更高,其二做到代码变动后文档实时同步,只要后端代码更新,文档自动更新 - 但是如果后端代码不在前端的团队来说,后端改造适应 gql 这是第一步要做的事情,如果搭建 node 版的 graphql 桥梁,还要考虑衔接问题, 不是第一手的后端代码使用后对数据模型更改效果一般,还是会存在上面的问题
let component = ReasonReact.reducerComponent("Greeting");
let make = (~name, _children) => { // ~name: Label Arguments 写法
...component,
initalState: () => 0, // state is an int
render: (self) => {
let greeting = "hello" ++ name ++ "you click an button" ++ string_of_int(self.state) ++ "time(s)";
<div>{ReasonReact.stringToElement(greeting)}</div>
}
}
- 除了类型提示支持模式匹配(TS 也做到了)比较完美, 其他和 redux 没啥区别
- graphql 是很惊艳,但是不配合应用到后端第一手代码而是作为一个桥接中间件的话没啥用
- reason 比初版 react + redux 强太多, 但是跟现在的前端生态链 react+typeScript+redux 相比,唯一惊艳的地方就是对
ocaml
用户较为友好,另外对于支持 Assembly 编译之后,这一类语言更加趋同了,对比之下 ts 更适合用于生产环境。