loading state for stage/panel/runner

[ComfyFluffy]

• add loading for runner
• loading for sprites/sounds in panel
• stage loading

[ComfyFluffy]

#442

[ComfyFluffy]

这里还是使用spread的写法，目的是watch sprites的增加/删除/替换，不关心sprites内部的更改。

[ComfyFluffy]

把context的map替换为通过props传递，考虑到只会传递一层。

类型使用Map<Sprite, boolean>，这样子rename不会影像loading状态。

[nighca]

这里还是使用spread的写法，目的是watch sprites的增加/删除/替换，不关心sprites内部的更改。

你如果不把 SpriteItem 那边的

onCleanup(() => spritesReady.delete(props.sprite.name))

删掉，这里不就不需要这段逻辑了吗..现在看起来不仅代码变复杂了，而且对于 sprite ready 的维护逻辑也被拆分到了多处？

把context的map替换为通过props传递，考虑到只会传递一层。

这个没问题

类型使用Map<Sprite, boolean>，这样子rename不会影像loading状态。

本来应该也能正确处理 rename？我记得我特地测试处理过

依赖引用比较而不是数据比较来区分业务概念可能会有潜在的风险，比如我们从同一份数据恢复两次（构造 model 实例）的话，这边的状态就很可能会丢（虽然数据没变，但是 model 实例的引用可能变了）；这个也是我在 EditorContextProvider.vue 那边把 selectedSprite 信息从记名字改成记引用后，注释 TODO: consider moving selected to model Project 的原因

“从同一份数据恢复两次”这样的事情在我们后边支持类似 undo/redo 这样的功能的时候会很容易遇到

所以如果不是必要的话，我不建议去依赖引用比较，而是尽量依赖业务数据的比较

[ComfyFluffy]

忘记说了，之前的onCleanup在我测试的时候好像不会执行，所以不会在删除Sprite时自动更新map，才改成了不用onCleanup而是手动维护，暂时没细看原因。我再测试一下。

[nighca]

OK

之前的onCleanup在我测试的时候好像不会执行

这个确实不是预期的

[nighca]

不知道跟这个有没有关系：现在是

onCleanup(() => spritesReady.delete(props.sprite.name))

而不是

onCleanup(() => spritesReady.delete(name))

在执行回调的时候 sprite.name 已经变更了，所以 delete 的是新的 name 而不是老的 name？

[ComfyFluffy]

试了下应该不是这个原因：

watchEffect((onCleanup) => {
  const spriteName = props.sprite.name
  onCleanup(() => {
    props.spritesReadyMap.delete(spriteName)
  })
}

之前是在改成props传递map之前测试的，应该没修改sprite.name，也是不行的

[ComfyFluffy]

把第一个onCleanup拆出去单独的watchEffect就行了，拆出去应该也更合理，会只在卸载组件时删除

[nighca]

把第一个onCleanup拆出去单独的watchEffect就行了

嗯这个改动本身没问题

我试了一下，好像之前行为不负预期是因为一个 watchEffect 里的 onCleanup 只能被调用一次..第二次调用 onCleanup 传入的 cleanup 会把第一次 onCleanup 传入的给冲掉..即

watchEffect((onCleanup) => {
  onCleanup(fn1)
  onCleanup(fn2)
})

在 clean up 的时候，这里只有 fn2 会被执行，而 fn1 不会

我之前没有意识到是这样的..

[nighca]

一个 watchEffect 里的 onCleanup 只能被调用一次..第二次调用 onCleanup 传入的 cleanup 会把第一次 onCleanup 传入的给冲掉..

文档没找到相关的说明，只找到个 issue vuejs/core#3341

[ComfyFluffy]

目前测试过：增加/删除 Sprite，重命名，限流并测试载入。

[nighca]

这里还是使用spread的写法，目的是watch sprites的增加/删除/替换，不关心sprites内部的更改。

你如果不把 SpriteItem 那边的

onCleanup(() => spritesReady.delete(props.sprite.name))

删掉，这里不就不需要这段逻辑了吗..现在看起来不仅代码变复杂了，而且对于 sprite ready 的维护逻辑也被拆分到了多处？

把context的map替换为通过props传递，考虑到只会传递一层。

这个没问题

类型使用Map<Sprite, boolean>，这样子rename不会影像loading状态。

本来应该也能正确处理 rename？我记得我特地测试处理过

依赖引用比较而不是数据比较来区分业务概念可能会有潜在的风险，比如我们从同一份数据恢复两次（构造 model 实例）的话，这边的状态就很可能会丢（虽然数据没变，但是 model 实例的引用可能变了）；这个也是我在 EditorContextProvider.vue 那边把 selectedSprite 信息从记名字改成记引用后，注释 TODO: consider moving selected to model Project 的原因

“从同一份数据恢复两次”这样的事情在我们后边支持类似 undo/redo 这样的功能的时候会很容易遇到

所以如果不是必要的话，我不建议去依赖引用比较，而是尽量依赖业务数据的比较

[qiniu-ci]

The PR environment is ready, please check the PR environment

[Attention]: This environment will be automatically cleaned up after a certain period of time., please make sure to test it in time. If you have any questions, please contact the builder team.