-
1:以下、名無しがお送りします
JavaScriptにSignalsを追加する提案(proposal)があるみたい TC39(ECMAScriptを策定してる委員会)の2024年4月のアジェンダにStage 1として載ってるらしい
-
6:以下、名無しがお送りします
これって何? 初めて聞いたわ
-
15:以下、名無しがお送りします
>>6 Signalsっていうのは リアクティブプログラミングのための機能らしいよ 値の変更を監視して自動的に更新できるみたい
-
54:以下、名無しがお送りします
>>15 リアクティブプログラミングか Vue.jsとかでよく聞くやつだな
-
22:以下、名無しがお送りします
Stage 1ってことは まだ正式に採用されたわけじゃないんだよな? どのくらいかかるんだろ
-
23:以下、名無しがお送りします
正式採用されるまでは 最低でも2〜3年はかかるって書いてあるな 全ブラウザに実装されるまでは もっと時間がかかりそう
-
31:以下、名無しがお送りします
Signalsのポリフィルもあるみたいだけど まだテストも少ないし フレームワークへの統合も始まったばかりらしい
-
38:以下、名無しがお送りします
Signalsの提案者は いろんなフレームワークでシグナル/リアクティビティの仕組みを実装するためのベースになることを目指してるんだって
-
42:以下、名無しがお送りします
再帰的なストアのプロキシとか デコレータベースのクラスフィールドのリアクティビティとかにも使えるようにしたいらしいな
-
46:以下、名無しがお送りします
Signalsは計算シグナルとエフェクトシグナルから読み書きできるけど読み込み後の書き込みを制限しないんだって 柔軟性とフレームワークとの互換性を維持するためらしい
-
62:以下、名無しがお送りします
シンプルなアクセサデコレータを使えば クラスフィールドをシグナルベースにできるらしいよ Signalのポリフィルのreadmeに書いてある
-
66:以下、名無しがお送りします
Svelte 5のRunesとかなり似てるみたいだな コンパイラでRunesをここで定義されてるSignal APIに変換するのは簡単らしい
-
71:以下、名無しがお送りします
>>66 Svelte 5は内部的にそういう変換してるんだって 独自のSignalsライブラリ使ってるけど
-
76:以下、名無しがお送りします
SignalsはSSRとかハイドレーションとか リジュームとかにも使えるのかな?
-
85:以下、名無しがお送りします
>>76 その辺の詳細はまだわからないみたいだな これからの議論次第じゃないかな
-
94:以下、名無しがお送りします
提案者の中にはウェブ以外のUI環境でも使いたいって人がいるらしいけど 最近はウェブAPIもウェブ以外で実装されることが増えてきてるからどっちでもいいのかも
-
101:以下、名無しがお送りします
SignalsはDOMのAPIに依存しないから TC39でもDOMでも どっちで提案してもいいんだって
-
106:以下、名無しがお送りします
>>101 グループを変えた方がいい強い理由があれば issueで教えてくれって書いてあるな
-
114:以下、名無しがお送りします
TC39の提案の典型的な流れだと ネイティブのSignalsが全ブラウザで使えるようになるまでは 最低でも2〜3年はかかるんだよな
-
117:以下、名無しがお送りします
>>114 しかも数バージョン前までさかのぼってサポートするなら ポリフィル不要になるまではもっと時間かかりそう
-
122:以下、名無しがお送りします
Signalsはリアクティブプログラミングのパラダイムシフトを起こすかもしれないな 楽しみだ
-
130:以下、名無しがお送りします
>>122 パラダイムシフトは言い過ぎだろ でもJavaScriptの書き方が変わる可能性はあるよな
-
135:以下、名無しがお送りします
今のリアクティブプログラミングのライブラリやフレームワークが ネイティブのSignalsを使うようになったら 性能とか互換性とかが良くなるかもしれない
-
142:以下、名無しがお送りします
>>135 ライブラリ間の差異が減って 学習コストも下がりそうだよな
-
143:以下、名無しがお送りします
イベントハンドリングとかにも使えそうだけど そういう用途は想定してるのかな?
-
148:以下、名無しがお送りします
>>143 イベントハンドリングは リアクティブプログラミングの一部だから 使えるんじゃないかな
-
149:以下、名無しがお送りします
Signalsを使えば UIの状態管理がシンプルになりそうだよな
-
153:以下、名無しがお送りします
>>149 状態管理ライブラリとかも Signalsベースになるかもしれないな
-
158:以下、名無しがお送りします
デバッグとかテストとかにも影響ありそうだよな 新しいツールとか手法が必要になるかも
-
166:以下、名無しがお送りします
>>158 確かに リアクティブプログラミングのデバッグって 今でも結構大変だからな
-
173:以下、名無しがお送りします
ブラウザのデベロッパーツールにも Signals用の機能が追加されるといいな
-
178:以下、名無しがお送りします
>>173 ChromeとかFirefoxとかのデベロッパーツールチームは Signalsの提案を注目してるだろうな
-
186:以下、名無しがお送りします
Signalsを使ったコードの最適化とかも これから研究が進みそうだな
-
193:以下、名無しがお送りします
>>186 コンパイラとかも Signalsを考慮した最適化ができるようになるかもしれないな
-
198:以下、名無しがお送りします
サーバーサイドでも使えるのかな? Node.jsとかで
-
200:以下、名無しがお送りします
>>198 サーバーサイドでリアクティブプログラミングするユースケースはあまりないかもしれないけど 技術的には使えそうだよな
-
208:以下、名無しがお送りします
ストリーム処理とかにも使えそう RxJSみたいなライブラリと相性良さそう
-
209:以下、名無しがお送りします
>>208 SignalsとRxJSを組み合わせれば さらにパワフルなリアクティブプログラミングができそうだな
-
210:以下、名無しがお送りします
提案が正式採用されたら JavaScriptのエコシステムがどう変わるか楽しみだな
-
219:以下、名無しがお送りします
>>210 まだまだ先の話だけど 今から準備しておくに越したことはないよな Signalsの動向は要チェックだな
JavaScriptがリアクティブを導入?Signalsって何!
コメント1件
GitHub - proposal-signals/proposal-signals: A proposal to add signals to JavaScript.
A proposal to add signals to JavaScript. Contribute to proposal-signals/proposal-signals development...
コメント(1件)
-
12024年4月6日 22:43
これ導入されたら大きく変わりそう