xcodebuild/overdom

A tiny view library with JSX, mutate(data) = mutate(DOM).

overdom's Issues

ref.current

我回来了！我发现有人，只使用 ref，而不使用 reactive

https://github.com/pago/reactive#why-refcurrent-instead-of-refvalue

也就是说，模拟不支持 Proxy 的嵌套，但是默认使用 ref 的话，用户就会主动感知到，然后主动加 .value

另外我发现，这里的 diff 算法有优化空间：https://github.com/xcodebuild/overdom/blob/master/packages/overdom/src/directive.ts#L120

noneed Proxy apply

这组 API 不需要 Proxy 就可以做到

比如脏检查：https://github.com/yisar/dirty-check

比起 Proxy apply，脏检查的内部实现会精彩一些，但是单纯从 API 来说，其实都有点丑，而且语义也不好

但是不管怎么说，我个人不喜欢将这个思路用于 jsx……

jsx 这种偏 runtime 的 dsl，怎么写怎么憋屈

Class-based API

Funtional API

Funtional API 存在不小心解构 props 后无法响应的问题，见 #2 中的讨论

const Count = ({ count }) => {
  const state = reactive({
    get double() {
       return count * 2; // 无法 reactive
    }
  });
  return <div>{count}</div> // 这里消费了，所以不会再报错
}

Class-based API

如果基于 class 重新设计 API 可以规避上述问题：

class Count {
  @reactive props;
  @compute get double() {
    const {
     count,
    } = this.props; // 这样解构没有问题，因为是以函数为维度响应的
    return count * 2;
  }
  render() {
    const {
     count,
   } = this.props; // 同样的没有问题
    return <div>{count} {this.double}</div>;
  }
}

关于逻辑组合方面可以考虑用实例化的方式组合

class NewCount {
  count: new Count();
  render() {
    return <div>{this.count.double}</div>
  }
}

优缺点

优点

• 规避解构带来的不直观的响应式丢失问题（而且该问题不易完整检测）
• decorator 能提供的 API 更直观和灵活，避免通过其他方式引入语法糖

缺点

• 生成代码体积相对较大，uglify 不易压缩 class 属性
• 代码相对来说繁琐一些