思路不错，不过你可以了解一款老游戏（也许不算游戏）《桌游模拟器》。

很牛逼的项目，把你们的文档都看了一遍。不过对你们的技术实现很感兴趣呀，有这块细节文档吗～？

去哪煮米上看吧： https://www.nazhumi.com/

MUD 还存在，比如：北大侠客行

华西～天天一瓶 10.5 的

真一： https://zhen.one ，RSS： https://zhen.one/atom.xml 。
感谢关注， 一直在输出~

业务决定产品

楼主不嫌弃的话，可以瞅瞅我这个 demo ，内容很精简，同时还集成了 websocket：
https://github.com/w4ngzhen/nest-http-websocket-demo

说下思路吧。首先，这个“输入框”从上到下需要分为三个部分：
1. 实际的输入框；
2. 展示上传图片的地方；
3. 圈子选择。
然后，思考一下这里的数据模型。大概这样：
{
inputText: string;
// 这里是放置上传的媒体数据，是一个数组，每一项 thumbnailUrl 是这个媒体资源的缩略图； resUrl 是媒体资源的实际 URL ； localPath 是初始传上来，没有传到后端的文件路径； resType 就是资源类型（图片 or 视频）
mediaResInfo: Array<{ thumbnailUrl: string; resUrl: string; localPath:string; resType: string }>;
groupInfo: string; // 不知道具体什么，就用个 string 吧
}
顶部实际的输入框是一个完全无边框的 input ，每次 onChange 修改的是 inputText ；
下方的缩略图呈现区域你用图片 img 来渲染；整个组件接受图片拖入的事件，如果是图片，你可以直接将图片放到这里（由于大小原因，直接缩放了），不需要缩略图 url ；如果是视频，则你可能需要一个服务（我不太清楚这块还有什么方式获取视频首帧图片）来获取视频首帧图片，得到一个 URL ，进行展示。

最下方的圈子选择不多说的。

至于你说的二选一功能，只需要考虑，上面数据模型中的检查媒体资源中的 resType 是否满足二选一的要求，不满足就不能再传了，（也就是对拖入事件不处理）；

外面手机大概写的，思路就是围绕数据，上面界面只是呈现数据的结果。大概这个思路哈。

个人的理解，redux 不适合业务项目，适合一些底层框架使用。举个例子，比如做一个某些领域的低代码底层，使用 redux 可以很好的控制低开中的数据流。

啥时候来成都呀🤩

个人推荐矮人要塞，会了以后其乐无穷

更加推荐 rm 别名到 cp 等，把删除的内容放到临时目录下。至于 rm 加上确认 prompt ，可能短期有用，但是长期很容易养成一路 yes 的习惯，实际上没啥大用处。

想起以前看的留言终结者，一直变道试图找到最快路线的开车方式和基本不变道差不了几分钟。另外，其实估算也算的出来，高速上 120km/h ，跑 120km 花 60min ，如果跑到 140km/h ，也就 51min 。两者相差 9min ，也就服务区简单休息撒泡尿的时间，这还是你冒着高风险且一直不减速的结果。

大佬好，请问这个图床纯用爱发电么？

@bnrwnjyw “编制有什么好的” 大哥，人家媳妇是北京在编教师。。。