https://d226lax1qjow5r.cloudfront.net/blog/blogposts/new-year-new-rails/new-year_new-rails.png

Karl LingiahRuby開発者支援

KarlはVonageのDeveloper Advocateで、RubyサーバSDKのメンテナンスとコミュニティの開発者エクスペリエンスの向上に注力しています。彼は学ぶこと、ものを作ること、知識を共有すること、そして一般的にウェブ技術に関連することが大好きです。

新年、新しいレール

最終更新日 January 31, 2022

#ruby-on-rails

#ruby

所要時間：1 分

新たな年の始まりは、しばしば、新体制の刷新の時期とみなされる。 self.ジムの会員になる、もっと健康的な食事をする、新しい言語を学ぶ、などなど。私はこれまで、「新しい年、新しい自分」的な抱負はあまり好きではなかったが、最初の印象からすると、「新しい年、新しいRails」のファンであることは確かだ。

さて、その "新しい年 "の部分は、完全なものではない。 正確には正確には Rails 7.0は昨年末の12月15日にリリースされました。私たちはすでに 7.0.1パッチのアップデートがありました。新しいRails」という部分は正確に感じますが。メジャーバージョンのアップデートは常に新しさをもたらしますが、Rails 7.0はそれを超えています。以前のバージョンからの大胆でエキサイティングな出発のように感じられる。

Railsの初期には、コンフィギュレーションよりも規約を重視し、ツールやコンポーネントのデフォルトに意見を反映させることで、やや物議を醸すこともありました。これらのRailsアプローチの重要な信条は、最終的に Railsドクトリンの一部を形成するものであり、多くの開発者がこのフレームワークに魅了される理由でもありました。確かに、デフォルトに慣れ、規約を学ぶ必要はありましたが、一度それができれば、Railsは単純に仕事をするのが楽しくなるものでした。この全体的なアプローチは、Rails Doctrineの最初の柱を支えていました：プログラマの幸福のために最適化する.

フレームワークとしてのRailsの強みの1つは、刻々と変化する技術状況に合わせて進化できることです。ここ数年、この変化の多くはフロントエンドで起こりました。リアクティブなインタフェースを求めるあまり、シングルページアプリケーション (SPA) が台頭し、それに伴ってアプリケーションロジックがサーバからクライアントへとシフトしました。このシフトの影響の1つは、依存関係の管理、トランスパイル、アセットのバンドルなどの点で、フロントエンド開発プロセスに複雑さを加えることでした。Rails 5.2以降、このフロントエンドの複雑さを管理するための答えはウェブパッカー.

Webpackerは喜びを呼び起こすか？

Webpackerはフロントエンドの依存関係や設定を管理する複雑さをいくらか抽象化してくれましたが、必要なものではあっても、常に回避策のように思われていました。組み込みのフロントエンドソリューションというよりは、Railsアプリを既存のフロントエンドエコシステムにフックする方法でした。すべてがうまくいくときはいいのですが、複雑なNodeパッケージの依存関係の問題に対処したり、さまざまなコンパイルエラーをデバッグしたりしなければならなくなることもあります。

Railsチームは、近藤麻理恵のアプローチで近藤麻理恵のアプローチを採用したようです。というのもこの動きの背景にある考え方というのも、Rails 7ではES6がブラウザでサポートされるようになり、HTTP/2が広く採用されるようになったからです。前者ではES6のコードをES5にトランスパイルする必要がなくなり、後者では多重化機能により、1つの大きな「パック」ではなく複数の小さなファイルをリクエストすることによる待ち時間が軽減されます。

でも、まだNodeのパッケージが全部必要なんだけど、どうやって手に入れたらいいの？その答えはインポートマップのようなESモジュールを提供できるCDNと組み合わせることです。スカイパックや JSPM.この組み合わせにより、ビルド・ツールや、ローカルにNodeをインストールする必要性すらなくなる。また importmap-rails gemは、基本的に「素のモジュール指定子」をそのモジュールをロードするためのソースにマッピングします。インポートマップの設定は config/importmap.rbファイルでインポートマップの設定を行います。特定のモジュールは、特定のレイアウトで必要なときに、実行時に <script>タイプの "importmap"の <head>のタイプのタグを通して、特定のレイアウトで必要になったときに要求されます。かなりすごい！

このアプローチは誰にとってもうまくいくわけではない。JSXでReactを使ったり、Typescriptを使ったりしたい開発者もいるでしょうから、コンパイル/トランスパイルステップや、Nodeエコシステムにフックする機能が必要になります。まあ、Rails 7でもこれはできます。そのためには jsbundling-rails gemを使うと、esbuild、rollup.js、またはWebpackを使ってJavaScriptをバンドルし、Railsのアセットパイプライン経由で配信できます。

フロントエンドとバックエンドを分割するようなアプローチを使いたい開発者もまだいるでしょうが、Rails 7からのメッセージは、ほとんどのユースケースにおいて、ブラウザでリアクティブなユーザー体験を提供するために、フロントエンドにヘビー級のフロントエンドフレームワークや大量のカスタムJavaScriptを必ずしも必要としないということです。ブラウザでリアクティブなユーザー体験を提供するために、フロントエンドに重量のあるフロントエンドフレームワークや多くのカスタムJavaScriptを必ずしも必要としないということです。 Hotwire.

Hotwireは鉄道的

Hotwireは完全な新機能というわけではなく、Rails 6でも設定次第で使用できましたが、Rails 7ではデフォルトのアプローチになっています。HotwireはBasecampとHeyのチームによって開発され、3つのライブラリで構成されている：Turbo、Stimulus、そしてまだリリースされていないStradaだ。

ターボ

Turboは力仕事のほとんどを行う。サーバーサイドレンダリング（SSR）を使用して、JSONの代わりにHTMLをワイヤ経由で送信するため、レンダリングや状態管理などのフロントエンドでの要件がなくなります。Turboは、いくつかの補完的なコンセプトとテクニックを組み合わせています。

ドライブリンクのクリックとフォームの送信をインターセプトし、新しいコンテンツへのリクエストを発行し、HTMLレスポンスをレンダリングする。 fetch新しいコンテンツへのリクエストを発行し、HTML レスポンスをレンダリングします。
フレーム：リンクをクリックしたり、フォームを送信したりすると、ページ全体がリロードされるのではなく、ウェブページの特定の部分のみがリフレッシュされるように、ビューを個々の部分またはコンポーネントに分割することができます。
ストリーム：WebSocket または Server-Sent Event を介して送信された非同期アクションに応答して、部分的なページ更新を配信します。

これらはすべて、ごく標準的なSPA機能のように聞こえるかもしれません。Turboの決定的な違いは、フロントエンドの応答性を高めるためのロジックが、Railsアプリの前面にボルトで固定された別のフレームワークに分割されていないことです。その代わりに、明確で論理的でエレガントな規約を使用して、Railsのモデル、ビュー、コントローラの中にあります。

この記事はチュートリアルを目的としたものではないので、これらの規約の詳細についてはここでは触れない。ハンドブックと開発者リファレンスや READMEページも参照してください、 turbo-rails.

刺激

Stimulusは「控えめな野心を持ったJavaScriptフレームワーク」と自称しており、Turboを補完することを目的としている。HTMLのデータ属性に大きく依存し、次のようなJavaScriptオブジェクトを使用する。 コントローラと呼ばれるJavaScriptオブジェクトを使用して、一致する data-controller属性を持つ要素によって発生するブラウザ・イベントに応答するために、コントローラと呼ばれるJavaScriptオブジェクトを使用する。 data-action属性を使用して特定のアクションをDOMイベントにマッピングします。ここでも具体的な説明は省きますが、詳しくは Stimulus のハンドブック, 開発者リファレンスや READMEページがあります。 stimulus-rails.

Hotwireはフレームワークにとらわれないように設計されています。しかし、Railsのコンテキストでは非常に理にかなっており、特にライブラリのRails実装が ActiveRecord.たとえば、モデルで broadcasts_toヘルパーをモデル内で使用して、特定の名前のチャネルにパブリッシュするさまざまなコールバックを設定できます。 :todo_listに発行するさまざまなコールバックを設定することができます。

class Todo < ApplicationRecord
  broadcasts_to :todo_list
end

そして、Turbo Streamエレメントをセットアップして、そのブロードキャストを購読することができる。 :todo_listブロードキャストを購読します。これらの要素は、データの変更が発生したときに適切に更新されます。特定のブロードキャストを購読しているストリーム要素を含むページを閲覧している人は、ブラウザがページのその要素をリアルタイムで更新するのを見ることができます。

この機能は ActionCableをバックグラウンドで使用します。この turbo-railsは、論理的でアクセスしやすい方法ですべてを配線します。

Hotwireの大きな特徴は、Railsらしさを感じることです。革新的なアプローチと確かな規約によって、フロントエンドの複雑さの多くを抽象化しています。これは常にRailsのやり方であり、Rails 7への統合は、Webpackerの妥協よりもずっとRailsの教義に忠実であるように思えます。

その他のハイライト

Rails 7の注目すべき変更点は、フロントエンドでの作業に対する新しいデフォルトのアプローチですが、バックエンドに関しても注目すべき変更がいくつかあります。その中で最も興味深いのは、データを扱うさまざまな側面に関するものです。

アクティブレコードの暗号化は、暗号化された属性を追加することで、セキュリティの追加レイヤーを提供します。暗号化された属性を追加します。 ActiveRecord.
Parallel Query Loadingは、コントローラのアクションが複数の無関係なクエリを同時にロードする必要がある場合のパフォーマンスを改善します。

個人的には、Rails 7にとても期待していますし、今年はRails 7とVonage APIを使ってクールなものを作りたいと思っています。Rails 7についてどう思うか、ぜひお聞かせください！ぜひツイッター.