Angularアプリケーションの状態管理パターン | Marginalia
Angularアプリケーションの状態管理の方法はさまざまな実装がありえるが、その中でも典型的ないくつかのパターンを、それがどのようなニーズがあって選ばれるのかという考察を踏まえながら列挙する。パターンとその特徴を例示するのであって、それぞれのパターンにおける最良の実装を示すものでもないし、これらのパターンに該当しない実装を否定するものでもない。 Standalone Componentsなど、Angularのメンタルモデルが変わっていく兆しを見せる今、これらをまとめておくことは諸々のAngularアプリケーションの状態管理のあり方を見直すきっかけになるのでないかと思う。特に、NgRxがデファクトスタンダードであり唯一の選択肢だと考えている人には、それが単にひとつの選択肢であることを思い出してもらえるのではないだろうか。 コンポーネントクラスによる直接の状態管理一番最初のパターンは、次の例の
GitHub Actions: Yarn キャッシュをシンプルに使う | Marginalia
今後は actions/setup-node の cache オプションで事足りるだろう。以下は読まなくていい。 GitHub Actions で継続的インテグレーション・デプロイを構成すると、すぐに問題になるのはキャッシュの活用だろう。 特に Node.js プロジェクトでは NPM から依存パッケージをダウンロードする時間がワークフロー実行時間全体の大部分を占めることも珍しくない。 毎回すべての依存パッケージをインターネット越しに取得することはなるべく避けたい。そこでキャッシュの出番になる。 GitHub Actions ではデフォルトで何もキャッシュされないため、基本的には公式のactions/cacheを使うことになる。 actions/cacheはキャッシュするファイル・ディレクトリを指定し、それにキャッシュキーを紐付けるだけ、という単純なものだ。
Angular: ESLintサポートの現状 2020 Autumn | Marginalia
Angular v11.0.0のリリースとともに、Angularの開発ロードマップも更新された。 この記事では開発ロードマップから “Migrate To ESLint” が消えたことと、Lintingに関するAngular CLIの動きについて簡単にまとめる。 TL;DR要点だけ知りたい人は次のことだけ持ち帰って欲しい。 TSLintからESLintへの移行はサードパーティのangular-eslintの利用を公式に推奨している Angular CLIのデフォルトLinter(TSLint)はv12で非推奨になる angular-eslintAngularチームがTSLintからESLintへの移行を考え始める以前から、angular-eslintプロジェクトはTSLint+Codelyzerの機能をESLintで再現するツールを開発してきた。 近々angular-eslintのリリース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
