Popular React Folder Structures and Screaming Architecture
Screaming ArchitectureEvolution of a React folder structure and why to group by features right away React folder structures have been debated for years due to React's unopinionated approach, leading developers to ask, "Where should I put my files? How should I organize my code?" I've researched the most popular approaches to organizing React projects: Grouping by file type like components, context
GraphQL の Fragment Colocation を導入したら依存関係がスッキリしてクエリもコンポーネントも書きやすくなった
この記事は Money Forward Engineering 1 Advent Calendar 2022 11 日目の投稿です 🎄 昨日 10 日目は cabossoldir さんによる 『コードレビューのとき、私は何をレビューしているのか？』 でした。 🙈 TL;DR Fragment Colocation とは、コンポーネントが必要とするデータを Fragment にまとめてコンポーネントと同じ場所に配置 (co-locate) すること Fragment Colocation を導入することで、「Query や Mutation を実行するコンポーネント」と、「それらの結果を必要とするコンポーネント」との関心の分離ができる Query, Mutation, Fragment はそれを実行するあるいは必要とするコンポーネントと同じファイル内に宣言すると依存関係が見やすく、変更が
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
Reactでロジックをhooksにまとめないという選択肢 - Hello Tech
javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 突然ですが、Reactを使用する際、コンポネントのロジックや状態が増えてきたとき、みなさんはどうされてるでしょうか。 関数コンポネントでは、一般にcustom hooksとしてまとめて切り出すことが多く行われていると思います。 今回の記事では、useState/useRef + custom hooksという単位で切り出すのではなく、 クロージャを使いロジックや状態をコンポネントの外に持たせるようにリファクタリングすることで、コードの見通しが良くなる、という事例を紹介します。 JavaScriptにおけるクロージャとは、関数が外側のスコープの変数などへの参照を保持できる機能のことです。ここではクロージャとして実装しましたが、同等のことはclassを使っても実装できます。 A
【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々
CSSとコンポーネント設計に対する考察 - uhyo/blog
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
React+Fluxアプリケーションにpropsバケツリレーは必要か
React+Fluxアプリケーションのメンテをしている中で「propsのバケツリレーを減らすためにContainerを増やしてもよいか？」というディスカッションになったので、考察をまとめてみます。 いまの設計の確認 FluxUtilsフレームワークを利用している 複数のStoreを持つ ComponentTreeのRootをContainerとし、StoreのStateを受け取る Tree状に配置された各Componentにはprops経由で状態を受け渡す 各Componentはローカルステートを持つことができる ちなみに、ここで言うFluxの定義については「React+Fluxで正しく設計するためのFlux見直しガイド」にてまとめています。 propsのバケツリレーと単一Containerとは？ Reactアプリケーションでしばしばある「ComponentTreeのRootでアプリケーシ
フロントエンドのコンポーネント設計に立ち向かう - Qiita
ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コンポーネント設計？なにそれ？おいしいの？」という方 初めてコンポーネント設計でアプリ作ってみたけど、本当にこれでいいのか自信の無い方 はじめに: "コンポーネント"とは まず最初に"コンポーネント"という言葉についてですが、ここでは「GUIのパーツをモジュー
Reactアプリのコードを美しく保つ「高階コンポーネント」の考え方とは？
Reactアプリケーションを整理して構築し、保守を簡単にするためにHigher-Order Componentsを使用する方法について説明します。純粋関数でコードをクリーンに保つ方法や、同じ原理をReactコンポーネントに適用する方法を紹介します。 純粋関数 以下のプロパティに従っている場合、その関数は純粋であると見なされます。 取り扱うすべてのデータが引数として宣言されている 与えられたデータやその他のデータを変化させない（多くの場合、副作用と呼ばれる） 同じ入力には、常に同じ出力を返す たとえば、以下のadd関数は純粋です。 function add(x, y) { return x + y; } しかし以下のbadAdd関数は純粋ではありません。 var y = 2; function badAdd(x) { return x + y; } badAdd関数は直接与えられていないデー
Reactの Higher-order Components (HoCs) という概念に関するメモ - Qiita
ReduxなどReact関連のライブラリで時々出てくるHigher-order Componentsについて色々わかんなくなったので調べたことをメモ程度に留めてまとめる 通称 HoCとかHoCsとか略されるが、この記事では Higher-order Components、HoCsで統一しておく。 Higher-order Components(HoCs)とは？ 語の元となったのは高階関数(Higher-order function)であると思われる。 高階関数は、「関数を引数にとり、関数を戻り値とする」ような関数の事。 HoCsも同様で、「Componentを引数にとり、Componentを戻り値とする」ような関数（または実装パターン）の事 1 なぜこんな概念が出てきたのか？ この記事が良く出される Mixins Are Dead. Long Live Composition ざっくり要約
FluxのActionとStoreをちゃんと分ける話 - pixiv inside [archive]
ピクシブ株式会社 Advent Calendar 2015、19日目の記事です。 qiita.com こんにちは、愛らしくも憎らしいJavaScriptを書いてご飯を食べている @geta6 です。業務では pixiv Sketch というサービスの開発や運営に携わっています。 pixiv Sketchでは、node.jsとReact/Fluxibleを使用してサーバーとクライアントを同じコードベースで動作させるIsomorphicな構成を採用しています。 このプロジェクトでコードレビューをしていて、チームメンバーがつまずきやすいと感じたのが『FluxにおけるActionとStoreのどちらに何を実装するべきか』という点でした。 そこで、本日は『ActionとStoreとの適切な責務の持たせ方』について話をしたいと思います。 ReactとFluxについておさらい 今年の4月にこんなスライド
![FluxのActionとStoreをちゃんと分ける話 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0da913cbf8a21a9b94e0b3b6024eb39bf6869768/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fg%2Fgeta6%2F20151218%2F20151218175826.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
