React Architecture: How to Structure and Organize a React Application
There is no consensus on the right way to organize a React application. React gives you a lot of freedom, but with that freedom comes the responsibility of deciding on your own architecture. Often the case is that whoever sets up the application in the beginning throws almost everything in a components folder, or maybe components and containers if they used Redux, but I propose there's a better wa
React で <Stack.Item> みたいな作り方の使い所を考える
自分ではあまり使ったことがないのですが、最近他所のデザインシステムの実装なんかを眺めていて <Stack.Item> のようにあるコンポーネントのプロパティとして他のコンポーネントを定義するパターンを何度か見かけて、どんな時に有効なのかを考えてみたくなった次第です。 具体例 Shopify のデザインシステムの中にある Stack と Stack.Item が当てはまります。 これらのコンポーネントは次のようにセットで使われます。 <Stack> <Stack.Item fill> <Heading>Order #1136</Heading> </Stack.Item> <Stack.Item> <Badge>Paid</Badge> </Stack.Item> <Stack.Item> <Badge>Fulfilled</Badge> </Stack.Item> </Stack> //
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
atoms の「制御・非制御」をどう作るのか
本稿では React で atoms を作る際「制御・非制御」どちら前程に作るべきか？という課題についてを考察します。 「制御・非制御」は atoms では決定しない なぜ決定しないのかは「ライブラリ選定に縛られないため」につきます。Form 関連ライブラリはたくさん選択肢がありますが、この選定が atom に影響するのはあまり良いパターンではありません。 「制御・非制御」は atoms では決定しないといっても、正確には以下の「A・B」のうち 「A」で決定しない という意味です。以下「A・B」の様にきちんと分けて構成することで「A」は「制御・非制御」に囚われず、再利用することが出来ます。 A. 【"style"決定層】CSS のみが適用された element 集 B. 【"制御・非制御"決定層】A を用いて、再度小さい atom を構築する CSS in JS 以外での定義 CSS in
フロントエンドでClean Architectureを適用してみる(+サンプルコード) - Qiita
ここ数年でClean Architectureはおなじみのアーキテクトとして親しまれるようになりました。 とりわけ単体テストを書く習慣が根付いているバックエンドで重点的に取り入れられているように見受けられますが、フロントエンドにおいても同様にClean Architectureを導入し、メリットを享受できます。 今回はフロントエンドにClean Architectureを導入する手順を、実際にコードを追いながら紹介していきます。 実際のコード 実際に書いたコードはこちらのGithubに公開しています。データを外部から取得するフローを表現するために、node.jsで実装されたモックサーバーも用意しました。 https://github.com/t-tiger/React-CleanArchitecture-Example 前提知識 Clean Architectureでおなじみの図と共に前提
Next.js 10 の画像最適化システム next/image を読んで理解を深める
※ ソースコードは 2020/11/20 時点の canary ブランチを参照しています。 Next.js 10 では next/image から提供されるコンポーネントを使用することで、開発者が特別に意識することなく画像を最適化することができるようになりました。リリースのタイミングで Next.js Conf が開催されていたこともあり、この機能は大きく話題になりました。 今回はコードを読みながら最適化の裏側を紐解いて next/image の理解を深めようと思います。 何を調べるのか 目的を持たずに読んでいると露頭に迷いそうなので、最初に何を調べるのか決めました。 今回は最適化の仕組みを紐解くことを目的として、コードを読みながら次の 2 つについて調べます。 最適化された画像の出し分け 画像最適化処理 結論 最適化された画像の出し分け img 要素の srcset 属性を利用して画面サ
経年劣化に耐える ReactComponent の書き方 - Qiita
「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type
API 設計ガイド | Cloud API Design Guide | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
SNS時代のマーケティングフレームワーク「DRESS」とは？
マーケティングやビジネスに関わる方なら、みんな「AIDMA」や「AISAS」をご存知だと思います。 AIDMAとは、消費者が購買を決定プロセスのことです。これは ・製品の存在を知る（Attention） ・興味をもつ（Interest） ・欲しいと思う（Desire） ・記憶する（Memory） ・購買する（Action） の頭文字をとったものです。Wikipediaによると AIDMAとは1920年代にアメリカ合衆国の販売・広告の実務書の著作者であったサミュエル・ローランド・ホールが著作中で示した広告宣伝に対する消費者の心理のプロセスを示した略語である。となっています。 昔の広告らしいなーという感じはするものの、今の日本でも、「人に欲しいと思わせるために恐怖などの感情を刺激したり、一貫性を持って量を投下しまくることで、記憶させる」という手法はよく使われるので、非常に優れたフレームワークと
なぜ作ったゲームが面白くならないのか？基礎にして奥義「フロー理論」｜かえるD
そろそろ、ゲームデザインの話もしていこうかと思う。今回は、ゲームが面白いとはそもそも何なのか？そもそもゲームとはなんなのかを紐解き、そこからどうすれば面白くなるのかを書いていこうと思う。 そして、最初に本記事の結論を書いておく。 ・ゲームとは学習を嗜好品化したものである ・人が学習から面白いと感じるには条件がある＝フロー理論この二つが、本記事の結論である。面白いと思ったら、この先を読み進めていただければ幸いだ。 そもそもとして、今回の記事をnoteに書こうと思った理由の一つとして、毎年新卒に向けて同じような話をするのだけれど、ずっと張り付いて教えられるわけでもないし、必要になったタイミングで情報を提供しないと、なかなか身に付かないので、これ参考にすると良いよというような似たようなまとまったリファレンスがほしかったのだ。でもそのようなリファレンスは存在しないので自分で書こうと思った次第だ。
私のReactのコンポーネント実装アンチパターン
(編集: React以外のライブラリで当てはまるか確認できておらず、主語がデカめなのでタイトルに"Reactの"をつけました) この記事はコンポーネント指向開発における、私が実際に産み出した/遭遇したアンチパターンをまとめたものです。 コンポーネント設計論はちらほら見かけますが、アンチパターン集はあまり見たことないなと思ったことと、実際の開発していくにあたってより具体的なアンチパターン例があった方が学びが捗るのではという思いからこの記事を書き始めました。似たようなコードを書いた時に参考になれば幸いです。また、絶対的な解があるものでもないと思っているので、より良い案などございましたらコメントいただけると嬉しいです。 なお、思いつきベースで書いているので特に網羅性はないです。 忙しい人のためのサマリ 中間のProp変化 あるコンポーネントが他のコンポーネントで何がどう表示されるかを知っているよ
React hooks: not magic, just arrays – Rudi Yardley – Medium
I am a huge fan of the new hooks API. However, it has some odd constraints about how you need to use it. Here I present a model for how to think about using the new API for those that are struggling to understand the reasons for those rules. Unpacking how hooks workI have heard some people struggling with the ‘magic’ around the new hooks API draft proposal so I thought I would attempt to unpack ho
Herokuで成功させるサービス開発 - ボクココ
ページ版執筆にあたって ども、@kimihom です。 技術書典5で販売した書籍の記事版として公開します。より多くの方へ Heroku でサービス開発を成功させていただきたいという思いから、ボクココの固定ページとして無償公開するに至りました。 なお、本記事は、Heroku 社から認められていない非公式の記事となります。予めご了承ください。 はじめに Happy Coding! 本記事はWebサービス開発を本気で成功させたいと考えているエンジニア向けに、サービス開発とHerokuの運用に関して記しています。サービス開発を成功させるには、限られた時間の中で注力すべき内容を見極め、サービスの差別化を推し進めることが重要です。ユーザーはなぜ他の多くのサービスではなくて、あなたが作ったサービスを使うのか。その問いに自信を持って答えられるようにしなければなりません。その状況の中で、どのテクノロジーを採
リファクタリングして学ぶTypeScriptでクリーンアーキテクチャ - Qiita
概要 最近，ASCII Dwangoさんから「クリーンアーキテクチャ」という本が出版されました． そこに書いてある内容は素晴らしいものでした．しかし，実際に組んでみた場合，どういう風に作るのが良いのか？どういう問題があるのか？そういった疑問が湧いてきました．そこで， 実際に非クリーンアーキテクチャのコードをリファクタリングしていくことで，クリーンアーキテクチャの要点を感じる． という試みです． クリーンアーキテクチャとは ここでは簡単にしか説明しませんが，実際に本を読んで勉強することをお勧めします． 「クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計」のp200によると フレームワーク非依存：アーキテクチャは，機能満載のソフトウェアのライブラリに依存していない．これにより，システムをフレームワークの制約で縛るのではなく，フレームワークをツールとして使用できる． テスト可能：ビジネ
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hooks時代の設計の話 #agrinoteinside
Atomic Architecture
率土之滨2018组合搭配_率土之滨攻略_9k9k手游网