就问几点

[Lizhooh]

1、可预测？怎么预测。
2、高性能？挂载了这么多东西，谈何高，有本事给出测试报告。
3、依赖标记，引用收集？体现在哪里，怕不是 ppt 库。
3、min size 24k，敢看也不敢用。

[fantasticsoul]

1、可预测？怎么预测。
2、高性能？挂载了这么多东西，谈何高，有本事给出测试报告。
3、依赖标记，引用收集？体现在哪里，怕不是 ppt 库。
3、min size 24k，敢看也不敢用。

你好，非常欢迎你提的issues，针对你的疑问我都可以逐个解答，希望能够给你解惑。

1，concent依然是经典的flux架构实现，但是不在局限于dispatch，setState已经被接管，所以应用的任何修改state的操作都是要经过concent core的，那么可预测当然是理所当然的了，对吗？
查看此live-demo，注意右上角的开启状态调试工具按钮，你的所有动作都被记录。
live-demo
当然你也可以使用redux-dev-tool来追踪状态变迁

2， 挂载了这么多东西？这一点我不知你是怎么理解的，每一个组件实例注入一个上下文对象ctx，ctx下面就是一些简单的属性和方法，何来这么多？如果注入一个属性算多的话，那么为了使用fiber架构而给每一个实例挂的fiberNode对象是不是算巨大了？

3，依赖标记，体现在register 的watchedKeys参数里，不设定的话默认就是观察所属模块的所有statekey的变化，为了让你理解watchedKeys，我写了个在线demo
watchedKeys demo
引用收集发生在组件实例化后首次渲染前

4 ，关于高性能和引用收集更多相关信息，请查看高性能演示
concent设计理念

最后，那个徽章有问题，实际minzip后有18k，而且代码里有太多的错误文案提示log，这些log后面会统一抽过一个code同时给一个链接让用户具体查看错误含义，去掉这些文案log后，minzip后有13k左右，如果你觉得13k也太大，你得权限下concent带给你的收益再来看包体大小，concent是一个可预测、零入侵、渐进式、高性能的增强型状态管理方案，携带computed, watch, effect, setup, lazyDispatch, renderKey, delayBroadcast等特性，统一了组组件和函数组件的编码思路，如果这些都不是你care的，你可以了解omis类似的1kb方案，only 状态管理。

你可以通过在线示例列表了解更多，同时如果你对性能还是有质疑，强烈建议用cra引入concent试一试，哪怕是了解这种弱入侵的代码风格，彻底的函数式带来的魅力。

在性能上concent是做了大量工作的，无论是dom层级还是渲染触发时机，这一点毋庸置疑，不是所谓的ppt。

如果还有什么疑问，欢迎随时提出来，concent已在内部项目生产环境使用，作为个人开发者最大的欣慰就是有朋友提出issue，这至少说明有人关注有人了解有人质疑，而不是一个僵尸项目。

[Lizhooh]

ok

[ks-stack]

1、可预测？怎么预测。
2、高性能？挂载了这么多东西，谈何高，有本事给出测试报告。
3、依赖标记，引用收集？体现在哪里，怕不是 ppt 库。
3、min size 24k，敢看也不敢用。

你好，非常欢迎你提的issues，针对你的疑问我都可以逐个解答，希望能够给你解惑。

1，concent依然是经典的flux架构实现，但是不在局限于dispatch，setState已经被接管，所以应用的任何修改state的操作都是要经过concent core的，那么可预测当然是理所当然的了，对吗？
查看此live-demo，注意右上角的开启状态调试工具按钮，你的所有动作都被记录。
live-demo
当然你也可以使用redux-dev-tool来追踪状态变迁

2， 挂载了这么多东西？这一点我不知你是怎么理解的，每一个组件实例注入一个上下文对象ctx，ctx下面就是一些简单的属性和方法，何来这么多？如果注入一个属性算多的话，那么为了使用fiber架构而给每一个实例挂的fiberNode对象是不是算巨大了？

3，依赖标记，体现在register 的watchedKeys参数里，不设定的话默认就是观察所属模块的所有statekey的变化，为了让你理解watchedKeys，我写了个在线demo
watchedKeys demo
引用收集发生在组件实例化后首次渲染前

4 ，关于高性能和引用收集更多相关信息，请查看高性能演示
concent设计理念

最后，那个徽章有问题，实际minzip后有18k，而且代码里有太多的错误文案提示log，这些log后面会统一抽过一个code同时给一个链接让用户具体查看错误含义，去掉这些文案log后，minzip后有13k左右，如果你觉得13k也太大，你得权限下concent带给你的收益再来看包体大小，concent是一个可预测、零入侵、渐进式、高性能的增强型状态管理方案，携带computed, watch, effect, setup, lazyDispatch, renderKey, delayBroadcast等特性，统一了组组件和函数组件的编码思路，如果这些都不是你care的，你可以了解omis类似的1kb方案，only 状态管理。

你可以通过在线示例列表了解更多，同时如果你对性能还是有质疑，强烈建议用cra引入concent试一试，哪怕是了解这种弱入侵的代码风格，彻底的函数式带来的魅力。

在性能上concent是做了大量工作的，无论是dom层级还是渲染触发时机，这一点毋庸置疑，不是所谓的ppt。

如果还有什么疑问，欢迎随时提出来，concent已在内部项目生产环境使用，作为个人开发者最大的欣慰就是有朋友提出issue，这至少说明有人关注有人了解有人质疑，而不是一个僵尸项目。

你好，我想问下，在redux是通过mapStateToProps来控制组件上接受那些数据，从而实现无关数据是的变化不会让组件发生渲染。请问concent是怎样做的呢？是自动的吗？每个组件内的this.ctx只包含当前组件用到的数据吗？

[fantasticsoul]

在2.0版本里，concent启用proxy特性，做到了运行时的依赖收集，以便确保组件最小粒度的更新，更多细节可参考下面文章
redux、mobx、concent特性大比拼, 看后生如何对局前辈

Concent 2.4发布, 最小粒度观察与渲染组件单元

ctx包含什么数据取决于你定义组件属于什么模块或者连接了其他什么模块

@register('login')
class Demo extends React.Component{
    render(){
         const loginState = this.state;
         // or
        // const loginState  = this.ctx.state;
   }
}

@register({connect:['foo', bar]})
class Demo extends React.Component{
    render(){
         // 获得 foo模块 bar模块 state
         const { foo, bar } = this.ctx.connectedState;
   }
}

[ks-stack]

在2.0版本里，concent启用proxy特性，做到了运行时的依赖收集，以便确保组件最小粒度的更新，更多细节可参考下面文章
redux、mobx、concent特性大比拼, 看后生如何对局前辈

Concent 2.4发布, 最小粒度观察与渲染组件单元

ctx包含什么数据取决于你定义组件属于什么模块或者连接了其他什么模块

@register('login')
class Demo extends React.Component{
    render(){
         const loginState = this.state;
         // or
        // const loginState  = this.ctx.state;
   }
}

@register({connect:['foo', bar]})
class Demo extends React.Component{
    render(){
         // 获得 foo模块 bar模块 state
         const { foo, bar } = this.ctx.connectedState;
   }
}

如果链接了一个模块，整个模块的数据都会在this.ctx里面吗

[fantasticsoul]

是的，你按需获取就好了，获取的时候就产生了依赖。

[ks-stack]

是的，你按需获取就好了，获取的时候就产生了依赖。

意思是虽然this.ctx里面有注册的整个模块的数据，但是不使用的话，是不会产生依赖的对吗？如果是这样的话，可以直接把所有模块都放在this.ctx里面吗

[fantasticsoul]

没有必要，2个原因
1 因为普通对象转换为proxy虽然代价小，但是为每一个实例转换所有所有模块的数据，积少成多就浪费很多性能了

2 模块是可以运行时动态添加的，作为数据消费方的组件，声明好连接的模块，有利于ts推导和代码维护。

如果真的需要连接所有模块，可以举一个具体场景我们探讨下