见过这么做的，能运行
但完全不可以，绝对不可以

状态管理是用来存储、修改、共享和分发数据的，不应该包含任何副作用、异步过程和其他多余操作

目前见过的一些状态管理使用状况，基本都是乱用，什么都放到状态管理中
实际上应该谨慎使用状态管理，尽量少用或不用，真需要状态管理的数据和场景并不多

我本地的联通更扯淡，之前从账号登录改成自动获取 IP 了，也没通知过用户，搞了半天电话联系客服才知道

学校为何能代表收入水平呢

@learnshare 续项目管理，我个人感觉项目需要有的几个特征：

1. 正确的需求、设计、开发、测试和上线流程
2. 符合实际的排期和更新上线节奏
3. 应用可靠性和代码质量
4. 文档资料完整，确保可持续维护更新
5. 人员可替代

几年前的公司，规模不算小了，但也是关键模块陈年老 jQuery 不愿动，完全没法维护
后来努力重构了一个版本，然后离职了，不知道后续是否被采用

格式化旧代码是发生过的，领导把全部代码都格式化了...

出问题的不是代码，是人。项目管理是门艺术，糙人做不来

@0576coder 房子烂尾属于地方不敢插手的问题，涉及的人和事太多

取决于老家和你自己的状况。

从上海回老家三年多了，一直在远程工作，感觉也还行。

+ 买了房，烂尾没人管
+ 车学了一半，严重紫外线过敏放弃了，甚至出门也困难
+ 近处没有菜场集市，超市品类少不新鲜，而且不算便宜
+ 四五线城市确实差，各方面都差

/t/785701

正常写就行，但放大之后的效果取决于浏览器本身

- [Awesome Design Systems]( https://github.com/alexpate/awesome-design-systems)

- [Google Material Design]( https://material.io/design/introduction)
- [Apple Design Guidelines]( https://developer.apple.com/design/resources/)
- [Microsoft Fluent Design]( https://www.microsoft.com/design/fluent/)
- [Windows UWP Design]( https://docs.microsoft.com/zh-cn/windows/uwp/design/)

先从 Design System 开始，了解有什么、是什么、为什么、怎么用

千元左右的山地车就可以了，结实耐造最重要。折叠车通常过于轻便，骑着有点飘，稳定性差一些。

以前骑车上班有两三年，单程 13km 左右。这几年很少骑了，偶尔骑还膝盖疼。

骑车上下班路上问题比较多：
+ 非机动车专用道不多
+ 路边乱停乱放 /行人乱窜
+ 共享单车太多，速度慢，蛇形走位
+ 电动车 /汽车水平不高，威胁很大

安全第一。头盔、头尾灯、铃铛都有必要，甚至运动相机也需要

并不是个技术问题，而是个服务问题。

室内地图和室内导航并不是问题，根据成本能够提供不同的使用体验。
但在医院 /体检中心这个场景下，核心是操作流程，而不是导航去哪里。

比如一个简单的门诊 - 检查 - 开药流程：
1. 挂号（在线、现场自助或人工柜台）
2. 门诊
3. 检查，等待结果
4. 打印检查报告，挂号（返诊）
5. 返诊，开药
6. 交费，取药

需要结合医院的信息系统，加上地图和导航，实时更新个人状态，并给出引导。

目前我接触的医院是没有这种实时跟踪服务的，就诊检查需要到处跑、到处问，年长的家人去大医院非常困难。

https://esahubble.org/images/
https://images.nasa.gov/
https://www.nasa.gov/multimedia/imagegallery/index.html
https://www.esa.int/ESA_Multimedia/Images

例如 https://esahubble.org/images/heic1403a/
Large JPEG: 124.0 MB

https://codepen.io/ 上来个 demo

@avastms
@iikebug

对比是必须要有的，但的确应该在三个都详细了解和使用之后

@foil2 谢谢


@pddwin 也可以，但 Svelte 目前应用还不够广泛吧

@shuxhan
@murmur 两个不同版本我是了解的

接手过两个时间略久的项目，出现了我前边讲的问题。

当然主要责任还是在使用者，即便不基于此类项目，也可能把项目写到没法维护。

但作为具有一定流行度的项目，还是希望它能够高标准、高要求、方便维护和升级。

@ruanimal 要看版本的

一同抵制一下 vue-admin-template ?

类似的项目通常缺乏最佳实践，配套工具和代码风格不太好，导致项目质量不高。
而且后续升级 /维护难度很大，依赖包只能停留在项目创建之日。

我的建议是按自己 /团队的风格搭建类似的模板项目，而且要确保风格统一，配置简洁，后续可升级。

@anjianshi
@murmur
@mxT52CRuqR6o5

感谢关注 ;)

从使用者角度讲，三者的功能都差不多。同类工具，掌握一个也就够了。

+ view = f(state)
+ 模块化、组件化开发
+ 路由
+ 数据、状态管理
+ ES2015+、TypeScript
+ Babel 、Webpack 、CLI

这次学习（或者挑战）的原因是一直想三者都学一遍，从 15 年丢掉 Angular 1.* 的时候就一直想了。

+ 首先是三者都比较流行。从求职的角度看，三者出现的概率是 Vue > React > Angular
+ 虽然三者都可以快速上手开发，但使用者通常只掌握了项目里常用的知识，路走窄了
+ 目前正好有大把时间，可以结合过去几年的开发经验把三者一起学起来
+ 原理层面暂时没有想法，就像大多数人不需要看 Web 规范定义和浏览器源码一样

多学点总是好的，而且有足够的开发经验，不至于走火入魔。