virgo
virgo
> > > 补充一下，如果是这种状态基本判定无法大规模使用，只能做局部模块缓存使用。 以 #5 这个 issue 大概率是一个问题。 > > > > > > 5 4 如果默认motionLeave为true的话，会默认走一遍动画流程，看下是否可以关闭 > > 我昨天也看了源码，大概率不能这么搞，大概率是生命周期的问题： > > 那么如果不用Activity，直接用DIsplay: none 的方式会不会也有这个问题呢？显然，没有这个问题。 > > 导致这个问题的主要原因还是生命周期，没有执行 effect...
路由的话需要修改react-router了
I've reviewed the original PR. Regarding the issue with `use`, could we maintain a `ThenableList` on the Suspense fiber? We would always throw the first unresolved promise until it is...
or like this ```typescript {(isSuspend) => ( )} ``` even though I really hate it, I also don't want to do it this way.
> ci 挂了 fixed 少个包
> 收起动画丢了。 我在想有没有必要开个discussion讨论下这个问题 改造前开闭实现其实是利用content的`height`值变化来实现的，本质上是没有`open`状态的 改造后基于details的实现其实是有`open`状态的，即content的可见性是有`open`决定的，而不是content的`height`值 因此改造后的渲染流程如下 open = true时，content展现，然后高度过渡 open = false时，content隐藏，此时动画不可见 所以我觉得需要讨论下这部分的实现，我先说下我的想法 1. 渐进式增强，对于高版本浏览器，移除`CSSMotion`，使用`::details-content`实现展开关闭动画，对于不支持的，使用`CSSMotion`实现展开动画 2. 内部再维护一个动画状态，拦截details的点击事件，优先改变动画状态，待动画执行完毕再改变open状态 个人上是更倾向方式1，这样的话，在高版本浏览器中，组件将变得足够简单，性能也将更上一层楼，仅做状态同步即可
> 1 可以的，我也倾向渐进式。  新增渐进式处理，为false则回退至CSSMotion，但这里存在一个问题，走服务端渲染时，会存在两端不一致的问题，有什么建议？  动画实现可以参考
或许可以移除CSSMotion，根据是否支持`::details-content`伪元素将motionName设置到details元素或者``上
> 有冲突 fixed
@supnate Please review this PR if you have time.