Writebook を読む
refs
要は買い切りでインストールすれば動作するソフトウェアといった趣きのソフトウェアだ
DHHの最近のブログの傾向からもクラウドをやめる、TypeScript をやめる、コンテナイメージひとつだけポンとデプロイくん(語弊)、Thrusterの開発など、過度に複雑性を持ち込まずにソフトウェア開発をする流れが DHH (ならびに Rails ) にはある フロントエンドよりの人類なのでそのへんから見てく
views
モデルに Current < ActiveSupport::CurrentAttributes があってアカウントごとにカスタムCSSが挿入できるようなヘルパーが用意されている
先の記事にも触れられているが <%= stylesheet_link_tag :all, "data-turbo-track": "reload" %> Turbo を使ったこのへんの記述の理解が薄い
多分 reload したときに head の参照をマージするなどよしなにしてくれるんだろう
当然のように CSP
tkdn.icon lightbox というモーダル向けの単語はいつまで使われるんだろうかね
initializers/assets.rb
Rails.application.config.assets.version こんなんあったんだっけと思ったがある
class="layout--reading" などスタイル目的ではない(CSSに該当のセレクタがない)クラス名もある
これも Turbo 関連なのか?
assets(CSS)
表面的に命名だけを抽出すると BEM っぽさがある .book__cover, .lightbox__image: Block + Element みたいな
.theme--white: Block + Modifier みたいな
ガチガチではなくゆるく命名されてそう
ただこれらが Turbo による画面遷移でどう読み込まれるかというのは知っておきたいかもしれない
印象的なのはファイル単位で :root {} にカスタムプロパティで値を指定している(e.g. --btn-size: 2.65em;)
:is, :where が頻出している
assets(JavaScript)
controller.js にけっこう濃く書かれていることが多い
やはりこれがどう stimulus と連携するのかよくわかってない
view data: { controller: "upload-preview" } の upload-preview はファイル名で呼ばれるんだろうか(ファイルのクラスは default export されてる
読み進めるとそうっぽい
models
User には Concern として Transferable, Role が include されている
Book::Accessable あたりが印象的で、Access へのリレーションシップを表現した Concern として切り出されていた
関連や scope, ARライフサイクルメソッドがダラダラ書かれたクソデカモデルばかり見ていたので整然としている印象を受けた
initializer
RubyVM::YJIT.enable
Rails.application.config.filter_parameters 知らんかった。ログからフィルタリングする
Rails.application.config.git_revision で Git HEAD コミットを取ってヘッダーに埋めている
Dockerfile
ビルドの引数はアプリケーションバージョンとGit HEAD Commit 程度
起動は Ruby スクリプトで Procfile を読み込む