by90 / iconnect Goto Github PK

这里可以借鉴处理json的方式。

如果model重写了相等逻辑，则：
即使dispatch，若model没有改变，也不需要重新build
这里亦可考虑，监听部分内容，但我们既然用于处理了不同model，对监听者就无法进一步细化。

这样的好处是进一步提高性能

通过fromjson和tojson处理，注意null问题
暂时考虑使用sqflite？或者drift？或者hype？实际上服务端也是一种方式。

不再使用内置的asyncSnapshot，而是使用futureBuilder和streamBuilder
这需要修改model和counter实例
这里是手工bloc的教程，包括窗体验证、登录、比较密码、购物车等场景，比较老的。
https://juejin.cn/post/6844903812063297544
注意我们不要引入实践概念，ui到bloc只是dispatch即可。

https://www.raywenderlich.com/31973428-getting-started-with-the-bloc-pattern
这里也是手工处理，其中提到了每次刷新bloc重新载入一遍的问题，它使用rxdart解决。
它是简单的文章列表。

登录、列表、窗体验证、进度等....bloc包的场景十分丰富。
另外一些例子：
比如缓存：https://pub.dev/packages/flutter_cache_store

https://www.raywenderlich.com/31973428-getting-started-with-the-bloc-pattern
这里也是手工处理，其中提到了每次刷新bloc重新载入一遍的问题，它使用rxdart解决。
它是简单的文章列表。

默认情况下，store以类型作为键，实例作为值，这种方式仅可访问唯一的model，不支持多个实例
考虑一个type形式的map，一个string形式的map
当然这对持久化不利...因为type访问没有key，可暂时以type.toString,也就是类名取代。

目前是简单的使用provider.of
可考虑使用bloc方式监听？
作为核心功能的listen和dispatch，需要仔细的权衡。

现行的函数直接通过mixin附着在model上，这样使用model无需import iconnect。

提供默认的，但同时要能修改行为，根据asyncSnapShot

使用Store.add<>这种方式。启动时处理。
由此定义model即可，无需同时定义全局变量和register