こんにちは！フリーランスエンジニアの雄貴です！ Reactを用いたコンポーネント設計の方針は様々ありますが、 私が普段用いている手法を紹介しようと思います！ <h1 id="hd0ab3d0d4a">Reactのコンポーネント</h1>従来のコンポーネントだと、以下のコードのように関数の中でstate(状態)やfunction(ロジック)を定義し、それを「return」直下のview部分に渡してレンダリングしています。<pre><code>import React from 'react'

/**
 * InputForm
 * @returns
 */
export const InputForm: React.FC = () =&gt; {
 // state (状態)
 const [value, setValue] = React.useState('')

 // function (ロジック)
 const handleChange = (event: React.ChangeEvent&lt;HTMLInputElement&gt;) =&gt; {
 setValue(event.target.value)
 }

 // view (UI部分)
 return &lt;input type="text" value={value} onChange={handleChange} /&gt;
}</code></pre>上記はシンプルな例でしたが、より複雑なコンポーネントの場合だとどうなるでしょうか？ 例として「NOCHITOKU」ブログの記事ページのコンポーネントを見てみましょう！ <a href="https://www.nochitoku-it.com/about" target="_blank" rel="noopener noreferrer">ブログ記事ページ</a><pre><code>/* import, props部分は省略 */

/**
* BlogItemTemplate
 * @param props Props
 * @returns
 */
export const BlogItemTemplate: React.FC&lt;Props&gt; = (props: Props) =&gt; {
 const { blogItem, highlightedBody, tableOfContents, draftKey } = props

 const image: ImageType = {
 url: blogItem?.image?.url ? blogItem.image.url : '/no_image.png',
 width: blogItem?.image?.width ? blogItem.image.width : 750,
 height: blogItem?.image?.height ? blogItem.image.height : 422,
 }

 const router = useRouter()
 let shareUrl = NOCHITOKU_URL
 if (router?.asPath &amp;&amp; typeof router.asPath === 'string') {
 shareUrl = NOCHITOKU_URL + router.asPath
 }

 const metaData: MetaHeadType = {
 title: `${blogItem.title} | ${BASE_TITLE}`,
 description: blogItem.description,
 keyword: 'エンジニア,IT,プログラミング,フロントエンド,AWS',
 image: blogItem.image.url,
 url: NOCHITOKU_URL + router.asPath,
 }


 return (
 &lt;BasePostPageLayout metaData={metaData} breadName={blogItem.title}&gt;
 &lt;section className={styles.container}&gt;
 &lt;div className={styles.image}&gt;
 &lt;Image
 src={image.url}
 alt="Picture"
 width={image.width * 2}
 height={image.height * 2}
 /&gt;
 &lt;/div&gt;

 &lt;main className={styles.main}&gt;
 &lt;div className={styles.leftBar}&gt;
 {/* SNSシェアボタン */}
 &lt;SnsShareBar title={blogItem.title} shareUrl={shareUrl} /&gt;
 &lt;/div&gt;

 &lt;div className={styles.rightBar}&gt;
 {/* ブログタイトルエリア */}
 &lt;TitleArea blogItem={blogItem} /&gt;

 {/* 目次 */}
 &lt;TableOfContents tableOfContents={tableOfContents} /&gt;

 {/* 記事本文 */}
 &lt;HighlightBody highlightedBody={highlightedBody} /&gt;

 {/* SNSシェアボタン */}
 &lt;div className={styles.shareArea}&gt;
 &lt;SnsShareArea title={blogItem.title} shareUrl={shareUrl} /&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/main&gt;
 &lt;/section&gt;
 &lt;/BasePostPageLayout&gt;
 )
}</code></pre> コードが長くなっちゃいましたね。。 ロジックとUIの部分を分けて記載はしていますが、可読性は悪くなっています。 1つのコンポーネントファイルに様々な機能を盛り込みすぎると、返って分かりにくくなるので避けた方がいいですね。<h1 id="hc6c8e9e651">Container / Presentational構成</h1>今回、先述した課題を解決する手法として 1つのコンポーネントのロジックとUIを分割する「Container / Presentational構成」を紹介します！ まずはコンポーネントを以下のような構成で作成します。<pre><code>BlogItemTemplate
 ├── index.tsx // container層 (ロジック担当)
 ├── Presenter.tsx // Presentational層 (UI担当)
 └── styles.module.scss // css</code></pre>1つのコンポーネントを「Container層」と「Presentational層」に分割します。 (styleの記載もついでに分割しています。) このContainer層は「コンポーネントのロジック」の記述を担当し、Presentational層は「コンポーネントのUI」を担当します。 イメージは以下の図のような感じですね。 <img src="https://images.microcms-assets.io/assets/07ff07e8d1244dd1984512c2a5431805/12af829c42f3406383b1a3396cedef04/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-04-04%2015.31.28.png" alt=""> コンポーネント自体はContainerでPresenterをラップする構造です。 Containerでstateやロジックを定義、またはRedux, ContextAPI, CustomHooksなどの外部モジュールから呼び出します。 そしてContainerからPresenterへPropsで渡し、Presenterは「UIを描画する」のみに専念させます。 これによって1つコンポーネントに対し、「ロジック」と「UI」のモジュールに責務を分割することができます。 具体的なコードは以下の通りです。 ■ Container<pre><code>/**
 * pages/BlogItemTemplate
 * ContainerComponent
 * @package Component
 */
import React from 'react'
import { useRouter } from 'next/router'
/* components */
import { Presenter } from './Presenter'
/* constants */
import { NOCHITOKU_URL, BASE_TITLE } from '@/constants/config'
/* types */
import { MetaHeadType } from '@/types/metaHead'
import { BlogItemType, TableOfContentType } from '@/types/blog'
import { ImageType } from '@/types/image'

/**
 * container
 * @param props Props
 * @returns
 */
export const BlogItemTemplate: React.FC&lt;Props&gt; = (props: Props) =&gt; {
 const { blogItem, highlightedBody, tableOfContents, draftKey } = props

 const propsImage: ImageType = {
 url: blogItem?.image?.url ? blogItem.image.url : '/no_image.png',
 width: blogItem?.image?.width ? blogItem.image.width : 750,
 height: blogItem?.image?.height ? blogItem.image.height : 422,
 }

 const router = useRouter()
 let shareUrl = NOCHITOKU_URL
 if (router?.asPath &amp;&amp; typeof router.asPath === 'string') {
 shareUrl = NOCHITOKU_URL + router.asPath
 }

 const metaData: MetaHeadType = {
 title: `${blogItem.title} | ${BASE_TITLE}`,
 description: blogItem.description,
 keyword: 'エンジニア,IT,プログラミング,フロントエンド,AWS',
 image: blogItem.image.url,
 url: NOCHITOKU_URL + router.asPath,
 }

 // Presenterをラップ (propsでstateとロジックを渡す)
 return (
 &lt;Presenter
 metaData={metaData}
 blogItem={blogItem}
 image={propsImage}
 highlightedBody={highlightedBody}
 tableOfContents={tableOfContents}
 shareUrl={shareUrl}
 draftKey={draftKey}
 /&gt;
 )
}</code></pre> ■Presenter<pre><code>/**
 * pages/BlogItemTemplate
 * PresentationalComponent
 * @package Component
 */
import React from 'react'
import Link from 'next/link'
import Image from 'next/image'
/* components */
import { BasePostPageLayout } from '@/components/layouts/BasePostPageLayout'
import { SnsShareBar } from '@/components/common/molcules/SnsShareBar'
import { SnsShareArea } from '@/components/common/molcules/SnsShareArea'
import { TitleArea } from './organisms/TitleArea'
import { TableOfContents } from './organisms/TableOfContents'
import { HighlightBody } from '@/components/common/molcules/HighlightBody'
/* types */
import { MetaHeadType } from '@/types/metaHead'
import { BlogItemType, TableOfContentType } from '@/types/blog'
import { ImageType } from '@/types/image'
/* styles */
import styles from './styles.module.scss'

/**
 * props
 */
type Props = {
 metaData: MetaHeadType
 blogItem: BlogItemType
 image: ImageType
 highlightedBody: string
 tableOfContents: TableOfContentType[]
 shareUrl: string
 draftKey?: string
}

/**
 * presenter
 * @param props
 * @returns
 */
export const Presenter: React.FC&lt;Props&gt; = (props: Props) =&gt; {
 const {
 metaData,
 blogItem,
 image,
 highlightedBody,
 tableOfContents,
 shareUrl,
 draftKey,
 } = props

 // Propsで受け取ったものをUIとともに描画するのみ
 return (
 &lt;BasePostPageLayout metaData={metaData} breadName={blogItem.title}&gt;
 &lt;section className={styles.container}&gt;
 &lt;div className={styles.image}&gt;
 &lt;Image
 src={image.url}
 alt="Picture"
 width={image.width * 2}
 height={image.height * 2}
 /&gt;
 &lt;/div&gt;

 &lt;main className={styles.main}&gt;
 &lt;div className={styles.leftBar}&gt;
 {/* SNSシェアボタン */}
 &lt;SnsShareBar title={blogItem.title} shareUrl={shareUrl} /&gt;
 &lt;/div&gt;

 &lt;div className={styles.rightBar}&gt;
 {/* ブログタイトルエリア */}
 &lt;TitleArea blogItem={blogItem} /&gt;

 {/* 目次 */}
 &lt;TableOfContents tableOfContents={tableOfContents} /&gt;

 {/* 記事本文 */}
 &lt;HighlightBody highlightedBody={highlightedBody} /&gt;

 {/* SNSシェアボタン */}
 &lt;div className={styles.shareArea}&gt;
 &lt;SnsShareArea title={blogItem.title} shareUrl={shareUrl} /&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/main&gt;
 &lt;/section&gt;
 &lt;/BasePostPageLayout&gt;
 )
}</code></pre> <h2 id="h3ab24f6f50">メリット</h2>Container/Presentational構成は以下のようなメリットがあります。<ul><li>ロジックとUIを分離し、可読性が良くなる</li><li>Storybook (StoryShot)はPresenterのみを対象にすれば良くなる</li><li>ロジックのテストはContainerのみ対象にすれば良くなる</li></ul>責務を分割することで「保守性が良くなる」ことがメリットですね。 アプリケーションの機能が追加される度に構造が複雑化してしまうので、保守性が悪いと第三者がみた時に解読に時間がかかります。 どこに何があるかパッと見て分かりやすければ、それだけ工数削減にもなりますね。 責務を分割することで、開発者が戸惑うことなく保守できるようになります。 <h2 id="h7e4a670898">デメリット</h2>保守性が良くなる反面、「コードの記載量が肥大化」することがデメリットではあります。 コード量が多くなることで、JavaScriptのバンドルサイズが大きくなります。 Webブラウザだとそこまで影響はないかもしれませんが、ReactNativeを用いたネイティブアプリだとスマホの容量を無駄に取ってしまうので、ネイティブアプリ開発ではあまり多様しないほうがいいかもしれません。 しかしロジックの記載が多いコンポーネントなど、部分的に採用することで保守性は上がりますので、設計段階で検討して取り入れていくのがベストだと考えています。 <h1 id="h3bcda3e6b0">最後に</h1>いかがでしたでしょうか？ 今回はReactのコンポーネント設計のContainer / Presentational構成について紹介いたしました！ モダンフロントの設計方針は現状これといったものはなく、現場によって独自に発展しているところばかりです。 今回の設計方針も絶対的なものではないですが、知見に入れておくことで設計を考慮する際に役に立てると思います。 今後もReact, Next.jsの設計手法について発信してく予定ですので、良ければご覧いただけると嬉しいです！

React・Next.jsのコンポーネント設計手法の1つ「Contaienr/Presentational構成」について紹介いたします！ コンポーネントを「ロジック」と「UI」に責務を分割することで保守性の向上が期待できます！

 Container / Presentational構成【Reactのコンポーネント設計】

フリーランスエンジニアの雄貴です。 私のプロフィールについてお話ししようと思いますが、 この記事では「エンジニアとしての私」についてお話ししようと思います。 <h1 id="h1e07488449">何やってる人か？</h1>フリーランスのWebエンジニアとして、お客様のシステム開発を業務委託としてご協力させていただいております。 エンジニア経歴は4年で、主にReactやNext.jsを扱ったSPAシステム開発をメインに活動しております。 他にもReactNativeを扱ったネイティブアプリ開発や、Node.jsを用いたバックエンドAPIの開発業務などの経験もあり、 フロントエンド、バックエンド、ネイティブアプリ開発に精通しております。 また昨今AWSのLambdaを用いたサーバレス構成の案件を多く見られるようになってきたので、個人開発としてAWSをキャッチアップし、業務に活かすよう尽力しております。 現場では開発業務だけでなく、チーム開発の効率化のため、メンバーのフォローや教育なども行ってきました。 フロントエンドのリーダーとして仕様検討、タスク進捗管理、チームメイキングなどマネジメント経験もあります。 技術力とチーム開発スキルを用いてお客様の利益向上に勤めております。<h1 id="hd520c521dd">スキル</h1><h2 id="h5dc0967264">フロントエンド</h2>JavaScript TypeScript React Next.js Vue.js Nuxt.js その他フロントエンドスキル：jest Cypress Storybook 状態管理：Rudux ContextAPI (ReduxLikeな状態管理を得意とする) コンポーネント設計：AtomicDesign Container/Presentaitional構成 ※ SPA(CSR), SSR, SSG構成のシステム開発経験あり ※ Swagger(Open API)を用いたスキーマ駆動開発の経験あり <h2 id="ha2cc149486">バックエンド</h2>Node.js Express PHP Laravel CakePHP Ruby RubyOnRails 仮想環境：Docker vagrant DBMS：MySQL ※ Swagger(Open API)を用いたスキーマ駆動開発の経験あり <h2 id="hcf3f0ac45b">ネイティブアプリ</h2>ReactNative Expo 状態管理：Rudux ContextAPI (ReduxLikeな状態管理を得意とする) コンポーネント設計：AtomicDesign Container/Presentaitional構成 <h2 id="h1a558df3a4">クラウド</h2>AWS (Amplify) <h2 id="h979887ec0a">mBaas</h2>Firebase (FirebaseAuthentication Firestore CloudStorage CloudFunctions) <h1 id="hee2905b975">主な参画案件</h1><h2 id="h6cbc33c39d">コンシューマー向けレシピアプリのMVP開発</h2>■スキル TypeScript ReactNative Expo Firebase (FirebaseAuthentication Firestore CloudStorage CloudFunctions) ■メンバー 「計3名 (エンジニアとして参画)」PM 1名, エンジニア 2名 ■内容 新規サービスのMVP開発に参画 (市場検証向けのプロトタイプ開発) 要件定義、基本設計から開発、テスト、デプロイ、運用・保守まで担当 自分がリーダーとなって設計開発を行う またMVP検証後の実運用サービス開発を目処に入れた、設計を考慮し実施した。 <h2 id="hf8b1db8fea">建築業界向けSaaSシステムの新規開発業務</h2>■スキル TypeScript Nuxt.js Ruby RubyOnRails MySQL Docker Swagger(OpenAPI) AWS(Amplify) ■メンバー 「計11名 (フロントエンドエンジニアのリーダーとして参画)」PM 1名, フロントエンドエンジニア 4名 バックエンドエンジニア 3名 ネイティブアプリエンジニア 2名 デザイナー 1名 ■内容 新規サービスの開発案件に参画 要件定義、基本設計から開発、テスト、デプロイ、運用・保守まで担当 チームリーダーとしてフロントチーム内の開発効率向上、さらにバックエンドチーム、PMとのコミュニケーションコストの削減に勤める UI/UXを考慮したWFを作成し、提案(デザイナーと共同作業) WF、機能をもとにストア設計、コンポーネント設計を実施 OpenAPIを用いたスキーマ駆動開発をバックエンドと共同で実施 <h2 id="hbbb82c9c78">営業支援サービスの新規構築</h2>■スキル TypeScript Next.js Ruby RubyOnRails MySQL Docker CircleCI Swagger(OpenAPI) AWS(Amplify) ■メンバー 「計9名 (フロントエンドエンジニアとして参画)」PM 2名, フロントエンドエンジニア 2名 バックエンドエンジニア 2名 ネイティブアプリエンジニア 2名 デザイナー 1名 ■内容 Next.js+TypeScriptにおけるSSR構成システムの新規開発、テスト、リリース 基本設計から開発、テスト、デプロイ、運用・保守まで担当 トークンを用いた認証周りの開発 OpenAPIを用いたスキーマ駆動開発をバックエンドと共同で実施 <h1 id="h3bcda3e6b0">最後に</h1>業務委託のエンジニアをご希望でありましたら、ご連絡いただけると幸いです。 Email: yuki.onishi1129@gmail.com

フリーランスのWebエンジニアとして、お客様のシステム開発を業務委託としてご協力させていただいております。主にReactやNext.jsを扱ったSPAシステム開発をメインに活動しております。他にもReactNativeを扱ったネイティブアプリ開発や、Node.jsを用いたバックエンドAPIの開発業務などの経験もありフロントエンド、バックエンド、ネイティブアプリ開発に精通しております。

NOCHITOKU

ホーム

このブログについて

プロフィール

「Next.js」の記事一覧