Burikaigi 2023 https://burikaigi.dev/ Twitter https://twitter.com/__sakito__
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント(使用者)で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
Front-End Study #5 の発表資料です。 https://forkwell.connpass.com/event/205227/ フィードバックはこちら: https://koibu.me/events/14/talks/wQQs0pbvMZHcnZ8TawAi
eslint-plugin-prettier 時代の設定をずっと使っていたので、重い腰を上げてアップデートした作業メモ。 背景 Prettier 公式ドキュメントによれば、現在 eslint-plugin-prettier は以下の問題があるとして推奨していない。 エディタが真っ赤になる(人間が気にする必要のない問題なのに!) 直接実行するより遅い(同様に prettier-eslint も遅い) ESLint と Prettier の間に間接レイヤーを追加するので、壊れやすい なるほど正しい。 一方、別々に実行することで以下のような問題も出てくるので、解決していく。 CLI とエディタを個別に設定する必要がある エディタで ESLint と Prettier の協調動作が必要 CLI (npm scripts) で ESLint と Prettier の対象ファイルが別管理になる 上記の
はじめに HotwireはBasecampが発表した、モダンなWebアプリケーションを作るための新しいアプローチです。名前もHTML OVER THE WIREから来ているように、HotwireではHTMLをサーバーから送ります。「それ普通のWebアプリケーションでは?」と思う方もいるかもしれませんが、SPA + APIサーバでJSONが使われるのに対し、SPAと同様の体験をHTMLを中心に置いて作るアプローチであることを示す表現です。 僕個人は、最初は「ふ〜ん」という感じだったんですが turbo-railsを読みつつHotwireのデモアプリをPhoenixに移植してみたり WebSocketではないTurbo Streamsのsourceを作ってみて遊んだり と、ある程度触ってみて良さが理解できてきたので、Hotwireを使うと何が嬉しいのか、Hotwireの各要素の紹介を記事として
注意 この記事は 2020 年 09 月 24 日現在、古い情報となりました。 eslint-plugin-prettier の利用は非推奨であると公式がアナウンスを出しています。 そのことについては Prettier と ESLint の組み合わせの公式推奨が変わった にてまとめましたので、こちらもご覧ください。 また eslint-plugin-prettier は公式推奨ではなくなりましたが、それは Editor などの外部環境の進化によるものでこのプラグイン自体に何か問題が起きたわけではありません。 そして eslint-plugin-prettier を利用した設定方法、特に eslint-plugin-prettier と eslint-config-prettier が何を解決していたかを知らないと、prettier-eslint が何をどう解決したかを理解できないはずなので
Transcript ݱϑϩϯτΤϯυʹ͔ܽͤͳ͍ XFCQBDLͱ#BCFMΛཧղ͠Α͏ʂ� CVJMEFSTDPO�UPLZP����� /BNF� ����4BLJUP�.VLBJ� 5XJUUFS ����!@@TBLJUP@@� $PNQBOZ� ����$ZCP[V�JOD� ����'SPOUFOE�&YQFSU�5FBN "CPVU�NF w#BCFMͷલʹݱࡏͷ+BWB4DSJQUʹ͍ͭͯ� w#BCFMʹ͍ͭͯ� wXFCQBDLʹ͍ͭͯ� wXFCQBDL #BCFMͰ෦࣮Λ͍ͬͯ͘ "HFOEB #BCFMͷલʹݱࡏͷ+BWB4DSJQUʹ͍ͭͯ &$."4DSJQUͱ5$�� w+BWB4DSJQUʹ&$."4DSJQUͱ͍͏ݴޠ༷͕͋Δ� w͜ͷݴޠ༷ΛܾΊ͍ͯΔҕһձ͕5$�� 5FDIOJDBM�$PNNJUUFF��� � w&4��
Transcript ΅͘ͷϑϩϯτΤϯυֶश .JY�-FBQ�4UVEZ�ಛผฤ���$50�/JHIU�,"/4"*�7PM�� wTBLJUP !@@TBLJUP@@ � w'SPOU�&OE�&OHJOFFS� w3FBDU XFCQBDL (BUTCZ+4� w&WFOU� w#POpSF�'SPOUFOE� w3FBDU�NFFUVQ� w*OTJEF�'SPOUFOE� ϠϑʔͰͬͯΔ͜ͱ wϑϩϯτΤϯυνʔϜʹॴଐ� w#UP#ͷϑϩϯτΤϯυ� wओʹ3FBDUΛ͍ͬͯΔ� wٕज़બఆɺϨϏϡʔɺ։ൃͳͲ� wશࣾϑϩϯτΤϯυΠϕϯτͷ։࠵� wϥϯνձ� w-5ձ� wࣾ֎͚ษڧձ ϓϥΠϕʔτͰͬͯΔ͜ͱ wϑϩϯτΤϯυؔ࿈ͷهࣄΛॻ͘� wษڧձ� wओ࠵Λ͢Δ� wࢀՃΛ͢Δ� wελοϑʹͳΔ� w෭ۀΛ͢Δ ࠓ͢͜ͱɺ͞ͳ͍͜ͱ ࠓ
Frontend Conference Fukuoka 2018で発表した資料です。 https://frontend-conf.fukuoka.jp/ 各リンク先を確認する場合は、以下のpdfを参照ください http://tonkotsuboy.github.io/slides/181204_frontend_fukuoka/181208_frontendconffukuoka.pdf はてなブックマーク http://b.hatena.ne.jp/entry/s/speakerdeck.com/tonkotsuboy_com/2019nian-madenijian-zhi-siteokitai-cssjavascriptfalseshou-fa ご意見やご感想はTwitter ( https://twitter.com/tonkotsuboy_com ) までお寄せください。 #fec
Navigation Timing とか Resource Timing とか、パフォーマンスまわりのAPIについて自分で整理できていなかったので、これを機会にまとめてみました。
相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか? ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか? 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く