[B! react.js][design] somathorのブックマーク

[React🐣 ]宣言的UIの構築をシンプルなプロセスで理解する

この記事で話すことこの記事ではReact入門者の方、UIの状態管理についてよく悩んでしまう人を対象に書いています。いきなり複雑な状態管理を考え出すのではなく、そもそも宣言的UIの構築プロセスを頭の中に置いてそのコンポーネントの状態を特定し、整理することで管理する状態を明確にします☺️ 宣言的UIの構築プロセスを通し、react入門・初心者がいきなり状態管理を考え出して手が動かなくなる状態を脱却することを目的にしています。宣言的UIの構築をフォームコンポーネントを例に４STEPで理解する今回は「入力値を送信するテキスト入力フォーム」を例にとって4stepでプロセスを理解するコンポーネントの状態を列挙してみる状態変化のきっかけのトリガーを特定して、フローを作る useStateを使って状態を宣言する状態のリファクタリング（今回は不要・重要でない状態変数を削除する）目標：最初から

somathor 2022/08/09

リンク

そのファイル、本当に hooks/・utils/ に入れるんですか？ ―― React プロジェクトを蝕む「見かけ駆動パッケージング」 - Qiita

そのファイル、本当に hooks/・utils/ に入れるんですか？ ―― React プロジェクトを蝕む「見かけ駆動パッケージング」設計アンチパターンReact 結論 (2023/06/03 追記) React の開発においては、コロケーション Co-location の原則に従って、ファイルをディレクトリごとに分類しましょう。チームメイトや将来の自分にとって分かりやすいコードベースになります。スキット「書くときは楽だけど...」 == 某日 == 太郎くんの今日のタスクは、「トーストを作る」です。イメージ図太郎くん「コンポーネントを作るから..」「ファイルの場所は components/Toast.tsxでええか。」「useState でローカルに状態管理して、表示を切り替えればええやろ。」太郎くん「ヨシ！」この記事は、拙スクラップの一項目をモノローグ形式で分かりやす

somathor 2022/07/26

リンク

BOXIL SaaSのフロントエンドをモノリポ構成 + Reactで仕切り直した話 - SMARTCAMP Engineer Blog

こんにちは!! スマートキャンプでエンジニアをしている吉永(@__GGEasy)です！自己紹介記事はこちら前回の記事はこちら私は現在、スマートキャンプの主力サービスであるBOXIL SaaSの開発にフロントエンド、バックエンド問わず携わっています。今回は、弊社で新規サービスとしてリリースしたBOXIL SaaS質問箱(以下SaaS質問箱)にて、React.js(以下React)を私の主導で採用しました。この記事では、フロントエンド整備に至った経緯や、今後のBOXIL SaaSにおけるフロントエンドの技術的な展望についてお話します。 BOXIL SaaSのフロントエンドで抱えていた課題感さまざまな技術が同居している Vue + Atomic Designでの課題構成変更の検討どのようにフロントエンド構成を整備したのか SaaS質問箱のフロントエンド技術選定 React + T

somathor 2022/06/30

リンク

【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog

概要こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました）コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より）そこで今回は、数々

somathor 2022/05/24

リンク

Reactのディレクトリ構成でAtomicデザインをやめた話

Atomic デザインをやめた結論から言うと Atomic デザインを React のディレクトリ構成に当て込むのをやめました。結構ツラミが出てきてしまった感じです。とはいえ、Atomic デザインを批判するわけではなく、むしろ概念というか考え方は好きな部類です。あくまでデザインシステムであり、ディレクトリ構成に当て込むべきものではないなと。以前までのディレクトリ構成はこんな感じ Atomic デザインが話題になった頃からそれに倣ったディレクトリ構成にしていました。Next.js のプロジェクトになってしまいますが大体こんな感じ。 ├── common │ ├── config │ ├── styles │ ├── types │ └── utils ├── components │ ├── atoms │ ├── molecules │ ├── organisms │ └── te

somathor 2022/04/02

リンク

Reactのprops/contextの使い分け - saneyuki_s log

Reactのprops/contextの使い分け仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。公開したのは、時々見かける「どっちを使うべき？」みたいな議論に自分も混ざりたかった思うところがあったから. 「とにかくpropsでいい」と自分は考えている。なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい前提以下のように考える React/preact のコンポーネント = 通常のclassや関数状態を隠蔽して抽象する最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数）実装の指針

somathor 2021/03/24

リンク

脱Reduxを試みて失敗した話、その原因と対策について

さて、年末が近づいてきましたが今年も「Redux 使うべき使わないべきか」という話で盛り上がりましたね。僕もずっと悩める人なのですが、@f_subal さんの Tweet や @takepepe さんの Next.js の状態管理 2020 が示すように Read 要件・Write 要件の多さで使い分けるという指針には深く納得をしました。 Redux の代替になるツールやノウハウもより活発に出てきて、Redux 以外の選択肢を考えるにあたって様々な学びがあった 1 年でした。自分も色々と Redux 以外の選択肢を試していたのですが、その中で「やっぱ Redux を使えばよかった」と思ったときがあったので、これから Redux を剥がそうと考えている人に向けてその失敗談を語りたいと思います。自分も手探りで正解がわかっていないところなのでアドバイス・反論・指摘などがあれば頂きたいです

somathor 2020/12/14

リンク

綺麗なReactコンポーネント設計でモノリシックなコンポーネントを爆殺する - Qiita

まずはじめに Reactはユーザインターフェース構築のためのJavaScriptライブラリです。 React は、インタラクティブなユーザインターフェイスの作成にともなう苦痛を取り除きます。アプリケーションの各状態に対応するシンプルな View を設計するだけで、React はデータの変更を検知し、関連するコンポーネントだけを効率的に更新、描画します。 - React公式より Reactのプロジェクトである程度規模が大きくなっていくと問題になっていくのはきちんと設計しないとビジネスロジック、コンポーネントのステート、表示これらが入り混じって数百行の巨大なコンポーネント（モノリシックなコンポーネント）ができてしまう場合があることです。確かにReactはユーザインタラクティブなViewの作成には強力な力を発揮しますが、綺麗なコンポーネント設計に関しては利用者に委ねられています。 (Re

somathor 2020/09/25

リンク

reactの基礎と設計パターン

https://supporterzcolab.com/event/822/ の登壇資料です！参考リポジトリはこちらです。https://github.com/Dragon-taro/spz-react

somathor 2019/05/15

リンク

React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 | ランサーズ（Lancers）エンジニアブログ

@tsuyoshi です。先日行われた React Redux を用いた SPA 新規サービスを運用して得た知見と実装例　と言うイベントで使ったスライドをアップロードしました。 https://pook.life/ と言うサービスをReact Redux の SPA で運用して得た知見などを共有できればと思い。公開してみた次第です。内容としては利用しているライブラリや開発環境、開発フローコードベースでの実装例の紹介その他 SPA サービスを運用する上での構成や知見など、実例や結果を交えながら説明しています。何かの参考になれば幸いです。スライドを貼ってますが、以下のgoogle スライドで見た方が、アニメーションとか動いて見やすいかもしれません。 https://docs.google.com/presentation/d/1TIEg5rYJ9vlWTSO6etwupBBO0e

somathor 2017/11/20

リンク

Reactアハ体験 - Qiita

Reactはちょっとしたコツを掴むと一気に理解が進みます。 Googleのデベロッパーであり数々のReactトレーニングを手がけてきたTyler McGinnis氏によるReact "Aha" Momentsが非常に参考になるため、本人の許可を得て意訳しました。誤りやより良い表現などがあればご指摘頂けると助かります。原文：https://tylermcginnis.com/react-aha-moments/ 私が技術的なコンテンツを教えたり書いたりする時の主な目標の1つは「アハ体験」を最大化することです。アハ体験は物事が突然理解できた瞬間のひらめきです。私たちは皆これを体験してきましたし、私の知る最高の教師たちは聴衆に応じて、それらの瞬間を最大化するための教えを最適化することができます。ここ数年、私はほぼ全ての一般的なメディアでReactを教えてきました。その間、私はReact習得

somathor 2017/10/05

リンク

再利用可能なコンポーネントはアンチパターン - ジンジャー研究室

言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。以下、現時点での考え。ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。再利用可能なコンポーネントビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。

somathor 2016/08/03

リンク

React.js 実戦投入への道 - Qiita

最近話題のReact.jsですが、実戦投入に当たっては結構重たい選択を迫られることになります。ざっくり言えば、テンプレートエンジンを捨ててReactしますか?それともReactあきらめますか?という選択です。本記事ではReactの基本思想とこうした選択肢が生まれてしまう背景を述べるとともに、後半では「どちらもあきらめない」という(若干シミュレーションRPGあるある感のある)第三の方策について案を提示します。 Reactの基本最初に、Reactの基本的な仕組みについてまとめておきます。 Reactは公式ドキュメントが非常に充実しているので、始める際はぜひQuick Startのドキュメントに目を通すことをお勧めします。 Getting Started Tutorial Thinking in React 後述しますが、Reactを使ってアプリケーションを作る際の設計方法についての記載が

somathor 2015/03/16

リンク

はてなブックマーク

タグ

関連タグで絞り込む (8)

react.jsとdesignに関するsomathorのブックマーク (13)

お知らせ

今週のはてなブックマーク数ランキング（2024年11月第1週）

月間はてなブックマーク数ランキング（2024年10月）

今週のはてなブックマーク数ランキング（2024年10月第4週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス