@vevlins lowcode 不就是 DSL 的可视化编辑么

自己实现过 DSL 的人应该都明白，当需求越来越复杂的时候 DSL 慢慢演变成脚本语言，再往后就演变成有工程化能力语言

你是这么优秀的一个人，为什么要在这样的论坛上寻找对话呢，大多数人是不匹配的，但能拿到话语权，得到的只能是噪音罢了

耳塞不要长久带，之前因为噪音问题，睡觉带耳塞，引发了耳石症，后面就不敢这么带了

@taowen 你这个挺棒的

@DiamondYuan 能给大型的项目提交 MR 也应该有不错的能力了

@windyCity1 是的确实需要经验的积累，但这方面的分享其实是最匮乏的，github 虽然能够分享好代码，库，框架，但没办法分享这些设计的方法和抽象的方法

@xujinkai 相关书还 是很多的，unix 编程艺术其实主要关注的也是设计非常的重要，面向 Unix 命令行的工具的交互方式的探讨和设计。

@charlie21 前端除了营销页，几乎大部分项目都是有很长的周期的，现在公司的所做的所有项目都是要长期维护的，还包括祖传几代的 AngularJS 项目

@ianva 想了下你的疑惑，我大概可以了解到可能存在的问题，
“具体来说是，一个状态改变，可能是在离用到这个状态的代码很远的地方开始，由一条很长的链路触发的”
状态为什么要和前端的 view model 有关系，当前的 view model 应该是从视图着手去描述你的业务，这是和交互无关，和状态无关的东西，这层 model 是要将后端的数据映射过来的，这层决定着项目的业务逻辑和稳定，后端接口的变化也在这一层隔离出来，所有的 container 的数据都应该基于这个模型

UI 在目前的本质就是数据对视图的映射，所以这就是我说的，大部分的前端欠缺建模的意识的，但不自知，因为缺少尝试，如果走 BFF，GraphQL, 可能会更容易理解

另外 react 这样的库让数据驱动变的更自然和容易，在我们之前使用 jQuery, YUI, 的时候我们做这件事情是需要成本本经验的，即便在那个时候你不去从数据驱动的方式入手，那代码是更难以维护的，也就是说为什么前端的老项目维护起来如此困难，能够做到这些的开发太少了

@KuroNekoFan 交互也需要分层的，对前端来说交互就是业务，在交互复杂的 container，更是要把不同的交互方式拆分出来，数据层和 container 的对接也可以用 hooks 隔离出来。
当必然交互层的分隔甚至有多种方式，比如把组件抽成无状态的组件和通过 context 拆出的纯状态操作，等等，这都可以让当前的复杂的容器交互变的更简单

多年专职前端，hooks 分层业务很好

@godbasin 满满的干货啊，支持一下

@wiwby 培训赚钱

@kop1989 为啥是“收割廉价劳动力”

@Mithril 是的，相比学会一个新技术，真是授人以渔

@rioshikelong121 挺好的建议，出题也是个有挑战的事情，其实具体业务是最容易的