Note that the second argument populates the array with references to the same object.
第二个参数传的是引用,意味着第一层数组的每一项都指向同一个 array 对象。
可以混用,一部分打包一部分不打包。如果有洁癖想要完全不打包,就把编辑器独立一个项目打包,就好像 trix editor。
取决于 app server 实现,如果是 puma,我没仔细研究,但我看到了线程池,按我理解是复用的。
访问结束后 current 清理了吗?没清理这个 thread 处理的下一个请求就能访问。
Rails 提供了 Current Attributes 可以帮忙每个请求之后清理值。
https://api.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html
没有。
第一次见这样写的,如果让我 code review 会驳回,写得简单点。
我没有用过 Django,单从文档看,Django 对前端技术不持立场,开发者根据自己的情况选择前端技术;而 Rails 创始人 DHH 强烈推荐全栈开发,默认包括一个叫 hotwire 的从网页到移动端的前端框架,当然如果不想用 hotwire 也可以选择集成其他“主流”的前端技术。
Rails 7.1 发布 Hacker News 上有一些多框架使用者的评论,可以看一下 https://news.ycombinator.com/item?id=37787130
选择无聊的技术 https://boringtechnology.club/
应该部署一个 demo。
我觉得 Ruby on Rails 的开发效率优势来源于:
ORM 只是 Rails 其中一个优势,且不说我不觉得其他语言的 ORM 追上了 Rails,Rails 还有很多优于其他框架的地方。
例如 Turbo Stream Broadcast 是一个杀手锏功能,让我非常容易开发即时更新的功能。要实现这个功能必须整合数据库、消息队列、前后端通信、前端更新这整个技术栈。少数全栈框架,例如 laravel、Phoenix 也有类似的功能。
过去几年前后端分离盛行,能体会全栈开发效率的人变少了。现在 next.js,remix 等框架又开始往全栈方向回摆,因为有些功能就是全栈更有效率。目前这种技术回摆导致了一些混乱,不断有人抱怨 RSC 难以理解。
我很庆幸 Rails 是一个成熟的全栈框架,让我远离这些混乱,只需专心开发应用。所以是的,我认为 Rails 在 2023 年仍然有效率优势。
我补充一点为什么应该用 stimulus。
Turob 环境下 document.addEventListener
是全局的,去到别的页面这个监听器依然存在(除非再实现解绑逻辑),然后每次 stream render 都要判断有没有需要处理的内容存在。
而 stimulus 是让元素成为自行管理的组件,要优于事件绑定。
turbo:render
也许对应 turbo visit 和 cache render,不包括 stream render。
当一个元素出现在页面时执行某操作,更适合用 sitmulus。
需要扎实的运维开发,能讲好增长故事拉来投资,还要能稳定服务提供信心。我觉得是非常难的,但说不定有人可以做到。
文件同步慢可以用 docker sync 这个工具 https://github.com/EugenMayer/docker-sync
我是买了 M2 版 Macbook Pro 后性能提升解决了这个问题……
Config 往上找祖先,找到 self.instance
方法,然后执行方法的上下文是 Config,@single
属于 Config。
我还在用 2015 款的时候是有升级就升的。我的开发环境都放在 docker 里所以系统影响不大。
但如果你的开发环境是在原生环境要注意会不会一大堆东西不兼容。
老项目用容器或者虚拟机搭建和线上一样的环境。
新的 Macbook。我从 2015 款换到 M2 版 pro 14,起飞一样。
应该是系统没有安装中文字体
贴日志。
有点挑战的程序都不是一下能写好的,要容忍不完美,先做个能用的出来。如果程序是有需求的,后面随时可以重构。
英文原版一直紧跟最新版的。
已去除
补全完我要看一遍,总的来说看的时间少于手敲。
对编程有帮助,节省不少 crud 代码和 test 代码的输入时间。
不过我没有买,GitHub 判断我有开源项目所以送了使用权。
如果不知道怎么选择,我建议这样: