再考: アプリ開発と状態遷移の管理 - ninjinkun's diary
自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態
Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか Reactを取り巻く状態管理のアプローチは変化を続けていますが、いま知っておくべき手法とはどのようなものでしょうか。小林 徹（@koba04）さんに、現在、そしてこの先の状態管理について執筆いただきました。 こんにちは、小林（@koba04）です。 2019年5月に『SPAにおける状態管理:関数型のアプローチも取り入れるフロントエンド系アーキテクチャの変遷』という記事を書きましたが、そこから2年以上が経過し、Reactを用いた状態管理は大きく変わりました。本記事ではReactを取り巻く状態管理の変遷について解説します。 広がるReduxの採用 Hooksの登場 コンポーネントツリーから独立した状態管理 Concurrent Featuresによる新しいユーザー体験 状態とキャ
ウェブフロントエンドの設計力を高めるためにアプリケーションの構造を捉えてみる話 - Chatwork Creator's Note
こんにちはー。 フロントエンド開発部の火村(ひむら/id:eiel)です。前回までは id:cw-himura で記事を書いていましたが、個人アカウントに切り替わりました。 よろしくおねがいします。 以前はサーバーサイド開発部に所属していましたが、2019年6月ぐらいからフロントエンドチームにヘルプとして無期限レンタル移籍中です。 主な担当している業務は「難しいバグ対応」と「これからChatworkのウェブフロントエンドをどうするかを考える」です。 昨日は期待の新人であるレオくんの入社して3ヶ月の熱烈な想いでした。アツいです。 さて、今回のお題は「レガシーフロントエンド脱却への挑戦」と雑に上から投げられたのですが、未来のことを考える作業をしているので書きやすいネタがありません。 あってもオチがつきません。 ということで、設計に役立つかもしれない話をラフに書くことにしました。 アプリケーショ
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
HTML5 Conference 11/25
フロントエンドのコンポーネント設計に立ち向かう - Qiita
ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コンポーネント設計？なにそれ？おいしいの？」という方 初めてコンポーネント設計でアプリ作ってみたけど、本当にこれでいいのか自信の無い方 はじめに: "コンポーネント"とは まず最初に"コンポーネント"という言葉についてですが、ここでは「GUIのパーツをモジュー
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
LDRがサービス終了のため、Inoreader/Feedlyをバックエンドに動くRSSリーダを書いている
LDRがサービス終了のため、Inoreader/Feedlyをバックエンドに動くRSSリーダを書いている 追記: 1.0.0を出して説明を書き直したので、Irodrを使いたい方はLDRライクなRSSリーダのIrodr 1.0.0をリリースした | Web Scratchを参照してください。 2017年8月31日をもってLDRはサービス終了です。乗り換え先となるRSSリーダを探したりしましたが、求めるものを見つけることができなかったので作ることにしました。 【重要】Live Dwango Reader/LDR Pocketサービス終了のお知らせ｜LDR / LDRポケット 開発日誌 次の記事でも書いていましたが、RSSリーダのバックエンドを自前で管理するのはコスト的に難しそうでした。そのため、バックエンドとしてInoreaderやFeedlyのAPI使ったRSSリーダのウェブクライアントを書
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
フロントエンドを楽にするために
フロントエンドを楽にするために Qiitaを支えたい技術 at 時雨祭 About HN: mizchi Qiitaの方からきました(入社半年たったらしい) Reactオジサンはそろそろ飽きてきた Angularに興味が無いのでこっちにきた 最近の業務 Kobito for Windows Closedβ中: もうちょい待ってろ お前らウェブエンジニアはWindows使わないのでβユーザー集めにくいんじゃ 省力モード 一昨日がClosedβリリースだったんで察してくれ！！！ ついさっきまでバグフィックス用のビルド作ってた Qiitaを支える技術? 4ヶ月ほどほぼソロ作業 正直カウボーイぎみ OSSでドキュメントガンガン書いてカバー(したい) 業務から派生したOSS mizchi/arda Flux フレームワーク mizchi/stone-skin IndexedDb ラッパー mizch
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UIT INSIDE