こんにちは！雄貴です！ Jestを用いた非同期処理のテストコード実装方法を紹介いたします！ また今回は私のやり方ですので、もっといいやり方があるよ！って方はご連絡いただけると嬉しいです😁 <h1 id="hf48e268c7b">テストの方針</h1> 非同期処理があるということはDBやFirebase, 外部APIなどの、外部サービスとの接続処理がある場合が多いと思います。 今回のテストはそれを対象にした関数のテストについて考えていこうと思います！ やり方としては2つあるかなと考えています。 <h2 id="h7caca1182b">1.テスト環境を用意して、テスト実施時にはそこに接続する方法</h2> DBやFirestoreなどに限った話ではありますが、 テスト実施用のDBやFirebaseのプロジェクトを作成して、テスト時にそこに接続してデータのCRUD処理などを検証する方法です。 jestの「beforeAll」でテストデータを登録し、「afterAll」でデータを削除すればテスト実施のたびに使わないデータが増えていくことはないので、実現可能ではあると思います。 ※参考: <a href="https://jestjs.io/ja/docs/setup-teardown" target="_blank" rel="noopener noreferrer">セットアップと破棄</a> しかし以下2点の懸念点があります。 <ol><li>CIで実施する場合は失敗する</li><li>テストが失敗した場合、コード起因か外部サービスの不具合が原因なのか判別しにくい</li></ol> 1に関してはテスト環境へ接続する環境変数を設定している場合だとCIのワークフロー実行時に認識されずエラーになります。 だからと言って環境変数ではなくコードに直書きだとあまりセキュリティ的によろしくないので、微妙ではありますね。。 また2に関しては失敗した時の原因が外部サービス起因も含まれる可能性があるので、コード自体の担保には向いていないかなと考えています。 Unitテストなのでコード自体の品質担保を目的としたいので、この手法は微妙かなと思っています。。 <h2 id="h08187ba796">2.関数自体をmock化する</h2> ではどうするか？ですが、Unitテストとして、「関数自体の品質の担保」に着目しようと思います。 コードのロジックのみを担保したいので、外部サービスなどの外部要因は全てスタブにしていきたいですね。。 なのでDBや外部APIなど接続してデータ操作する操作は、それのみ実行する関数へと細分化したモジュールにして、その関数をmock化させるのがいいかなと思います。 要はまるっとテスト対象の関数をmock化させる方針です。 その関数には外部サービスからデータを取得したりなどのCRUDのみに絞って、そのデータを加工するなどは別のモジュールで実行するように実装すれば、テストも実装しやすいです。 文章で説明しても難しいと思うので、実際にテストコードを見ていきましょう！ <h1 id="hf031c5e696">実装方法</h1> 早速実装していきましょう！ テスト対象のサンプルコードはこちらです。 <h2 id="h1245c0eb5b">テスト対象のコード (sampleApi.ts)</h2><pre><code>/* configs */
import globalAxios from '@/config/globalAxios'
/* types */
import { SampleData } from '@/types/sample'

const BASE_URL = 'http://localhost:4000'

export const getSampleData = async (
 targetId: number
): Promise&lt;SampleData | undefined&gt; =&gt; {

 try {

 // 非同期処理を実施
 const res = await globalAxios.get(BASE_URL + `/${targetId}`)
 if (!res) return

 return {
 id: res.data.id,
 title: res.data.title,
 createdAt: res.data.createdAt,
 updatedAt: res.data.updatedAt,
 deleteFlg: res.data.deleteFlg,
 }

 } catch (error) {

 throw new Error(`API ERROR: getSampleData`)

 }
}


</code></pre> 「globalAxios」で外部のAPIに接続し、データを取得する処理になります。 APIからデータを取得して、それを返すのみの関数ですね。 この粒度まで細分化させれば、丸ごとmock化しても関数の引数と戻り値の型さえ検証できれば、品質としては充分担保できると思います。 ※この辺り賛否両論あると思うので、もしこの方がいいよ！ってのがありましたら、ご連絡ください🙇‍♂️ また、try~catchで例外処理も実装しており、テストケースは以下の3点になります。 <ul><li>【正常系】データを取得できる場合</li><li>【異常系】データが取得できない場合 (resの値がundefined)</li><li>【異常系】例外処理が発生</li></ul> <h2 id="hb83c013609">テストコード実装 (sampleApi.spec.ts)</h2> それではテストコードを実装していきましょう！ テストケースは3点あるので、それぞれ実装していきます。 <h3 id="h09e08947ca">【正常系】データを取得できる場合</h3> こちらがテストコードです。 正常系の部分のみ抜粋しています。 <pre><code>/* apis */
import { getSampleData } from './sampleApi'
/* types */
import { SampleData } from '@/types/sample'

describe('【APIテスト】sampleApi test', () =&gt; {
 
 // ① 変数の定義
 let targetId: number // getSampleDataの引数
 let sampleState: SampleData // getSampleDataの戻り値

 describe('【関数テスト】 getSampleData', () =&gt; {
 
 // ② 変数を初期化
 // beforeEachにて「test」が実行される前に記載の処理を実行する
 beforeEach(() =&gt; {
 targetId = 1
 sampleState = {
 id: 0,
 title: 'テスト',
 createdAt: '2020-01-01 00:00:00',
 updatedAt: '2020-01-01 00:00:00',
 deleteFlg: false,
 }
 })

 test('【正常系】処理が正常に動作する。', async () =&gt; {

 // ③ 関数をmock化
 const apiMock = jest.fn(getSampleData)

 // ④ mock関数の戻り値を設定する
 const apiMockFunc = apiMock.mockReturnValue(Promise.resolve(sampleState))

 // ⑤ テスト対象を実行し、テスト結果を検証する
 expect(await apiMockFunc(targetId)).toEqual(sampleState)

 // ⑥ mock関数に指定した引数を検証
 expect(apiMockFunc.mock.calls[0][0]).toBe(1)

 })
 })
})</code></pre> まず①と②で、テスト対象の関数である「getSampleData」の引数と戻り値に設定する変数を定義、初期化します。 そして、「test」関数内で、③ テスト対象の関数をmock化させます。 <pre><code>const apiMock = jest.fn(getSampleData)</code></pre> 「jest.fn()」の第一引数にmock化させたい関数を設定することで、ダミー関数として定義することができます。 ただこの状態だとmockとして実行できないので、④の「mockReturnValue」でmock関数の戻り値を設定します。 <pre><code> const apiMockFunc = apiMock.mockReturnValue(Promise.resolve(sampleState))</code></pre> 今回テスト対象の関数の戻り値はPromiseなので、「Promise.resolve」と指定することで正常に動作した際の戻り値を設定することができます。 そして⑤にて「expect」関数の中でテスト対象のmockを実行し、「toEqual」で値を検証します。 ※今回検証する値はオブジェクトなので、toEqualを採用。toBeだとエラーになるので注意 参考: <a href="https://jestjs.io/ja/docs/using-matchers" target="_blank" rel="noopener noreferrer">Mactherを使用する</a> ここでは実物の「getSampleData」が実行されるのではなく、mock化した関数が実行されるのみになります。 また⑥にてmock関数に指定した引数の値を確認することができます。 <pre><code>expect(apiMockFunc.mock.calls[0][0]).toBe(1)</code></pre> <h3 id="h93884fa6c6">【異常系】データが取得できない場合 (戻り値がundefined)</h3> 今回はテスト対象コードの以下の部分の確認を実施するテストを書いています。 <pre><code>// sampleApi.ts (テスト対象コード) 

const res = await globalAxios.get(BASE_URL + `/${targetId}`)

// この部分の確認！！ (非同期処理の結果がundefinedの場合)
 if (!res) return</code></pre> テストコードはこちら <pre><code>test('【異常系】処理が失敗する。apiの戻り値がundefinedの場合', async () =&gt; {
 targetId = 0

 // 関数をmock化
 const apiMock = jest.fn(getSampleData)
 // ① mock関数の戻り値を設定する (undefined)
 const apiMockFunc = apiMock.mockReturnValue(Promise.resolve(undefined))


 // ② mock関数の戻り値を検証
 expect(await apiMockFunc(targetId)).toEqual(undefined)

 // mock関数に指定した引数を検証
 expect(apiMockFunc.mock.calls[0][0]).toBe(0)
 })</code></pre> ①の「mockReturnValue」でundefinedを戻り値に設定しています。 先ほど説明した場合と同じで、Promise.resolve指定するんでしたね。 そして② でmock関数を実行し値を検証しています。 これは正常系とほぼ同じ構成です。 <h3 id="hcf628ddda7">【異常系】例外処理が発生した場合</h3> テスト対象コードではtry~catchで例外を処理する構成で実装しているので、その部分もテストします。 テストコードはこちら <pre><code>test('【異常系】処理が失敗する。例外処理が発生した場合', async () =&gt; {
 targetId = -1

 // 関数をmock化
 const apiMock = jest.fn(getSampleData)

 // ① mock関数を敢えて失敗させるよう設定する
 const apiMockFunc = apiMock.mockReturnValue(Promise.reject('error'))


 // ② テスト対象の実行はtry~catchで実施
 try {
 await apiMockFunc(targetId)
 } catch (error) {

 // ③ 例外が発生するので、catchの部分で検証する
 expect(error).toMatch('error')
 }

 // mock関数に指定した引数を検証
 expect(apiMockFunc.mock.calls[0][0]).toBe(-1)
 })</code></pre> これまでと異なる点は、mock関数を明示的に例外が発生するように設定する点です。 これまでは「Promise.resolve」で非同期処理が正常に終了した際の戻り値を設定していましたが、 今回は例外処理を発生させるので、「Promise.rejects」で敢えて例外を発生させます。 ※①の実装 またmock関数の実行をそのまま実施してしまうと例外が発生しテストがエラーになってしまうので ②のようにtry~catchの中でmock関数を実行させます。 そして③ catchのスコープ内でexpect関数による検証を実施します。 ※参考: <a href="https://jestjs.io/ja/docs/asynchronous#asyncawait" target="_blank" rel="noopener noreferrer">非同期コードのテスト Async/Await</a> <h1 id="ha214098e44">まとめ</h1> 以上、Jestを用いた非同期処理のテストコード実装方法を紹介いたしました。 外部サービスからのデータを操作する処理のテストはプロダクトによって方針が変わるとは思いますが、 Unitテストの観点から考えて、コードのロジックの担保飲みに着目した手法がオーソドックスなのかなと思います。 ここではmock化しているのでテスト対象の関数の「引数」と「戻り値」の型のみの品質確認になります。 これは一見やる意味はなさそうですが、今後運用していく中で既存コードが変更された時、 以前はどのような処理が正しかったのか？をテストコードを見ることで理解できるので、 保守性は上がるし、思わぬ事故を防げるかなと思っています。 ただ実際にデータ操作するテストは手動でやるか、もしくはE2Eなど結合テストで実施していくしかないのかなと考えています。 私もその辺りの知見は少ないので、今後もキャッチアップしていこうと思います👍 今回の実装コードについてはこちらにありますので、よければご覧ください😁 <a href="https://github.com/YukiOnishi1129/react-test-project" target="_blank" rel="noopener noreferrer">https://github.com/YukiOnishi1129/react-test-project</a>

Jestを用いた非同期処理のテストコード実装！！DBや外部API接続を含んだロジックのテストコードの実装方法を紹介しています！

Jestを用いた非同期処理のテストコード実装！！

こんにちは！雄貴です！ 今回はReactNative (Expo) ✖︎ TypeScript におけるテスト環境構築の手法をまとめました！ <h1 id="hed900658dc">環境</h1>以下のスキルを用いた環境にテスト環境を構築します。 <ul><li>React Natie</li><li>Expo</li><li>TypeScript</li></ul> <h1 id="h046876a126">手順</h1><a href="https://www.npmjs.com/package/@testing-library/react-native" target="_blank" rel="noopener noreferrer">公式</a>を元に構築します。 テストライブラリには「@testing-rabrary/react-native」を採用しました！ <h2 id="h87735c435c">ライブラリinstall</h2>以下のコマンドで必要なライブラリをinstallします。 <pre><code>yarn add -D expo-jest @types/jest @testing-library/react-native @testing-library/jest-native</code></pre> またpackage.jsonに以下の記述を追加<pre><code>{
&nbsp;・・・ &nbsp;
 "jest": {
&nbsp; &nbsp; "preset": "jest-expo",
&nbsp; &nbsp; "transformIgnorePatterns": [],
&nbsp; &nbsp; "setupFilesAfterEnv": [
&nbsp; &nbsp; &nbsp; &nbsp; "@testing-library/jest-native/extend-expect"
&nbsp; &nbsp; &nbsp;],
 "testMatch": [
 　　 "**/*.test.ts",
 "**/*.test.tsx",
 "**/*.spec.ts",
 "**/*.spec.tsx"
 　]
 },
 ・・・
}</code></pre> そして「jest.config.js」を新規作成し以下のコードを記載します。 <pre><code>module.exports = {
&nbsp; &nbsp; preset: "react-native",
&nbsp; &nbsp; moduleFileExtensions: ["ts", "tsx", "js", "jsx", "json", "node"],
};</code></pre> <h2 id="h075c5597b1">サンプルコードで動作確認！</h2>動作確認のためにサンプルコードを作成します！ <h3 id="hbcfc41be5b">sample.tsx</h3>テスト対象のコードです。 こちらは公式にあるものをTypeScriptで書き換えました。 <pre><code>/**
 * test sample
 */
import React from "react";
import { View, TouchableOpacity, Text, ScrollView, TextInput } from "react-native";

type Props = {
 questions: string[];
 onSubmit: (data: {}) =&gt; void; 
};

export const Sample: React.FC&lt;Props&gt; = ({ questions, onSubmit }: Props) =&gt; {
 const [data, setData] = React.useState({});

 return (
 &lt;ScrollView&gt;
 {questions.map((q, index) =&gt; {
 return (
 &lt;View key={q}&gt;
 &lt;Text&gt;{q}&lt;/Text&gt;
 &lt;TextInput
 // accessibilityLabel: テストコード側でgetAllByA11yLabelによって値を呼び出す
 accessibilityLabel="answer input"
 accessibilityHint="input"
 onChangeText={(text) =&gt; {
 setData((state) =&gt; ({
 ...state,
 [index + 1]: { q, a: text },
 }));
 }}
 /&gt;
 &lt;/View&gt;
 );
 })}
 &lt;TouchableOpacity onPress={() =&gt; onSubmit(data)}&gt;
 {/* テストコード側のgetByText("Submit"))で呼び出す */}
 &lt;Text&gt;Submit&lt;/Text&gt;
 &lt;/TouchableOpacity&gt;
 &lt;/ScrollView&gt;
 );
};


</code></pre><h3 id="h0255cec615">sample.spex.tsx</h3>「sample.tsx」におけるテストコードです。 こちらも公式にあるものをTypeScriptで書き換えました。<pre><code>/**
 * サンプルテストコード (ファイル名はspec.ts)
 * 「***.test.tsx」または「***.spec.tsx」の命名ででコンポーネントのテストが実施できる
 * 「***.test.ts」または「***.spec.ts」はコンポーネントをrenderしないテスト専用
 */
import React from "react"; // コンポーネントのテストをする際は、importしないとType error発生
import { render, fireEvent } from "@testing-library/react-native";
/* components */
import { Sample } from "./sample"; // テスト対象コード

describe("sample test", () =&gt; {
 it("test no1", () =&gt; {
 const allQuestions = ["q1", "q2"]; // stateのpropsを定義
 const mockFn = jest.fn(); // functionのpropsはmockを使用

 // テスト対象のコンポーネントをrender
 const { getAllByA11yLabel, getByText } = render(
 &lt;Sample questions={allQuestions} onSubmit={mockFn} /&gt;,
 );

 // 対象コードの「 accessibilityLabel="answer input"」に表示されたinput dataを取得する
 const answerInputs = getAllByA11yLabel("answer input");

 fireEvent.changeText(answerInputs[0], "a1");
 fireEvent.changeText(answerInputs[1], "a2");
 // 対象コードのTouchableOpacityを呼び出して、fireEventでクリック処理を実施
 fireEvent.press(getByText("Submit"));

 expect(mockFn).toBeCalledWith({
 "1": { q: "q1", a: "a1" },
 "2": { q: "q2", a: "a2" },
 });
 });
});


</code></pre><h3 id="h3c7222fefe">動作確認</h3>以下のコマンドでテストを実行できます。<pre><code>yarn jest</code></pre> するとターミナルに以下のような記述が表示されます。<pre><code>descktop % yarn jest
yarn run v1.22.4
$ /Users/~/sample-react-native/node_modules/.bin/jest
&nbsp;PASS&nbsp; src/components/sample.spec.tsx 

Test Suites: 1 passed, 1 total
Tests:&nbsp; &nbsp; &nbsp; &nbsp;1 passed, 1 total
Snapshots:&nbsp; &nbsp;0 total
Time:&nbsp; &nbsp; &nbsp; &nbsp;5.655s, estimated 82s
Ran all test suites.
✨&nbsp; Done in 19.39s.</code></pre> 上記のような表示が出れば成功です！ <h1 id="h3bcda3e6b0">最後に</h1>React Native (Expo) TypeScript環境におけるテスト環境構築方法を紹介いたしました！ Webに比べると構築はかなり楽でしたね！ ここからmockテストなど実施したいテストに合わせて追加でライブラリを組み込んでいく必要があります。 ぜひReactNativeで様々なテストを試してみてください！

ReactNative (Expo) ✖︎ TypeScript におけるテスト環境構築の手法をまとめました！

React Native (Expo) ✖︎ TypeScriptで テスト環境構築！！

こんにちは！雄貴です！ 今回はFirebaseのCloudFunctionsの構築の際に、詰まりそうな部分とその解決方法をまとめました！ <h1 id="hb4573aa564">CloudFunctionsとは？</h1>Firebase環境でバックエンド処理を自動実行できるものです。 具体的には以下の処理が可能ですね。<ul><li>バッチ処理</li><li>外部API呼び出し など</li></ul>例えば「リマインド送信」や「メール一斉送信」なんかもCloudFunctionsでできちゃいます！ これらはバックエンド言語(Node.jsなど)の記述で構築できるので、バックエンド経験者ならすんなり習得できるようになっています！ CloudFunctionsで可能な処理は<a href="https://firebase.google.com/docs/functions/use-cases?hl=ja" target="_blank" rel="noopener noreferrer">こちら</a>で説明されています。<h1 id="h868447cfa4">構築手順</h1>CloudFunctions環境の構築方法は以下のようなイメージです。 <img src="https://images.microcms-assets.io/assets/07ff07e8d1244dd1984512c2a5431805/7a7bed8791fc4ea29b92c779841aeda7/%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-25%2014.57.00.png" alt=""> ローカル上でCloudFunctionsの処理をコーディングして、その後Firebaseへデプロイする流れですね。 構築の手順は以下の流れになっています。<ol><li>Firebase上でプロジェクトを作成</li><li>Node.jsとFirebaseCLIを設定</li><li>「firebase login」でブラウザからFirebaseにログイン</li><li>Firebase用のリポジトリをローカル環境に作成し、そこに移動</li><li>「firebase init firestore」コマンドを実行 (firebaseアクセス環境をローカルに構築)</li><li>「firebase init functions」コマンドを実行 (CloudFunctions実装ディレクトリを構築)</li><li>CloudFunctionsの処理を実装</li><li>Firebase環境に実装したCloudFunctionsをデプロイ</li></ol>上記内容は<a href="https://firebase.google.com/docs/functions/get-started?hl=ja" target="_blank" rel="noopener noreferrer">公式</a>に記載されていますので、合わせてご覧ください。 またCloudFunctionsをTypeScriprtで構築する方法は<a href="https://firebase.google.com/docs/functions/typescript" target="_blank" rel="noopener noreferrer">こちら</a>にまとめられていますのでご覧ください。<h1 id="h20e2985d78">エラー解決方法</h1>以下のように、Next.jsやReactNativeのようなフロントリポジトリの中にFirebaseディレクトリを構築する場合にて、エラーになりやすい箇所を説明します。<pre><code>&nbsp;nextjsapp // フロントエンドリポジトリ
&nbsp; ├─ firebase&nbsp;
&nbsp; │&nbsp; &nbsp; ├─ functions // CloudFunctions実装部分
&nbsp; │ &nbsp; &nbsp;│&nbsp; &nbsp; ├─ node_modules
&nbsp; │ &nbsp; &nbsp;│&nbsp; &nbsp; ├─ src
&nbsp; │ &nbsp; &nbsp;│&nbsp; &nbsp; │&nbsp; &nbsp;└── index.ts // ここにCloudFunctionsの処理を記述
&nbsp; │ &nbsp; &nbsp;│&nbsp;&nbsp; ├── package.json
 &nbsp;│ &nbsp; &nbsp;│&nbsp;&nbsp; ├── eslintrc.js
 &nbsp;│ &nbsp; &nbsp;│&nbsp;&nbsp; └── tsconfig.json
 &nbsp;│ &nbsp; &nbsp;│&nbsp; &nbsp;
&nbsp; │&nbsp; &nbsp; ├─ .firebaserc
&nbsp; │&nbsp; &nbsp; ├─ firebase.json
&nbsp; │&nbsp; &nbsp; ├─ firestore.indexes.json
&nbsp; │&nbsp; &nbsp; └─ firestore.rules
&nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;　├── src // フロント実装部分
&nbsp;　├── node_modules&nbsp; &nbsp;
&nbsp;　├── eslintrc.js
&nbsp;　├── package.json&nbsp;
&nbsp;　└── tsconfig.json</code></pre> <h2 id="h024f41e39a">firebaseコマンドでエラー</h2>ローカル端末にpathの設定をすることで解決しました。 <a href="https://qiita.com/k2021/items/8b7389293f7896f8d4b1" target="_blank" rel="noopener noreferrer">firebase loginでfirebase: command not found と怒られる</a><h2 id="h51b61d2ad3">yarnコマンドでエラー</h2>firebase &gt; functions直下でyarnコマンドを実行するとエラーになることがあります。 原因はfunctions直下のpackage.jsonの"engines"の箇所のnodeのバージョンがグローバル環境と異なっている為です。 対策として、package.jsonのnodeのバージョンを合わせるか、以下の記事のようにディレクトリごとにnodeのバージョンを指定するかで解決できます。 <a href="https://qiita.com/tonkotsuboy_com/items/5322d226b6783d25b5df#%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88a%E3%81%A7%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8Bnodejs%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E8%A8%AD%E5%AE%9A" target="_blank" rel="noopener noreferrer">Node.jsのバージョンを自動で切り替えられるnodenvが超便利</a><h2 id="hb993162445">デプロイ時に親階層のnode_modulesが参照されてしまう</h2>デプロイする際に親階層(フロントリポジトリ側)のnode_modulesが参照されてしまいエラーになってしまいます。 こちらの記事に解決法が記載されています。 <a href="https://blog.yuhiisk.com/archive/2019/05/09/firebase-deploy-reference-parent-modules.html" target="_blank" rel="noopener noreferrer">Cloud Functions + TypeScriptでデプロイ時に親階層のnode_modulesが参照されてしまう</a> これはfunctions直下のtsconfig.jsonのcompolerOptionsに「typeRoots」プロパティを追加し、functionsで参照する@typesの箇所を明示的に記載すれば解決します。<pre><code>{
 "compilerOptions": {
 ・・・
 "typeRoots": [
 "./functions/node_modules/@types" 
 ]
 },
 ・・・
}</code></pre><h2 id="hb57a90920e">デプロイ時に@types/nodeのコンフリクトが起こる</h2><a href="https://github.com/firebase/firebase-admin-node/issues/1121" target="_blank" rel="noopener noreferrer">こちら</a>の記事のように、@type/nodeでconflictが発生する場合があります。 原因として「firebase-admin」がv9.4以上の場合に発生するようです。 <a href="https://github.com/firebase/firebase-admin-node/issues/1121#issuecomment-754840644" target="_blank" rel="noopener noreferrer">参考</a> issueではv9.3より発生しないとありますので、バージョンを落として使用しましょう。 (私はv9.0まで落として無事解決しました。)<h1 id="h3bcda3e6b0">最後に</h1>以上、Cloud Functions構築時のエラー解決方法をお話しいたしました！ Firebaseは便利ですがバージョンが上がるごとに予期しないエラーが発生する場合があるので注意ですね。。 エラーさえ解決できればとても便利なツールなので、ぜひ活用してみてください！

Cloud Functions構築時のエラー解決方法。TypeScriptにてFirebase Cloud Functionsの構築

Cloud Functions構築時のエラー解決方法

こんにちは！フリーランスエンジニアの雄貴です！ 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のコンポーネント設計】

こんにちは、フリーランスエンジニアの雄貴です！ この記事では、このブログのコンセプトや扱う内容についてお話ししようと思います！ また私のプロフィールについてはこちらにまとめています。 エンジニアとしての経験やスキルをまとめていますので、ぜひご覧ください！ <a href="https://www.nochitoku-it.com/profile" target="_blank" rel="noopener noreferrer">プロフィール | NOCHITOKU</a><h1 id="h0eaa11ba50">ブログコンセプト</h1>コンセプトとしては以下をテーマにしています。 私の技術ノウハウを発信し、全てのエンジニアの手助けをする 私自身、日頃からITスキルのキャッチアップを実施しているのですが、未経験スキルだと慣れていないため躓くことが多くあります。 そんな中私を助けてくれたのが、QiitaやZennなどに投稿されている技術記事でした。 エンジニアの皆さんの無償のアウトプットがあってこその今があると捉えています。 そこで私も自分自身の技術ノウハウを持って、他のエンジニアの方の手助けができればと思いブログを開設いたしました。<h1 id="h919594522f">記事のテーマ</h1>具体的には以下のテーマで発信していきます。 <ul><li>実践的なITスキルのノウハウ</li><li>チーム開発スキル</li><li>便利なライブラリや最新技術の情報</li></ul> <h2 id="h74c5906a42">実践的なITスキルのノウハウ</h2>私が業務を通して身につけた「設計方法」や「プログラミングスキル」を発信していきます。 私自身がReact,Next.jsを用いたSPAの開発をメインとしているので、「モダンフロント(JavaScriptフレームワーク)」の内容が多い傾向になります。 また、「AWSサーバーレス(lambda)」や「Firebase」、「Node.jsを用いたバックエンド」、「ReactNativeを用いたネイティブアプリ開発」など、フロントエンド以外の業務も実施していますので、その記事も記載していく予定です。 <h2 id="h7c723a0376">チーム開発スキル</h2>ITエンジニアはITスキルだけでなく、チーム開発スキルも重要になります。 具体的には「効率的な開発サイクル」「タスク管理方法」「チームメイキングの手法」など、実践で得たノウハウを発信していく予定です。 <h2 id="h24db667848">便利なライブラリや最新技術の情報</h2>私が日頃からキャッチアップしている内容を発信していきます。 使ってみて便利だったライブラリや、最新技術を使ってみた感想などを記事にしていく予定です。 個人開発から得た知見などもどんどんアウトプットしていこうと思います！ <h1 id="h55da33bc86">ブログの技術構成</h1>ブログはNext.js, TypeScriptを用いて私が開発いたしました。 SSG(静的サイトジェネレーター)と言われる技術を用いて、快適な操作性を実現しています。 詳細な内容はZennの記事にアップしていますので、良ければご覧ください。 <a href="https://zenn.dev/yukionishi/articles/4c02ece789c34daadda5" target="_blank" rel="noopener noreferrer">JAMstackで技術ブログを作った話【Next.js ✖️ microCMS ✖️ Vercel】</a> <h1 id="h31e13366f5">ブログデザイン</h1>このブログのデザインは妻に作成いただきました。 PCブラウザのみならず、スマートフォンサイズのレスポンシブデザインも全て作成いただきました。 詳細についてはこちらの記事でまとめています。 <a style="background-color:#ffffff" href="https://zenn.dev/yukionishi/articles/4c02ece789c34daadda5" target="_blank" rel="noopener noreferrer">JAMstackで技術ブログを作った話【Next.js ✖️ microCMS ✖️ Vercel】</a> 妻は現在UI・UXデザイナーを目指して転職活動をしております。 採用活動など、もしご興味がありましたら、こちらのアカウントまでご連絡いただければ幸いです。 <a style="color:inherit" href="https://twitter.com/shio_design" target="_blank" rel="noopener noreferrer">@shio_design</a> <h1 id="h3bcda3e6b0">最後に</h1>以上、ブログコンセプトについてお話ししました！ 私自身別のブログをやっているのですが、こちらは「ITエンジニアのキャリアやビジネス展開」に特化させていく予定ですので、「具体的なITスキルのノウハウ」は「NOCHITOKU」ブログに担当させることにしました。 <a href="https://read-engineer.com/" target="_blank" rel="noopener noreferrer">ブログ | Readするエンジニア</a> 皆様にとって「のちのち役に立つ」情報を発信していこうと思います！ どうぞ、よろしくお願いいたします！

のちのち役に立つITエンジニアの技術ブログ。React, Next.jsをはじめとしたフロントエンドのスキルや、AWS, Node.js, ReactNativeなど幅広いITスキルのノウハウを発信しています。

「NOCHITOKUブログ」について

フリーランスエンジニアの雄貴です。 私のプロフィールについてお話ししようと思いますが、 この記事では「エンジニアとしての私」についてお話ししようと思います。 <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

ホーム

このブログについて

プロフィール