なぜ現代フロントエンドの State 管理は難しいのか考える
このスクラップについて 現代フロントエンドの問題点として、State 管理の難しさがあります。 例えば、少し前までは Redux などに代表される Flux アーキテクチャ を採用( または継承 )した State 管理がデファクトスタンダードでしたが、扱う State の数が多くなるにつれて管理が大変になったり、Next.js などの活躍による SPA の縮小などの問題が浮上してきて使われなくなっています。 しかし、 Flux アーキテクチャ を代替するようなモノは 2023/03 現在のところ存在せず、実態としては各プロジェクトごとに自分たちで State 管理を考えているような状態です。( swr などありますが、全ての State 管理を任せるには少しキツイ ) このスクラップでは、なぜ現代フロントエンドの State 管理は難しいのか考え、どうすればこの問題を解決できるのか考えて
tsconfig.json 設定項目備忘録
型推論オプション 型推論の結果が変わるもの。 ⭐strict ... 以下のセット alwaysStrict strictNullChecks T | null や T | undefined が T に縮退しなくなる。 例 strictBindCallApply Function の各種メソッドが any に縮退しなくなる。 例 strictFunctionTypes コールバック関数の引数が共変でもunifyするようになる結果、型変数の推論優先度が変わることがある。 例 strictPropertyInitialization noImplicitAny 宣言型がない場合にflow typeが使われる機会が増える。 例 noImplicitThis thisの宣言型がない場合に文脈から型が決定される機会が増える。 例 useUnknownInCatchVariables catch (
Lage
Finally a task runner that truly understands the structure of my workspaces! —Jason Gore, Microsoft Loop Seriously, never build more than onceBuilding once is painful enough! Lage will remember what is done before and skip any work that is not needed. Lage even skips the work based on your changes… really!
WebアニメーションはRiveが便利！
みなさんは、Web アニメーション使っていますか？ おそらくLottieを使っている人が多いかと思います。 ただ、Lottieには大きな問題がありますね？ そうです。 Adobe の After Effects（AE）がないとアニメーションが作れないという問題です。 たくさんの人たちが嘆き苦しみながら AE を使うために Adobe に課金している事だと思います。 そんな人々を救うため、 最近では AE を使わなくてもアニメーションを作れるようにとLottie Labというサービスが開発されていたりします。 しかし、まだまだ公開には至っていない状態です。（2022/12/07 現在） そこで、Rive 登場 AE で行っていたアニメーションの作成から、書き出しまで全て Web 上で完結できるサービスです。 今回は、アニメーションの設定から React で動かすまでをやってみたいと思います！
SWR DevTools
DownloadYou can download the SWRDevTools extension at the following. ChromeFirefoxHow to UseYou don't need any setup if you use SWR v2, just open SWRDevTools extension on your application! ⚠️ If you use SWR v1, Install swr-devtools and wrap your application with the SWRDevTools component. Please see the more details in the documentation FeaturesOpen the Developer Tools of browsers and select the S
今まで知らずにいたnpmスクリプトでできる3つのこと
製品 コミュニケーション メッセージング マルチチャネルのテキストメッセージとメディアメッセージの送受信を180か国以上で
Cloud Run東京リージョンにカスタムドメインをマッピングするとどのくらいのレイテンシが発生するのか
調査結果まとめ 日本の真ん中あたりから東京リージョンのCloudRunにアクセスしたときのTTFB（Time To First Byte）のざっくり計測結果。詳細は後述。 Cloud Runのデフォルトドメインに直接アクセスした場合: 28msくらい Cloud Runにカスタムドメインをマッピングした場合: 99msくらい さらにCloudflareからCNAMEで指した場合: 114msくらい Cloudflare WorkersでCloud Runのデフォルトドメインをプロキシした場合: 44msくらい Cloud Run + Cloud Load Balancing（CDNなし）: 31msくらい Cloud Runの東京リージョンで「カスタムドメインのマッピング」を利用するとレイテンシが発生する 2023年1月現在、Cloud Runのドキュメントの既知の問題には以下の記載があり
Electronライクな新フレームワーク「Gluon」登場。Chromium内蔵せずWebブラウザを利用、Node.jsだけでなくDenoとBunにも対応
デスクトップアプリケーションの開発を、JavaScriptなどのWebテクノロジーで可能にするフレームワークとして知られるのがElectronフレームワークです。 このElectronのようなフレームワークが新たに登場しました。「Gluon」です。 Electronがアプリケーション基盤としてNode.jsとChromiumをバンドルするのに対して、GluonはOSにインストールされているWebブラウザを用いるのが大きな特長です。 Google ChromeのようなChromiumベースのWebブラウザだけでなく、Firefoxにも対応作業が進められており、最新のバージョン0.11ではFirefoxでの安定度が向上しました。 Node.jsをバンドルする点はElectronと同じですが、Node.jsの代わりにDenoやBunを利用することにも実験的に対応しています。 Gluonは主にCh
Cloudflare Pagesの開発でVite使う
Cloudflare Pagesの開発にはwrangler pages devが使えるんだけど、引数にコマンドライン渡せるの知らなかった。引数に渡したコマンドが開いたポートをリバースプロキシしてくれる。つまり、viteコマンドを渡せばViteのdevサーバーをバックエンドにしたWranglerが立ち上がり、裏側ではHMRが効く。これ何が嬉しいって、/functionsでAPIを作った場合にこれまでWranglerとVite2つ立ち上げていたのが1つで済むし、クライアントもAPIサーバーもホットリロード効くのでDXが良い。そして、これを利用すると例えば非常に少ないファイルでReactのSPAが作れる。 まずWranglerにコマンドライン渡せるやつはこんな感じ。 以下のスクショだと、Viteのdevサーバーが5175で立ったのを検出してWranglerがプロキシしている。 ではこれを利用して
ReactとCSSの新しいUIフレームワークを作った
リンク 公式サイト デモサイト 概要 Camome UI は React または HTML + CSS で使用できる UI フレームワークです。 ソースは React + CSS Modules で書かれており、 それを React コードからインポートするか、静的なクラス名で出力された CSS ファイルを読み込むことで使用できます。 特徴 軽量なバンドルサイズ 例えば @mui/material@5.11.6 の Button は単体で16.9KBあり、それに Emotion や ThemeProvider も加わります。 それに対して Camome UI の Buttonは単体で 1.42KB(CSS 含む)、それにグローバル CSS の 4KB が加わります（計測方法）。 これらのフレームワークは言ってみれば「フルスタック」であり、どんなウェブサイト・アプリでも構築できる柔軟性と機能
corepack を使って npm/Yarn をお仕事的に安心して使う方法を考える | t28.dev
npm/Yarn どっちでも良いけれど、ちゃんと管理されていて欲しい プライベートでは npm 一択ですが、お仕事環境では「〇〇プロジェクトでは npm、△△ プロジェクトでは Yarn を使ってる。バージョン？分からん。」となることは、まぁあると思います。 パッケージマネージャーのバージョン違いによってどれほどの差分が発生するかは正直分からないのですが(lockfile のバージョン違いは除く)、 バージョンを揃えて再現性を持たせるのは基本ですよね！ でも「バージョンを patch まで指定してるから気をつけてね！」とお願いするだけだと お仕事的には意味がない し、辛みが深い。 作業するプロジェクトごとに npm/Yarn とそのバージョンのスムーズに切り替えたいし、間違えていたらエラーにもなって欲しい。 つまり「〇〇プロジェクトでは npm vx.y.x、△△ プロジェクトでは yar
NodeでのCloud LoggingとError Reportの最適な使用方法を実験で導き出す
GCP の Cloud Run で Node のサーバを稼働させ、Cloud Logging にログを出力して、更にエラーが発生したときは Error Report で通知を受けるというような構成を組む際に、 どのようなケースで「重要度」が正しくマークされるのか どのような形式でログを吐けば Error Report が自動生成されるのか ドキュメントを読んでも、これらのことがいまいちわからなかったので実験してみました。 また、標準の console だけではなく、Node の主要なロガーライブラリーのうち、どれが一番 Cloud Logging と Error Report との相性が良いのかも実験から導き出しました。 前提 ロギング方法 Cloud Run で express サーバを用意し、下記のように文字列と Error をロガーで標準出力および標準エラーに出力 app.get("
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - pkgxdev/pkgx: the last thing you’ll install
もはや pnpm と Turborepo で Monorepo 環境作れるから