Hanxing Yang

React component [constructor](https://github.com/facebook/react/blob/master/packages/react/src/ReactBaseClasses.js#L17) 的参数，第一个是 `props`，第二个是 `context`，我不确定 `constructor(props, private _user: User) {}` 的问题会不会跟这个有关系

我们内部基于 InversifyJS 做了个跟 react 的绑定，我觉得 mobx & react 项目中引入 di 主要的工作在怎么跟 react 组件树结合，而不是怎么跟 MobX 一起工作 另外从 react 组件的角度看，通过 instance property 注入不是一个符合 react 的方式的做法，也容易有坑，所以我们后来选择通过 hook 或带 render prop 的组件来做注入了

> 其实这个 'di' 更多是解决测试上的问题，写法上更希望是 > > ``` > import s from './store' > > export default () => { > return {s.a} > } > ``` 最 naive 的方式就是这样，export &...

> 其实这个简单的做法能动态替换，只不过替换方式是用 Proxy，现在还有些浏览器不兼容而已。 那个偏 hack 了，而且那样的话还是要在这个基础上去搭建出一个与 DI 相似的能力，才能让这种替换/绑定关系可控易操作

另外去看 InversifyJS 的接口跟文档，上也让我对 DI 的认知发生了不少改变；很多 InversifyJS 的默认行为是反我们日常预期的姿势的，比如默认不 cache（transient scope 而非 singleton scope），鼓励绑定 identifier -> logic 而不是 identifier -> value，提供了很多一眼看上去不知道有什么用的能力等等

> 我自己是想着写代码的时候怎么简单怎么来。 嗯我也是这么想的，所以后来看文档的时候就很累地要去想，它为什么要做得看上去更复杂一点... https://github.com/inversify/InversifyJS/blob/master/wiki/oo_design.md https://github.com/inversify/InversifyJS/blob/master/wiki/good_practices.md 这俩篇都让我感觉学习到不少东西

哈哈我们这里大多数人相反，特别喜欢 class，主要是 decorator 用起来太爽了

@yinxulai 绝大部分情况下我们不需要手工去做绑定的事情，那样往往会要求我们直接接触 `_value` / `onChange`，所以使用 `bindInput` 或基于 `bindInput` 来实现一个合适的 bind 函数来做绑定的事情是推荐的做法； 从这个角度考虑，这里提到的提前 bind `this` 以方便直接使用 `onChange` 的收益会比较低，我倾向不做；这个 issue 可以先放一阵看看

> 1. 不应该仅从绝大部分情况&推荐做法的出发点认为的收益较低而所以不做 @yinxulai 为啥不应该.. > 2. 为什么不在可以预期的安全范围&合理的使用方式内提供使用者尽可能的自由和便利 工具做得越少，使用者越自由；工具做得越多，使用者可能越便利；这边是在权衡： * 收益：少部分 case 下的少量便利 * 代价：1. 工具本身的复杂度提升 2. 所有人群的少量自由（无法选择不 `bind` 了） > 3. 为什么不能使用很低的成本尽可能提升在 **“一旦脱离绝大部分，用不了推荐做法就会让本来轻松的事情需要额外的检查和保护”** 的情况下的开发者体验？ JavaScript 语言就是不默认 bind 的，这个不能说是用 formstate-x...

> 仔细想想这个 `onChange` 其实没有修改 `this` 的潜在需求，所以很难想到说有 "选择不 `bind`" 的情况 嗯所以是少量自由 > 仅从 `bind` 这个事儿上来说，牺牲了很少的自由或者说代价（也就是你说的无法选择不 `bind`） 主要的代价不是“无法选择不 `bind`”，是“工具复杂度的提升”（你一旦做了 `bind` 的事情，你以后就得一直保证这个） > 换来了相对更多的便利，所以权衡下来觉得还是 `bind` 更舒服。 因为我在项目里几乎没有直接 `` 这么用过，所以比较难体会这边你说的“相对更多地便利”.. 如果你的项目里确实存在不止一处这样的 case，你可以提个 PR 来加下...