不使用 react-router ，使用状态管理如 zustand 之类，把数据获取和对数据的二次加工等放进去也是个不错的选择。

而且和楼主相反，我跨端的时候反而越来越重原生了…… 虽然部分地方我会用 ReactNative 来节省工作量，但更多的东西我现在愿意用原生了。

原生还是稳，想做什么都可以。

我觉得 Taro 都更香一些，反正现在的 Taro 支持 React 和 Vue3 。

跑个题（也没跑太远），我看很多人会提到一个事，无论是讨论键盘布局，还是讨论自定义快捷键，或者说是讨论比如 hhkb 之类的键盘把 ctrl 放到 caps 的位置之类的操作，哦，还有说编辑器的，很多人会提到一个东西——

『我的手不需要离开主键盘区就可以完成几乎所有操作了』

隐含的言下之意就是，手不要动来动去，只动手指才是速度最快效率最高的。

我一直。。。不咋认同。

1. 影响你工作效率的，其实只要打字速度达到一定基线以上，基本就没问题了，你 apm 300 和 apm 120 ，都是很快的速度了，毕竟你还有很多时间是用来思考的。

2. 如果说键盘稍微离开字母区你就觉得影响速度了，那可能是你对键盘还没真的熟悉，那些编程常用的符号，本来也应该滚瓜烂熟，而且就那几个符号，你的手也是不需要离开键盘主区域的。

3. 手长期保持一个姿势做输入，也不是什么好事，肌肉在同一个姿态下太久了，压力也大。

虽然这个东西简单到其实就是几行脚本的流程组合……
虽然这个东西其实就是个任务流……
虽然 SFTP 发布前端这个模式我觉得本身就是有问题的……
但我还是鼓励和支持……

因为我就是从 17 年写一个类似的工具开始，到今天攒了一堆好用强大的工具……
都是从想改善一个小小的流程开始，哪怕它其实很简单……

东西是挺好。

我只是好奇，大家平时真的会在 web 端这样分享吗？

我比较懒，都是直接复制了 url 发过去给别人。。

先买住房，再买公寓。

能不能简单讲讲需求。哪些想要的点。

这东西纯本地也不是很合适，走线上又容易有问题。

我看看有没有办法搞个什么折中方案，开源程序或者某种更安全的服务之类的。

ts 不是只有好处没有坏处的。

一个是很多人提到的场景问题，前端开发中会存在着大量的月抛甚至周抛型任务，但这类任务中又有相当一部分需要从头开始开发，本身也不复杂，使用弱类型语言一把出货，又快又好，这种情况下上 ts 反而是徒增心智负担。

第二个，原因，是我个人感受。不知道有没有人和我持类似的想法，但这个可能没法解决。ts 里有一些优秀的特性我觉得应该是进入 js 里面去的，但 js 既然保证了对历史版本的兼容，意味着基本做不到了。ts 永远只能是一个方言的形式存在。
最后跑起来的还是 js，意味着，ts 是一个从开发层面实现了更友好支持的方言，但最终跑起来的运行时优化，是和 ts 本身没多大关系的。
这很像 python 里现在的类型提示，很大程度上可以借助 IDE 或者某些类库实现友好的提示，帮你写出更好的代码，但跑起来后还是一套动态一起上。
而真正的强类型，编译语言，是可以在运行时上做到针对性的优化的。这事，注定是 ts 的短板。

所以 ts 的场景，我们可以大概认为，它应该是主要面向开发这层做优化，更方便协作，能写出更工程化的东西。
但这样的事，我更觉得，应该让原生 js 增加这些 feature 才对。

ts 应该进入 js 。

但回头看看 js 这边的一些新提案，再看看 python 那边花里胡哨的一些提案……唔，感觉官方们都还集中在语言本身的 feature 改动上，而对工程化的支持，似乎都是社区在自行推进周边的支持。

目前看来最舒服的居然是 go …… 不挑刺，我知道 go 的问题和不爽，但总的来说，在工程化，效率，性能，语法上，我觉得当前阶段是一个蛮舒服的结合点的。

。。。。。。

这次真的不是产品经理问题。
是技术人员的问题。

自己写的屎，自己吃下去。

@javalaw2010 对对对，这个问题我也想过。
我甚至联想到了游戏服务器上，多玩家联网操作的逻辑同步。

但引申来了一个新问题。
我不同端操作先后有别，那我为了保证某种程度的最终一致性，后端除了记录数据，是不是还得记录下来自多个客户端的所有操作，类似 binlog 日志那样。
感觉又增加了存储队列上的额外操作。

@littlemcdull 其实这个模式我想过，颇有点类似 MySQL 了。
要实现同步数据，一个是传统的模式，拿最终数据。
二个是像这种模式一样，拿所有的操作行为日志，再完整走一次，就可以追回最终数据了。

但我想了下，这种前后端的场景中，走日志的模式代价远比直接获取最终数据高。

@DGideas 道理都对。

但给普罗大众这样的解释，更像传销了。

最起码传销组织也最爱用这样的东西把人唬的一愣一愣的，哈哈哈哈。

等两个月，我在写。

不用就对了。

vanillajs

小程序的 onPageScroll 我没用过，目测和浏览器环境下用法差不多。

使用 onPageScroll()方法，该函数有一个参数 e，通过 e.scrollTop 可以访问你所滚动的高度。

onPageScroll: function(e) {
console.log(e.scrollTop)
}

你可以计算 e.scrollTop 来决定要不要开始执行动画。
但应该不能在里面用不停的去 setData 的方法来做，会有严重的性能问题。它更应该是一个触发开关，开关打开后去调一次动画。

可以玩游戏了。。。