[React🐣 ]宣言的UIの構築をシンプルなプロセスで理解する
この記事で話すこと この記事ではReact入門者の方、UIの状態管理についてよく悩んでしまう人を対象に書いています。 いきなり複雑な状態管理を考え出すのではなく、そもそも宣言的UIの構築プロセスを頭の中に置いてそのコンポーネントの状態を特定し、整理することで管理する状態を明確にします☺️ 宣言的UIの構築プロセスを通し、react入門・初心者がいきなり状態管理を考え出して手が動かなくなる状態を脱却することを目的にしています。 宣言的UIの構築をフォームコンポーネントを例に４STEPで理解する 今回は「入力値を送信するテキスト入力フォーム」を例にとって4stepでプロセスを理解する コンポーネントの状態を列挙してみる 状態変化のきっかけのトリガーを特定して、フローを作る useStateを使って状態を宣言する 状態のリファクタリング（今回は不要・重要でない状態変数を削除する） 目標：最初から
![[React🐣 ]宣言的UIの構築をシンプルなプロセスで理解する](https://cdn-ak-scissors.b.st-hatena.com/image/square/a1ee0c459e1b4a4aea78c40bcee51962a03421c4/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--wJ9KmAW9--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BReact%252520%252520%25255D%2525E5%2525AE%2525A3%2525E8%2525A8%252580%2525E7%25259A%252584UI%2525E3%252581%2525AE%2525E6%2525A7%25258B%2525E7%2525AF%252589%2525E3%252582%252592%2525E3%252582%2525B7%2525E3%252583%2525B3%2525E3%252583%252597%2525E3%252583%2525AB%2525E3%252581%2525AA%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252582%2525BB%2525E3%252582%2525B9%2525E3%252581%2525A7%2525E7%252590%252586%2525E8%2525A7%2525A3%2525E3%252581%252599%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AAltppp%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzVmZmJmYTgzYTkuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
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
【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々
Reactのディレクトリ構成でAtomicデザインをやめた話
Atomic デザインをやめた 結論から言うと Atomic デザインを React のディレクトリ構成に当て込むのをやめました。結構ツラミが出てきてしまった感じです。とはいえ、Atomic デザインを批判するわけではなく、むしろ概念というか考え方は好きな部類です。 あくまでデザインシステムであり、ディレクトリ構成に当て込むべきものではないなと。 以前までのディレクトリ構成はこんな感じ Atomic デザインが話題になった頃からそれに倣ったディレクトリ構成にしていました。Next.js のプロジェクトになってしまいますが大体こんな感じ。 ├── common │ ├── config │ ├── styles │ ├── types │ └── utils ├── components │ ├── atoms │ ├── molecules │ ├── organisms │ └── te
Reactのprops/contextの使い分け - saneyuki_s log
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針
脱Reduxを試みて失敗した話、その原因と対策について
さて、年末が近づいてきましたが今年も 「Redux 使うべき使わないべきか」という話で盛り上がりましたね。 僕もずっと悩める人なのですが、@f_subal さんの Tweet や @takepepe さんの Next.js の状態管理 2020 が示すように Read 要件・Write 要件の多さで使い分けるという指針には深く納得をしました。 Redux の代替になるツールやノウハウもより活発に出てきて、Redux 以外の選択肢を考えるにあたって様々な学びがあった 1 年でした。 自分も色々と Redux 以外の選択肢を試していたのですが、その中で「やっぱ Redux を使えばよかった」と思ったときがあったので、これから Redux を剥がそうと考えている人に向けてその失敗談を語りたいと思います。 自分も手探りで正解がわかっていないところなのでアドバイス・反論・指摘などがあれば頂きたいです
綺麗なReactコンポーネント設計でモノリシックなコンポーネントを爆殺する - Qiita
まずはじめに Reactはユーザインターフェース構築のためのJavaScriptライブラリです。 React は、インタラクティブなユーザインターフェイスの作成にともなう苦痛を取り除きます。アプリケーションの各状態に対応するシンプルな View を設計するだけで、React はデータの変更を検知し、関連するコンポーネントだけを効率的に更新、描画します。 React公式より Reactのプロジェクトである程度規模が大きくなっていくと問題になっていくのは きちんと設計しないとビジネスロジック、コンポーネントのステート、表示 これらが入り混じって数百行の巨大なコンポーネント（モノリシックなコンポーネント）ができてしまう場合があることです。 確かにReactはユーザインタラクティブなViewの作成には強力な力を発揮しますが、 綺麗なコンポーネント設計に関しては利用者に委ねられています。 (Reac
React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 | ランサーズ（Lancers）エンジニアブログ
@tsuyoshi です。先日行われた React Redux を用いた SPA 新規サービスを運用して得た知見と実装例 と言うイベントで使ったスライドをアップロードしました。 https://pook.life/ と言うサービスをReact Redux の SPA で運用して得た知見などを共有できればと思い。公開してみた次第です。 内容としては 利用しているライブラリや開発環境、開発フロー コードベースでの実装例の紹介 その他 SPA サービスを運用する上での構成や知見 など、実例や結果を交えながら説明しています。 何かの参考になれば幸いです。 スライドを貼ってますが、以下のgoogle スライドで見た方が、アニメーションとか動いて見やすいかもしれません。 https://docs.google.com/presentation/d/1TIEg5rYJ9vlWTSO6etwupBBO0e
Reactアハ体験 - Qiita
Reactはちょっとしたコツを掴むと一気に理解が進みます。 Googleのデベロッパーであり数々のReactトレーニングを手がけてきたTyler McGinnis氏によるReact "Aha" Momentsが非常に参考になるため、本人の許可を得て意訳しました。 誤りやより良い表現などがあればご指摘頂けると助かります。 原文：https://tylermcginnis.com/react-aha-moments/ 私が技術的なコンテンツを教えたり書いたりする時の主な目標の1つは「アハ体験」を最大化することです。アハ体験は物事が突然理解できた瞬間のひらめきです。私たちは皆これを体験してきましたし、私の知る最高の教師たちは聴衆に応じて、それらの瞬間を最大化するための教えを最適化することができます。 ここ数年、私はほぼ全ての一般的なメディアでReactを教えてきました。その間、私はReact習得
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
React.js 実戦投入への道 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近話題のReact.jsですが、実戦投入に当たっては結構重たい選択を迫られることになります。 ざっくり言えば、テンプレートエンジンを捨ててReactしますか?それともReactあきらめますか?という選択です。 本記事ではReactの基本思想とこうした選択肢が生まれてしまう背景を述べるとともに、後半では「どちらもあきらめない」という(若干シミュレーションRPGあるある感のある)第三の方策について案を提示します。 Reactの基本 最初に、Reactの基本的な仕組みについてまとめておきます。 Reactは公式ドキュメントが非常に充実してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そのファイル、本当に hooks/・utils/ に入れるんですか？ ―― React プロジェクトを蝕む「見かけ駆動パッケージング」 - Qiita
reactの基礎と設計パターン