前端的小伙伴进来

无论如何，支持一下

大概看了一下，前端与 Active Record 相关的类库不太多，想法很棒。

一直觉得前端没有一个好的本地数据模型，在前端实现 Active Record 某些场景下对数据的处理逻辑可能会更清晰一点，期待能够实现 Relation 部分（ hasOne，hasMany ）。

具体使用场景有什么呢

@zitup 你好，关于使用场景，可以看一下这一节：[开发理念]( https://github.com/yetrun/ar-front#%E5%BC%80%E5%8F%91%E7%90%86%E5%BF%B5).

@ss098 Relation 部分我目前还没太想明白，主要是后端接口太五花八门了，没有一套统一的标准。怎么统一定义和实现它还没想好。

graphsql?

唉，复杂度哪怕增加一点点都没动力。前端复杂度现在已经够呛了。

想法不错，相当于把页面的 api fun 封装到 api 里面了，但是感觉带来复杂度比收益更大

已赞

感觉很有趣啊，文档也写的很好，赞一个

@shadowfish0 Thank you

@qin20 不是 GraphQL

@molvqingtai 如果有时间的话，我去整个示例，会更清楚点

TS 支持呢？

理念和实现都很棒，感觉也有一些潜力，但是对 extend 里的 Vue 风格实在是喜欢不起来。。。

一些建议：
1. TypeScript 支持，仅我个人而言，没有 TS 支持的库项目我都不会尝试；
2. attribute 里的 type 能不能换成 enum，用原生类型感觉会限制当前的实现，比如可以内置实现 ref：Car{ brand, color }, User{ car: Ref(Car) }。可能也限制了用户可能需要的动态扩展能力，比如自行扩展成 UUID，BigNumber 等；
3. 实例方法里的 this 看的我很慌，如果想写成箭头方法咋整？
4. 实例方法里，能不能做到只需要 return data，不用手写 this.attributes = data ？
5. User 提供一个构造参数应该灵活一点: const user = new User({name, age})，实例里没提供这种用法，提供一个 object 的写法不容易漏属性；
6. this.attributes = data 的具体作用是啥？如果把 save 实现在静态方法里：save(user) {}，看起来也是可以的，这样是不是就既可以使用箭头方法，又不需要写 this.attributes = data ？

支持，感觉在某些场景会很有用

这些貌似 mobx/dva/rematch/recoil 这些都能做到啊。。

@shunia 你的每个建议都挺好的，我会在后续的版本里考虑添加进去。由于你提的问题有些多，我还是一个一个来回复，一个问题没弄清楚之前就不继续回答另一个了。

我按照回复起来从简单到难的顺序。5 和 6 可以一起作答。const user = new User({name, age}) 这种形式，嘿嘿，有的，文档开头的示例也有提到。这里就带来了 `this.attributes` 的用法了，你看看能不能接受。

批量设置属性有两种形式，第一种是通过构造函数：

const user = new User({ name, age })

第二种是先从某处获得了模型实例，然后再批量设置属性：

const user = User.find(id)
user.attributes = { name, age }

其实 this.attributes 就是 user.attributes 了，只不过是用在方法里，引用实例要用到 this.

另一个问题是 save 实现在静态方法里，由于我所做的只是薄封装，具体实现还是需要用户自己来的，所以将 save 实现在静态方法是可以的，像这样

static: {
async save (user) {
const attrs = await axios.put('/user', user.attributes)
return new User(attrs)
}
}

与实现为实例方法的比较

actions: {
async save () {
const attrs = await axios.put('/user', this.attributes)
this.attributes = attrs
}
}

以及它们的调用比较：

static => User.save(user)
instance => user.save()

我个人是倾向于后者了。至于每个人具体用哪种，见仁见智。

后端的 Active Record 其实是减少了代码量，降低了复杂度。前端搞这套好像反倒增加了工作量及复杂度，相比增加的工作量和复杂度，带来的优势好像没有很明细

@hhjs 由于现在实现的功能有限，所以几乎没有带来额外的复杂度。因为前端至少需要组织调用 API，不大可能在视图组件里充斥着各种 axios 调用，除非项目小到没几个接口要调的程度。既然都已经在组织 API 了，何不尝试一下用库简化工作量，并且还能带来额外的功能呢？

如果觉得复杂了，问题可能出现在两点：

1. Model.extend 语法让人感觉不自然了。用 Model.extend 是一来是迫不得已的选择，要考虑到实现的干净而没有考虑调用的自然；另一来是与 Vue.extend 很像，我原以为大家会接受这种方式。
2. 我的文档写得不够好，让人觉得复杂了。

我想问题可能出现在一吧。

很多年前的 https://github.com/FacultyCreative/ngActiveResource 搭配 Rails 那是真好用。

@phpuser 赞一个，那年的 Angular 是真的火

感觉有点意思,已 star,我们也有做对 restfulApi 接口的封装,只是针对增删改查,没有你这么复杂

@luxTao 感谢关注

直接 start 毫不吝啬