こんにちは、ばんがです。 Reactのメモ化の機能について、パフォーマンス改善に使うらしいけど...程度の知識しかなかったのでざっくり調べてみました。 <h1 id="h6e5ee03ef0">メモ化とは？</h1>関数の計算結果をキャッシュしておいて、再度その関数が呼び出された時にはキャッシュを利用することで、再度関数が呼び出されないようにする、というプログラムの最適化手法のようです。 Reactの公式にはメモ化のWikipediaへのリンクが貼られていました。 https://en.wikipedia.org/wiki/Memoization より具体的には、前回の計算結果とその時の引数を保持しておいて、引数が同じであればキャッシュした結果を返す、引数が異なれば再計算される、という挙動になるようです。 <h1 id="h3d495e7e7e">Reactでのメモ化</h1>Reactでメモ化する方法をみていきます。 まず１つめ。<h2 id="h6ce25814b7">React.memo</h2>コンポーネントをラップし、コンポーネントのレンダリング結果をメモ化します。 コンポーネントに同じpropsを渡して同じレンダリング結果になる場合は、これを利用してパフォーマンスの向上が図れます。 まずは簡単なコードで動きをみてみます。 メモ化してないパターンです。 親(Parent)コンポーネントから子(Child)コンポーネントを呼び出しています。<pre><code>import React, {useState} from "react";

const Parent = () =&gt; {
 const [count, setCount] = useState(0)

 return (
 &lt;&gt;
 &lt;button onClick={() =&gt; setCount(prev =&gt; prev + 1)}&gt;カウントを増やす&lt;/button&gt;：
 {count}
 &lt;Child name='child component'/&gt;
 &lt;/&gt;
 )
}

const Child = (props) =&gt; {
 console.log("子コンポーネント")
 return (
 &lt;div&gt;{props.name}&lt;/div&gt;
 )
}</code></pre> 親コンポーネントのstateが変わるたびに、stateに依存しないChildコンポーネントが再レンダリングされているのがわかります。 確かに、Childのレンダリングが遅い場合だと結構重くなっちゃいそうですね。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/5522f3f2ab9d403f8cd60d4b69aa057c/nomemo.gif" alt=""> じゃあ次にChildをメモ化したパターンを見てみます。 React.memoでラップしました。<pre><code>const Child = React.memo((props) =&gt; {
 console.log("子コンポーネント")
 return (
 &lt;div&gt;{props.name}&lt;/div&gt;
 )
})</code></pre> この場合の挙動はこんな感じ。 コンソールに子コンポーネントが出てこないので、再レンダリングされてないのがわかります。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/b4f78a371b724e059e139e6c86266a64/memoized.gif" alt=""> <h3 id="he787685dcd">複雑なオブジェクトのpropsの場合、再レンダーされる場合もある</h3>React.memoでのpropsの比較は浅い比較なので、複雑な、例えばネストされたオブジェクトなどのpropsの場合は再レンダーされてしまう場合があります。 例えば、以下のような同じデータを持つオブジェクトを考えます。<pre><code>const objA = { a: { b: '1' } }
const objB = { a: { b: '1' } }</code></pre> これをChildコンポーネントのpropsに渡してみましょう。 countの偶奇によって渡すオブジェクトを変えるようにします。<pre><code>&lt;Child name='child component' targetObj={count % 2 === 0 ? objA : objB}/&gt;</code></pre> するとどうでしょうか？ 渡しているオブジェクトの値は同じなのにもかかわらず、Childコンポーネントは際レンダリングされています。 浅い比較では、プロパティにオブジェクトがある場合、オブジェクトの参照先を比較するので、このように参照先が異なる場合は不一致の判定をされてしまうわけです。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/5522f3f2ab9d403f8cd60d4b69aa057c/nomemo.gif" alt=""> このような複雑なオブジェクトでの等価性判定を制御する場合は、memoの第二引数に比較用の関数を指定します。 例えば、以下のようにtargetObjのネスト中のプロパティ同士を比較するように変更すると、等価判定されて再レンダリングされないようになりました。(あまり使う機会はなさそうですが...)<pre><code>const areEqual = (prevProps, nextProps) =&gt; {
 return prevProps.targetObj.a.b === nextProps.targetObj.a.b;
}

const Child = React.memo((props: { name: string; targetObj: any }) =&gt; {
 console.log("子コンポーネント")
 return (
 &lt;div&gt;{props.name}&lt;/div&gt;
 )
}, areEqual)</code></pre> <h2 id="h692f02ca4c">useMemo</h2>メモ化したい値を計算する関数を渡すことで、その計算結果をメモ化してくれるhookです。 また、第２引数に依存配列を渡すことで、その配列の要素が変化した場合に再計算を行ってくれます。 例えば、以下のようにレンダリング中に高価な計算 <code>calculation</code>を走らせなければならないとします。<pre><code>const calculation = (arg: number) =&gt; {
 console.log("高価な計算")
 return arg * 2;
}

const Parent = () =&gt; {
 const [count, setCount] = useState(0)
 const [arg, setArg] = useState(1)
 const result = calculation(arg)

 return (
 &lt;&gt;
 &lt;button onClick={() =&gt; setCount(prev =&gt; prev + 1)}&gt;カウントを増やす&lt;/button&gt;：{count}
 &lt;button onClick={() =&gt; setArg(prev =&gt; prev + 1)}&gt;引数を増やす&lt;/button&gt;：{arg}
 &lt;div&gt;
 高価な計算結果：{result}
 &lt;/div&gt;
 &lt;/&gt;
 )
}</code></pre> <code>calculation</code>はargにのみ依存し、countには依存しませんが、countを増やした場合でも再レンダリングとともに実行されてしまいます。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/cd4ccae94a944d329318d2f5ef304b37/calculation.gif" alt=""> では次にcalculationがargにのみ依存するようにメモ化してみましょう。<pre><code>const result = useMemo(() =&gt; calculation(arg), [arg])</code></pre> 引数を変化させたときだけ再計算が走り、countを増やした時は計算されないようになりました！ <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/3e3519df0dbd4aadb253d9d5b2a4ce93/usememo.gif" alt=""> これはとても簡単な例なので恩恵がわかりづらいですが、もっと重い計算を走らせる必要がある場合などはパフォーマンス改善が期待できそうです。 <h2 id="h4886ea6007">useCallback</h2>メモ化したコールバック関数を返すフックです。 これ単体ではあまり利用しないようで、React.memo等でメモ化したコンポーネントの再レンダリングを防ぐために利用するのが主な使い方のようです。<pre><code>const memoizedCallback = useCallback(() =&gt; {
 callback(a);
}, [a]);</code></pre> コンポーネントにコールバック関数を渡す場合、そのコンポーネントをReact.memoでメモ化していても再レンダリングされてしまいます。 例えば以下のような場合、Childに渡しているpropsは変わっていないはずなのに、子コンポーネント(React.memoしている )が再レンダリングされてしまいます。<pre><code>const Parent = () =&gt; {
 const [count, setCount] = useState(0)
 const callback = () =&gt; {
 console.log("コールバック！")
 }

 return (
 &lt;&gt;
 &lt;button onClick={() =&gt; setCount(prev =&gt; prev + 1)}&gt;カウントを増やす&lt;/button&gt;：{count}
 &lt;Child callback={callback} name="名前が入ります"/&gt;
 &lt;/&gt;
 )
}


const Child = React.memo((props: { callback: any, name: string}) =&gt; {
 console.log("子コンポーネント")
 return (
 &lt;div&gt;{props.name}&lt;/div&gt;
 )
})</code></pre> 親コンポーネントでcountを増やすと、親コンポーネントの再レンダリングが走ってcallback関数も再生成されます。 関数のようなオブジェクトをpropsに指定している場合、その参照先が同一かどうかで等価性の判断がされます。再生成されたcallback関数は、以前のcallback関数とは参照先が異なるので、React.memoの等価性判断で等価ではないと判断され、再レンダリングが走ってしまう、ということです。 このような場合に使うのがuseCallbackです。 以下のように先程のコールバック関数をメモ化し、メモ化したコールバックをメモ化したコンポーネントに渡すことで、子コンポーネントの再レンダリングを防ぐことができます。<pre><code>const callback = useCallback(() =&gt; {
 console.log("コールバック！")
}, [])</code></pre> <h2 id="ha214098e44">まとめ</h2>今回調べてみて、そもそもuseMemoやuseCallbackが何をするものなのか、メモ化がどうパフォーマンス改善につながるのか、がざっくり理解できました。 今後React書く際はメモ化できるとこがないか探してしまいそうですね。(何でもかんでも使えば良いもんでもないそうですが^^;) それでは。

Reactメモ化について

こんにちは、ばんがです。 今回はS3についての話です。 インフラをAWSで構築してるなら大体S3も使うと思うんですが、 S3のアクセス管理ってなにやら設定が多くてわからない...、正直よく理解しないまま使っている部分多い...という状態だったので、少し調査や挙動の確認などをしてみることにしました。 <h1 id="h1ced35c729">アクセスポリシー</h1>S3のアクセス制御は大まかに２種類のアクセスポリシーを介して行われます。 <h2 id="h8177ddd865">リソースベースのポリシー</h2>リソース(バケットやオブジェクト)にアタッチするポリシーのことで、主に ・ACL(バケットACL、オブジェクトACL) ・バケットポリシー があります。 <h3 id="hff6687a23e">ACL</h3>・AWSアカウントや、アカウントをまとめたグループ単位でアクセス制御を行う ・バケットポリシーに比べて柔軟な設定はできない ・<a href="https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/acl-overview.html#permissions" target="_blank" rel="noopener noreferrer">ACLでサポートされているアクション</a> 昔からある方法で、特殊な場合を除き現在は推奨されていないようです。 オブジェクト単位でのアクセス制御が必要な場合や、バケットの所有者がオブジェクトを所有していない場合に、そのオブジェクトのアクセス制御を行う時などに利用するようです。 <h3 id="hc245856528">バケットポリシー</h3>・S3に関する全てのアクションを制御できる ・バケット所有者が所有する全てのオブジェクトのアクセス制御が一括管理できる ・後述する<code>オブジェクト所有者</code>の設定によって、バケット所有者がどのオブジェクトを所有するかが変わってきます 上記のようにバケットポリシーの方がACLより柔軟な設定ができ管理も簡潔になることと、ほとんどのユースケースではバケットポリシーで十分対応できるため現在ACLよりもバケットポリシー(あるいはユーザーポリシー)の利用が推奨されています。 <h2 id="hd0bb2bf059">ユーザーベースのポリシー</h2>IAMユーザー・グループ・ロールなどにアタッチするアクセスポリシーのことです。 ・AWSアカウント内のユーザーごとにアクセス制御を管理したい場合はこちらを使います 最近はACLを無効にするのが一般的。 <h3 id="h4f623c0755">ポリシーの評価</h3>設定したポリシーは全て評価されるので、IAMユーザーやロールの場合、バケットポリシー、ユーザーポリシーともにアクセスが許可されていないと弾かれてしまいます。 IAMではない匿名ユーザーの場合は、バケットポリシーで評価されますが、こちらは後述するブロックパブリックアクセス設定でもアクセスが許可されている必要があります。 <h4 id="h57ceb3312b">挙動を見てみる</h4>例えば以下のようなバケットポリシーの場合、任意のユーザーが任意のリソースに対してGetObjectが実行できます。<pre><code>{
&nbsp; &nbsp; "Version": "2012-10-17",
&nbsp; &nbsp; "Statement": [
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Sid": "Statement1",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Effect": "Allow",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Principal": "*",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Action": "s3:GetObject",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Resource": "arn:aws:s3:::bucket-name/*"
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; ]
}</code></pre> 何の権限も持たない <code>iamuser</code>を利用しても、ファイルのダウンロードができました。<pre><code>aws --profile iamuser s3 cp s3://bucket-name/jojo.jpg ./
-&gt; download: s3://bucket-name/jojo.jpg to ./jojo.jpg</code></pre> ただし、匿名のユーザーの場合は失敗します。<pre><code>aws --no-sign-request s3 cp s3://bucket-name/jojo.jpg ./
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden</code></pre> これは、以下のようにブロックパブリックアクセス設定によって匿名アクセスがブロックされているからです。 この場合は、バケットポリシーで任意のプリンシパルを許可するようにしていてもアクセスはブロックされてしまいます。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/6edcf99ae51240d2b69ddd8174943935/block-public.png" alt=""> 試しにパブリックアクセスを許可するようにしてみましょう。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/cf437a34dfa843cc8d7a06d7eec71f43/allow-public.png" alt=""> 今度は匿名ユーザーでもエラーが出ずダウンロードができました。 ブロックパブリックアクセス設定については後ほど詳しく見てみましょう。<pre><code>aws --no-sign-request s3 cp s3://test-acstudy-bucket/jojo.jpg ./
download: s3://test-acstudy-bucket/jojo.jpg to ./jojo.jpg&nbsp; &nbsp;</code></pre> 試しにパブリックアクセスを許可したままバケットポリシーでprincipalを<code>iamuser</code>に指定してみます。<pre><code>{
&nbsp; &nbsp; "Version": "2012-10-17",
&nbsp; &nbsp; "Statement": [
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Sid": "Statement1",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Effect": "Allow",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Principal": {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "AWS": "iamuserのarn"
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Action": "s3:GetObject",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "Resource": "arn:aws:s3:::bucket-name/*"
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; ]
}</code></pre> <pre><code>aws --no-sign-request s3 cp s3://test-acstudy-bucket/jojo.jpg ./
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden</code></pre> 匿名ユーザーのアクセスがブロックされるようになりました。 ブロックパブリックアクセス設定でパブリックアクセスを許可していてもバケットポリシーが有効なことがわかります。 <h1 id="h61d30b6938">わかりにくい設定</h1>S3バケットのアクセス管理にはいろんな設定があるので正直わかりにくいし、あまり理解せずに使っていました...。 特に以下の項目がわかりにくかったので調べてみました。 <h3 id="h805a0ec351">オブジェクトの所有者</h3><img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/8809bfc2768c4deeafe69cd4aa527f6a/%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%202022-06-10%2021.43.15.png" alt=""> はい、これです。 読んで時のごとく、バケット内のオブジェクトの所有権をどう扱うか、ということの設定です。 そもそもACLについてはっきり理解していなかったのでわからなかった設定です。 <h3 id="h29ccbc7d58">ACL無効(推奨)</h3>この設定にすると、バケット内のオブジェクトはすべてバケットの所有者(そのバケットが存在するAWSアカウント)が所有することになります。 また、この設定にすることでACLが無効になります。 ACLを考慮することがないので、S3へのアクセスは、<code>バケットポリシー</code> <code>ユーザーポリシー</code>のみ考慮すれば良いので、アクセスコントロールが容易になるというメリットがあります。 基本的なS3のユースケースはこの設定で十分対応できるので、現在はACL無効の設定が推奨されているようです。 <h3 id="hacbd2586f2">ACL有効</h3><img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/d36131944cb544198ef7fe7b89a5cd8a/acl_on.png" alt=""> こちらはACLが有効になります。 まあ説明文に書いてある通りなんですが、この設定ではバケット内のオブジェクトの所有者がこのバケットの所有者ではない場合があり、その場合そのオブジェクトのアクセスコントロールはバケットポリシーではなくACLが適用されますよ、ということです。 <h4 id="h842c47e7d2">希望するバケット所有者</h4>アップロード時、オブジェクトのACLにbucket-owner-full-controlを指定すると、バケットの所有者がオブジェクトの所有者になり、指定しないとオブジェクトライター(アップロードしたアカウント、IAMユーザー)が所有者になります。 <h4 id="h5fd095f6e7">オブジェクトライター</h4>そのまま。アップロードユーザーが所有者になります。 複数アカウントで同じバケットを利用する場合はこの辺の考慮が必要になりそうですね。 <h3 id="hb21c3b1c40">ブロックパブリックアクセス</h3>先ほども少し話しましたが以下の設定です。 パブリックアクセス、つまり匿名ユーザーのアクセスをどう扱うか、に関する設定です。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/4f16f0670147467db27617069ed7e8cc/publicblock.png" alt=""> (日本語がわかりにくい.....) 英語で説明を読んだ方がわかりやすいかもしれない。 <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-options" target="_blank" rel="noopener noreferrer">https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-options</a> 上２つと下２つは対象がACLか、ポリシーかの違いだけなので、今回はポリシー対象の設定についてだけ見ていきます。 <h4 id="hddec3116ea">新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする</h4>これだけ読むと、この設定ONで匿名アクセスがブロックされるのかと思いました。 ですが、説明をみると少しわかりやすいです。 <blockquote>S3 は、バケットとオブジェクトへのパブリックアクセスを許可する新しいバケットポリシーおよびアクセスポイントポリシーをブロックします。この設定は、S3 リソースへのパブリックアクセスを許可する既存のポリシーを変更しません。</blockquote> つまり、新しくバケットポリシーなどで、匿名アクセスを許可するようなポリシーを作成したり追加したりするのをブロックする、ということです。 実際、この設定をONにして、<code>principal: "*"</code>のように匿名アクセスを許可する変更を入れようとすると、以下のように変更が弾かれます。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/55291aee83fc4354b6d60522d53a4353/error.png" alt=""> また、ポリシーの変更をブロックするだけなので、この設定によって現在許可されている匿名アクセスがブロックされることはありません。 <h4 id="h80015d2f7d">任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする</h4> こちらはもっとシンプルです。 単純に、現在匿名アクセスを許可しているポリシーを無視して匿名アクセスをブロックする設定です。 つまりこの設定をONにすると匿名でのアクセスはできず、AWSアカウントやIAMユーザー・ロールでのアクセスのみをバケットポリシー等で管理することになります。 <h2 id="ha214098e44">まとめ</h2>複数アカウントでバケットを利用するなどのユースケースでなければ、バケット所有者を強制してACL無効で管理が良さそうです。 また、ブロックパブリックアクセス設定も、設定の変更を禁止するか、パブリックアクセスを禁止するか、とわかってしまえば単純だったので、今後は設定に悩むことはなさそうです。 今後クロスアカウントのアクセス管理などをする機会が出て来れば、ACL周りについてより詳しく勉強してみようと思います。

S3のアクセスコントロールについて

Firestoreでリアルタイムチャットを実装する

こんにちは、ばんがです。 Redash SaaSのサービス終了に伴って、業務でRedashの自前での構築・SaaSからのデータ移行を実施したのでざっくりまとめようと思います。 Hosted Redashの終了について。 <a href="https://redash.io/help/faq/eol" target="_blank" rel="noopener noreferrer">https://redash.io/help/faq/eol</a> <h2 id="h2a1a7bcf5b">Self-Hosted Redashの構築</h2>RedashはOSSでコードが公開されているので自前で構築することができます。 公式から全部入りのAMIが提供されていますので今回はこちらを利用。 Redash自体はもちろん、DB(postgresql, redis)、nginxなどが入っておりこのAMIを使ってEC2を立ち上げればRedash環境が出来上がります。 <a href="https://redash.io/help/open-source/setup" target="_blank" rel="noopener noreferrer">https://redash.io/help/open-source/setup</a> とはいえVPCなどネットワーク周りやSSL化するためにロードバランサーなどを作る必要があるので、Terraformを使って必要なリソースを構築しました。 まずは、公式が提供するAMI(ap-northeast-1)を使ってEC2インスタンスを定義。 インスタンスタイプは、最低限smallが必要らしいので<code>t3.small</code>にしました。<pre><code>resource "aws_instance" "redash" {
	 ami = "ami-060741a96307668be"
	 instance_type = "t3.small"
	 subnet_id = aws_subnet.redash_public_a.id
	 ebs_optimized = true
	 vpc_security_group_ids = [
	 aws_security_group.redash.id
	 ]
	 monitoring = false
	 key_name = "redash"
	

	 root_block_device {
	 delete_on_termination = false
	 volume_size = 8
	 }
	

	 tags = {
	 Name = "redash"
	 }
	

	 depends_on = [
	 aws_subnet.redash_public_a,
	 aws_security_group.redash
	 ]
	}</code></pre> 割愛しますが、VPCやサブネット、ロードバランサーなども定義しておきます。 IP制限をかけたいので、セキュリティグループも定義しましょう。 EC2用とロードバランサー用それぞれを定義します。 Redashで連携した外部データソースと通信するので、EC2用にもアウトバウンド(egress)許可を入れておく必要がありました。<pre><code># EC2用
resource "aws_security_group" "redash" {
 name = "redash"
 description = "For Redash"
 vpc_id = aws_vpc.redash.id

 ingress {
 from_port = 80
 to_port = 80
 protocol = "tcp"
 security_groups = [aws_security_group.redash-lb.id]
 }

 lifecycle {
 ignore_changes = [ingress, egress]
 }
}

# ロードバランサー用
resource "aws_security_group" "redash-lb" {
 name = "redash-load-balancer"
 description = "sg for redash application load balancer"
 vpc_id = aws_vpc.redash.id

 egress {
 from_port = 0
 to_port = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
 }
}</code></pre> Redash関連の全リソースの定義はこちらにあります。参考まで。 <a href="https://github.com/bangarrr/terraform-test/tree/master/redash" target="_blank" rel="noopener noreferrer">https://github.com/bangarrr/terraform-test/tree/master/redash</a> <h2 id="he37f42b29f">SaaSからデータを移行する</h2>さて、自前でRedashが構築できたので、SaaS版のRedashからデータを移行します。 公式が提供しているデータ移行ツール(redash-toolbelt)があるのでこちらを利用します。 <a href="https://github.com/getredash/redash-toolbelt/tree/master/redash_toolbelt/docs/redash-migrate" target="_blank" rel="noopener noreferrer">https://github.com/getredash/redash-toolbelt/tree/master/redash_toolbelt/docs/redash-migrate</a> まずはインストールします。 当時の最新版(v0.1.8)ではダッシュボードなど複数のデータの移行でエラーが発生したため、v0.1.6を利用しました。<pre><code>pip install redash-toolbelt==0.1.6</code></pre> 移行作業は、移行元Redashと移行先Redashにアクセスできる環境であればローカル環境で実施できます。 まずは適当な作業ディレクトリで移行設定の初期化をしましょう。<pre><code>@some workdir
redash-migrate init</code></pre> コマンドを実行すると、移行元・移行先Redash双方のURLやadminユーザーのアクセスキー、ユーザーIDなどが聞かれるので入力します。(先ほど作成した移行先のRedashで、あらかじめ初期ユーザーを作っておく必要があります) コマンドが完了すると<code>meta.json</code>ファイルが作成されます。 ここに先程の設定が記載されており、またこれから行う移行コマンドを実行していくと、移行したクエリやデータソースなどの情報が追記されていきます。 <h3 id="h1e587af203">移行コマンドを実行していく</h3>redash-toolbeltではデータを一括移行できるわけではなく、データソース、クエリ、ダッシュボード...など、それぞれを順番に移行してやる必要があります。 公式にも記載がありますが、<code>redash-migrate --help</code>コマンドで移行コマンド一覧が表示されます。基本的に上から順番に実行していけばOKです。(逆に変な順番でやるとうまくいかないです) <h3 id="h10b38ed6b9">移行後の作業</h3>残念ながら上記移行コマンドだけでは完全に移行はできないので、移行先のRedashで追加で作業する必要があります。 <h4 id="h52963ef4d4">データソースの認証情報の設定</h4>データソースと連携するためのパスワード/シークレットキーなどの認証情報は移行されないので、新Redashで再度設定する必要があります。 <h4 id="h8fe9582f0d">既存ユーザーのパスワード</h4>同じく、既存ユーザーのパスワードも移行されません。最初に作成したAdminユーザー以外の既存ユーザーは招待中の状態になるので、各自でパスワード再設定をしてからログインしてもらうことになります。 <h4 id="h96111078d3">グループが重複する</h4>v0.1.6では、デフォルトのユーザーグループ(defaultとadmin)が新旧の分で重複します。 新Redashの方にデフォルトでdefault、adminのグループが存在するのに、グループの移行コマンドによって旧Redashのdefaultとadminが移行されてくるので重複してしまいます。 片方は不要なので、旧のdefault、adminを消しましょう。 ただし、旧グループに入っていたユーザーは新グループの方に追加してください。 <h4 id="hbb567d388a">クエリのIDがリセットされる</h4>これもv0.1.6の問題かもしれませんが、旧RedashでのクエリのID(DB上のIDだと思われます)は移行されず、新Redashでは新しく1から付与されます。 クエリ中に他クエリのIDを直書きしている場合などはクエリが動かなくなるので、新しいクエリIDで置き換える必要があります。 <h2 id="ha214098e44">まとめ</h2>追加の作業を行ってやっとデータ移行が完了しました。 細かいところで色々不具合はありますが、公式の移行ツールが提供されているのはありがたかったです。 現在はv0.1.9も出ているようなので、上記のような細かい問題も改善されているかもしれません。 それではまた。

自前でRedashを構築してSaaSからデータ移行をする

こんにちは、ばんがです。 最近趣味でFlutterを触っており、必然的にDartにも触れることになるのですが、Dartのコンストラクタはいろんな書き方や種類があり少しわかりづらかったので備忘録もかねてまとめようと思います。 <h2 id="hb0d023ac88">Generative Constructors</h2>生成的コンストラクタ(と訳すようです)は、コンストラクタ名・引数・リダイレクト句・Initializer List・ボディから成るコンストラクタです。 基本的には一般的にイメージするコンストラクタと同じものですが、Dart特有の記法や機能があります。 まずは基本的なコンストラクタです。 一般的なコンストラクタの書き方と同じです。 <code>this</code>は現在のインスタンスの参照で、通常名前が衝突する場合などに使用されます。<pre><code>class Point {
 double x = 0;
 double y = 0;

 Point(double x, double y) {
 this.x = x;
 thix.y = y;
 }
}</code></pre> また、代入をより簡易に記述するためにシンタックスシュガーが用意されています。 以下のコードは、コンストラクタのボディ内で代入する先程のコードと同等です。<pre><code>class Point {
 double x = 0;
 double y = 0;

 Point(this.x, this.y);
}</code></pre> <h3 id="h9577cacc32">デフォルトコンストラクタ</h3>コンストラクタを宣言しない場合、Dartが自動的にデフォルトのコンストラクタを提供してくれます。 デフォルトのコンストラクタは引数を持たず、スーパークラスの引数のないコンストラクタを呼び出します。 <h3 id="h044bbbeb03">名前付きコンストラクタ</h3>以下のように名前付きのコンストラクタを宣言することができます。 コンストラクタに名前をつけることで、複数のコンストラクタを作成することができます。<pre><code>class Point {
 double x, y;
 Point.origin1(this.x, this.y);
 Point.origin2() : x = 1, y = 1;
}

var p1 = Point.origin1(1, 1);
var p2 = Point.origin2();</code></pre><h3 id="hcf83e1357e"> </h3><h4 id="h77d88e5f07">スーパークラスの任意のコンストラクタを呼び出す方法</h4>通常サブクラスのコンストラクタは、ボディの実行前にスーパークラスのデフォルトコンストラクタ(名前なし・引数なしのコンストラクタ)を呼び出す仕様です。<pre><code>class Super {
 Super() {
 print('super default');
 }
}

class Sub extends Super {
 Sub.fromJson(json) {
 print('sub');
 }
}

void main() {
 var sub = Sub.fromJson({});
}

main();
// =&gt; super default
// =&gt; sub</code></pre> さらに、Initializer Listがあれば呼び出される順序は以下のようになります。<ol><li>イニシャライザリスト</li><li>スーパークラスの引数なしコンストラクタ</li><li>サブクラスの引数なしコンストラクタ</li></ol> スーパークラスのデフォルトコンストラクタ以外のコンストラクタを呼び出したい場合は、コロンをつけて、ボディの前に呼び出したいスーパークラスのコンストラクタを記述します。 (スーパークラスに名前なし、引数なしのコンストラクタが存在しない場合、この方法でいずれかのコンストラクタを呼び出さないとエラーになる)<pre><code>class Super {
 double x = 0;
 Super.fromJson(double num) {
 x = num;
 }
}

class Sub {
 double y = 0;
 Sub(this.y) : super.fromJson(1)
}</code></pre> コンストラクタへの引数は、コンストラクタが呼び出される前に評価されるので、以下のように関数の呼び出しもできる。 ただし、この引数はthisを参照することはできないので、staticメソッドは呼べるがインスタンスメソッドを呼ぶことはできないようです。<pre><code>class Sub {
 double y = 0;
 Sub(this.y) : super.fromJson(someMethod())
}</code></pre> <h2 id="h360dd13569">Initializer Listとは？</h2>Dart独自の機能で、コンストラクタのボディが実行される前に何らかの処理を実行することができます。 例えば、インスタンス変数を初期化したり、スーパークラスのコンストラクタを呼び出したりなどです。 Initializer Listを使うと、finalなインスタンス変数の初期化が簡単に行えます。<pre><code>class Point {
 final double x, y;
 Point(double x, double y) : this.x = 0, this.y = 0 {
 ...
 }
}</code></pre> 以下のような書き方だとエラー。 ボディ実行時点でxはfinalで初期化されており、代入など変更ができないためだと思われます。<pre><code>class Point {
 final double x;
 Point(double x) {
 this.x = x;
 }
}

var p = Point(0.1);
// Error: The setter 'x' isn't defined for the class 'Point'.</code></pre> シンタックスシュガーを用いた代入であれば問題ない様子。<pre><code>class Point {
 final double x;
 Point(this.x);
}

var p = Point(0.1);
print(p.x);
// 0.1</code></pre> 先程のスーパークラスの任意のコンストラクタの呼び出しも、Initializer Listの挙動と同じのようですね。 <h3 id="h587cc25d74">同じクラスの別のコンストラクタへリダイレクトする</h3>あるコンストラクタから、同じクラスの別のコンストラクタへ処理を委譲することができます。 コロンに続けて、処理を委譲したいコンストラクタを呼び出します。 ただし、コンストラクタを直接呼び出すのではなく、以下のようにthisを使って呼び出す必要があります。<pre><code>class Point {
 double x, y;
 Point(this.x, this.y);
 Point.another(double x, double y) : this.x = x * 10, this.y = y * 10;

 Point.redirect1(double x) : this(x, 0);
 Point.redirect2(double x) : this.another(x, 3);
}

var p1 = Point.redirect1(1);
var p2 = Point.redirect2(1);

print('${p1.x}, ${p1.y}');
// 1, 0

print('${p2.x}, ${p2.y}');
// 10, 30</code></pre> また、Initializer Listと記法が似ていますが、thisを使ってリダイレクトしたときは、ボディを記述することはできないようです。<pre><code>class Point {
 double x, y;
 Point(this.x, this.y);

 Point.redirect(double x) : this(x, 0) {
 ...
 }
}

// Error : Redirecting constructors can't have a body.</code></pre> <h2 id="ha26f8a19ba">Constant Constructors</h2>そのクラスが変化しないオブジェクトを作るときは、コンパイル時定数として生成することができます。 インスタンスをコンパイル時定数にするために利用するのがConstantコンストラクタです。 以下のようにコンストラクタにconstをつけて、全てのインスタンス変数をfinalで修飾します。<pre><code>class ImmutablePoint {
 static const ImmutablePoint origin = ImmutablePoint(0, 0);
 final double x, y;
 const ImmutablePoint(this.x, this.y);
}</code></pre> 呼び出すときもconstが必要になります。<pre><code>var ip = const ImmutablePoint(1, 1);</code></pre> コンパイル時に定数オブジェクトをインスタンス化したい場合に利用するそうですが...。 いまいちまだ使い所がよくわからない🤔 <h2 id="h405ad515b4">Factory Constructors</h2>必ずしもそのクラスの新しいインスタンスを返すわけではない場合に使うようです。 Factoryコンストラクタではインスタンスが自動的に生成されないので、例えばキャッシュデータを返したり、別のクラスのインスタンスを返したりすることができます。 以下のように<code>factory</code>キーワードを事前につけることでファクトリコンストラクタを作ることができます。 (※Factoryコンストラクタはthisを参照できない)<pre><code>class Logger {
 static final Map&lt;String, Logger&gt; _cache = &lt;String, Logger&gt;{};
 
 // キャッシュからインスタンスを返す
 factory Logger(String name) {
 return _cache.putIfAbsent(
 name, () =&gt; Logger._internal(name)
 );
 }
 Logger._internal(this.name);

 //別のコンストラクタを呼び出す
 factory Logger.fromJson(Map&lt;String, Object&gt; json) {
 return Logger(json['name'].toString());
 }
}

</code></pre> <h2 id="h3de35099b3">参考</h2><a href="https://dart.dev/guides/language/language-tour#constructors" target="_blank" rel="noopener noreferrer">https://dart.dev/guides/language/language-tour#constructors</a> <a href="https://dev.classmethod.jp/articles/about_dart_constructors/#toc-5" target="_blank" rel="noopener noreferrer">https://dev.classmethod.jp/articles/about_dart_constructors/#toc-5</a> <a href="https://doitu.info/blog/5c10f5358dbc7a001af33ce5" target="_blank" rel="noopener noreferrer">https://doitu.info/blog/5c10f5358dbc7a001af33ce5</a>

Dartのコンストラクタについて

こんにちは。 ばんがです。 最近趣味でFlutterを触っています。いやぁ...業務と全く関係のない開発って...楽しいですね笑 モバイルアプリの開発はこれまで業務でも趣味でも全く経験がないので、色々調べながら地道に開発をしています。 開発の中で、カレンダーをモーダルで表示する方法がなかなかわからなかったので備忘録として残そうと思います。 <h2 id="h67e83ce9c5">カレンダーのWidgetを作る</h2>まずカレンダーですが、自作すると色々大変なので<code>table_calendar</code>というライブラリを使いました。 <a href="https://pub.dev/packages/table_calendar" target="_blank" rel="noopener noreferrer">https://pub.dev/packages/table_calendar</a> 使い方は簡単で、以下のように記述するだけで立派なカレンダーが表示されます。<pre><code>TableCalendar(
 firstDay: DateTime.utc(2010, 10, 16),
 lastDay: DateTime.utc(2030, 3, 14),
 focusedDay: DateTime.now(),
)</code></pre> ただ、このままだと表示だけの、日付選択などができないカレンダーなので、タップした日付を選択でできるようにしましょう。 Stateful Widgetを作って、選択した日付の状態を保持するようにします。 最終的に以下のようなWidgetになりました。 <pre><code>import 'package:flutter/material.dart';
import 'package:intl/intl.dart';
import 'package:table_calendar/table_calendar.dart';

class Calendar extends StatefulWidget {
 const Calendar({Key? key}) : super(key: key);

 @override
 _CalendarState createState() =&gt; _CalendarState();
}

class _CalendarState extends State&lt;Calendar&gt; {
 CalendarFormat _calendarFormat = CalendarFormat.month;
 DateTime _forcusedDay = DateTime.now();
 DateTime? _selectedDay;

 @override
 Widget build(BuildContext context) {
 return TableCalendar(
 firstDay: DateTime.utc(2010, 10, 16),
 lastDay: DateTime.utc(2030, 3, 14),
 focusedDay: DateTime.now(),
 calendarFormat: _calendarFormat,
 selectedDayPredicate: (day) {
 return isSameDay(_selectedDay, day);
 },
 onDaySelected: (selectedDay, forcusedDay) {
 if (!isSameDay(_selectedDay, selectedDay)) {
 setState(() {
 _selectedDay = selectedDay;
 _forcusedDay = forcusedDay;
 });
 }
 },
 onFormatChanged: (format) {
 if (_calendarFormat != format) {
 // Call `setState()` when updating calendar format
 setState(() {
 _calendarFormat = format;
 });
 }
 },
 onPageChanged: (forcusedDay) {
 _forcusedDay = forcusedDay;
 },
 );
 }
}</code></pre><code>_selectedDay</code>が選択した日付が入る変数です。 <code>_forcusedDay</code>はカレンダー内でフォーカスしたい日付です。(よくある現在の日付が強調表示されてるやつ) <ul><li>selectedDayPredicateは特定の日付が選択している日付かどうかを判定するのに利用されます</li><li>onDaySelectedは日付をタップしたときに発火します。ステートを更新する処理を書いています。</li></ul> <h3 id="ha757352ca1">カレンダーを日本語化する</h3>デフォルトでは英語表記になっているので、日本語にしましょう。 まずアプリ自体のlocaleデータのセットアップをおこないます。<pre><code>void main() {
 initializeDateFormatting().then((_) =&gt; runApp(const MyApp()));
}</code></pre> これで他言語対応の準備ができたので、カレンダーのWidgetで言語を指定します。<pre><code>TableCalendar(
 locale: 'ja_JP',
 ...
)</code></pre> これでカレンダー内の言語を日本語にすることができました。 <h2 id="hf4dfd63cf7">モーダル内にカレンダーを表示する</h2>ボタンを押したらカレンダーがモーダルで出てきて、何か操作を完了したらモーダルが閉じて元の画面に戻る、ということをしたかったので、モーダルで表示できるようにしていきます。 調べてみた感じFlutterでモーダル(ダイアログ)を実現する方法は色々ありそうでしたが、今回はModalRouteを継承して独自のダイアログを実装してみました。 ダイアログ実装部分はほぼほぼ以下の記事を参考にさせていただきました。 <a href="https://www.egao-inc.co.jp/programming/flutter_custom_dialog/" target="_blank" rel="noopener noreferrer">https://www.egao-inc.co.jp/programming/flutter_custom_dialog/</a> <h3 id="h7ef3298fbe">モーダル部分の実装</h3>ModalRouteは、現在のRouteとインタラクションができないような新規のRouteを実現するクラスのようです。 現在の画面の上にポップアップのように表示されますが、これは新規のRouteで、前のRoute(ポップアップ前の画面)とのインタラクションはできないので、モーダルを実現できる、ということのようです。 (まだはっきりどんなものか理解できておらず....) 実際には、ModalRouteを継承したPopupRouteクラスが今回の用途に適していそうだったので、こちらを継承して独自のモーダルクラスを実装しました。 (<a href="https://github.com/flutter/flutter/blob/18116933e7/packages/flutter/lib/src/widgets/routes.dart#L1626" target="_blank" rel="noopener noreferrer">PopupRouteの実装</a>を見る限り、ポップアップ用途に合わせてModalRouteの特定のプロパティを指定しているだけ) <pre><code>import 'package:flutter/material.dart';

class CustomModal extends PopupRoute&lt;void&gt; {
 final Widget contents;

 CustomModal(this.contents): super();

 @override
 Duration get transitionDuration =&gt; Duration(milliseconds: 100);
 @override
 bool get barrierDismissible =&gt; false;
 @override
 Color get barrierColor =&gt; Colors.black.withOpacity(0.5);
 @override
 String? get barrierLabel =&gt; null;

 @override
 Widget buildPage(BuildContext context, Animation&lt;double&gt; animation, Animation&lt;double&gt; secondaryAnimation) {
 return Material(
 type: MaterialType.transparency,
 child: SafeArea(child: _buildOverlayContent(context))
 );
 }

 @override
 Widget buildTransitions(BuildContext context, Animation&lt;double&gt; animation, Animation&lt;double&gt; secondaryAnimation, Widget child) {
 return FadeTransition(
 opacity: animation,
 child: ScaleTransition(
 scale: animation,
 child: child
 )
 );
 }

 Widget _buildOverlayContent(BuildContext context) {
 return Container(
 margin: EdgeInsets.symmetric(horizontal: 32, vertical: 64),
 padding: EdgeInsets.all(16),
 color: Colors.white,
 child: Center(
 child: this.contents
 )
 );
 }
}</code></pre> 継承したクラス内で親クラスのメソッドをオーバーライドしてカスタムしていきます。 <ul><li>buildPageは新規ルート(モーダル内)のコンテンツを記述します。</li><li>buildTransitionsではモーダルのルートにどのように遷移するか、という遷移の挙動を指定できます。</li></ul> <h3 id="h2cb8336e78">モーダルの表示/非表示</h3>最後に作ったモーダルのコンテンツとしてカレンダーを渡し、表示できるようにします。 モーダルはページ遷移と同じように新規ルートへの遷移なので、Navigatorでルートをpushしたりpopして表示/非表示を実現します。 <pre><code>import 'package:flutter/material.dart';
import 'package:weekly_task/custom_modal.dart';
import 'package:weekly_task/calendar.dart';

class CalendarModal {
 BuildContext context;
 CalendarModal(this.context) : super();

 void showCalendarModal() {
 Navigator.push(
 context,
 CustomModal(
 Column(
 children: [
 Calendar(),
 Row(
 mainAxisAlignment: MainAxisAlignment.end,
 children: [
 TextButton(
 child: const Text('キャンセル'),
 onPressed: () =&gt; hideModal(),
 ),
 TextButton(
 child: const Text('選択'),
 onPressed: () {},
 ),
 ],
 )
 ]
 )
 )
 );
 }

 void hideModal() {
 Navigator.of(context).pop();
 }
}</code></pre> あとはタップイベントなどで上記のメソッドを呼び出せばカレンダーのモーダルが表示されます。<pre><code>onTap: () =&gt; { CalendarModal(context).showCalendarModal() }</code></pre> <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/98d65bcfe5bc40ad8f5893555223f04e/calendargif.gif" alt=""><h2 id="ha214098e44"> まとめ</h2>Flutterでモーダル(ダイアログ)と調べると、SimpleDialogやAlertDialogがよく出てきます。 SimpleDialogでもカレンダーWidgetを渡せば同じことはできそうでしたが、リファレンスには<blockquote>A simple dialog offers the user a choice between several options. A simple dialog has an optional title that is displayed above the choices.</blockquote>と書かれており、今回のような場合の用途とは別なのかな、と思って別の実装をしました。 (ほとんど他の方の記事のままの実装ですが...) この辺のFlutterの一般的な実装、というのがまだよくわかってないので、今後もっといろんなリポジトリ等を覗いて把握していけたらと思います。 それでは。 <h2 id="h3de35099b3">参考</h2><a href="https://www.egao-inc.co.jp/programming/fluttercustomdialog/" target="_blank" rel="noopener noreferrer">https://www.egao-inc.co.jp/programming/flutter</a><a href="https://www.egao-inc.co.jp/programming/fluttercustomdialog/" target="_blank" rel="noopener noreferrer">custom</a><a href="https://www.egao-inc.co.jp/programming/fluttercustomdialog/" target="_blank" rel="noopener noreferrer">dialog/</a> <a href="https://qiita.com/coka__01/items/4c1aea5fb1646e463f91" target="_blank" rel="noopener noreferrer">https://qiita.com/coka__01/items/4c1aea5fb1646e463f91</a> <a href="https://api.flutter.dev/flutter/widgets/ModalRoute-class.html" target="_blank" rel="noopener noreferrer">https://api.flutter.dev/flutter/widgets/ModalRoute-class.html</a>

【Flutter】カレンダーをモーダルで表示する

こんにちは、ばんがです。 ブログを始めるにあたって、自分で作った方がモチベがあがるかな？と思って実装してみました。 タイトルにもある通り今回はNext.js(SSG) + microCMS（+ vercel）を利用しています。 いわゆるJamstackと言われるものにしてみました。 <h3 id="he0b0446c65">Next.js / microCMSを選んだ理由</h3>途中で飽きてやめないようにできるだけサクッと作ってしまいたいたいと考えていたので、できるだけ手間がかからないものを選びました。 Next.js(React)を選んだのは、<ul><li>業務で軽く触っているので基本的なことはわかる</li><li>ブログなので静的なサイトで良い &amp; SSGは触ったことがないので勉強したい</li></ul>という理由からです。 バックエンドも手間をかけたくなかったので、自分で実装するのではなくCMSを利用することにしました。 その中でもmicroCMSは日本製でお手軽だったので使ってみることにしました。 日本語のサービスなのでわかりやすかった、というのもあります笑 <h3 id="hd9b90dce3a">ブログの機能、ページについて</h3>現状は投稿一覧、投稿詳細のページ(+ About)という最低限のページしかないです。 機能と言えるほどのものではないですが、<ul><li>記事へのタグ(カテゴリー)付け</li><li>投稿一覧の無限スクロール</li></ul>はできるようにしました。 以下の機能は今後追加していきたいなと考えています。<ul><li>タグ(カテゴリー)やキーワードでの記事検索</li><li>SEO対策やGAの導入</li></ul> <h3 id="h4d4441e346">microCMSで記事APIを作る</h3>microCMSでは画面ぽちぽちですぐAPIが作れます。 以下のように記事を取得するAPIのスキーマを定義します。 <img src="https://images.microcms-assets.io/assets/dd4ccd3769a343f29641f3662a55bf06/eab69984db8340209914271a0b164557/api.png" alt=""> このスキーマにしたがって記事内容を登録すると、こんな感じでAPIレスポンスが返ってきます。 これは記事一覧のAPIですが、自動的に１つの記事を取得するAPIも作成されます。(記事IDを指定)<pre><code>{
 "contents": [
 {
 "id": "XXXXXXXX",
 "createdAt": "2021-09-30T15:42:38.104Z",
 "updatedAt": "2021-10-01T04:45:58.531Z",
 "publishedAt": "2021-10-01T03:10:22.718Z",
 "revisedAt": "2021-10-01T04:45:58.531Z",
 "title": "ブログを始めました",
 "body": "&lt;p&gt;こんにちは。&lt;br&gt;初めましての人は初めまして。.....",
 "category": [
 "雑談"
 ]
 }
 ],
 "totalCount": 1,
 "offset": 0,
 "limit": 10
}</code></pre> <h3 id="ha50e02e1ed">Next.jsからAPIを叩く</h3>microCMSはSDKが提供されているのでそれを使います。 SDKの設定方法については<a href="https://blog.microcms.io/microcms-next-jamstack-blog/" target="_blank" rel="noopener noreferrer">こちら</a>を参照。 今回はSSGで静的サイトとして構築するので、ビルド時にレンダリングが行われます。 そのため、ビルド時にAPIから記事データを取ってきてやる必要があります。 そこで、Next.jsがSSG用に提供している<code>getStaticProps</code>と<code>getStaticPaths</code>というメソッドを使います。 <h4 id="he313a7dc2a">getStaticProps</h4>このメソッドはビルド時に実行され、レンダリングに必要なデータをpropsを通じてコンポーネントに渡すことができます。 SSGでは、このメソッド内でAPIを叩いて記事データを取得する処理を書いておく必要があります。 例えば記事一覧ページの場合以下な実装になります。 getStaticProps内でmicroCMSにある記事データの一覧を取得し、propsにセットしています。<pre><code>const Home: React.FC&lt;Props&gt; = ({articles}) =&gt; {
 // 記事データごとに表示する
 {articles.map((article) =&gt; (
 ...)
 }
}

export const getStaticProps = async () =&gt; {
 let articles: ArticleType[] = [];
 const limit = 10;
 let offset = 0;

 // client = microCMS SDK
 const data: ArticleListType = await client.get(
 {
 endpoint: "articles",
 queries: {limit: limit, offset: offset}
 }
 );

 return {
 props: { articles: articles }
 }
}</code></pre> 参考：<a href="https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation" target="_blank" rel="noopener noreferrer">https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation</a> <h4 id="h08afac0e9f">getStaticPaths</h4>ブログなので、投稿一覧だけではなく１つ１つの記事のページも作る必要があります。 記事IDは外部データ(microCMSにある記事データ)に依存しており、これらのページもビルド時にレンダリングするので事前に必要な記事ページのパスを生成する必要があります。 そこで使うのが<code>getStaticPaths</code>です。 動的ルーティングする必要があるページのコンポーネントに<code>getStaticPaths</code>メソッドを追加します。 ここではmicroCMSにある記事データを取得し、その記事IDごとのページのパスを生成して返しています。<pre><code>export const getStaticPaths = async () =&gt; {
 const data: ArticleListType = await client.get({endpoint: "articles"})

 const paths = data.contents.map((content) =&gt; `/articles/${content.id}`)
 return {paths, fallback: false};
}</code></pre> <code>getStaticPaths</code>も<code>getStaticProps</code>同様ビルド時に実行され、存在する記事IDから必要になる記事ページのパスが生成されます。 <h3 id="hc7e959fa8a">無限スクロールについて</h3>SSGで無限スクロールってどうなんだ...？って気もしましたが実装してみたかったので。 無限スクロールはreact-infinite-scrollerというライブラリを使用しました。 https://github.com/danbovey/react-infinite-scroller このライブラリではwindowや指定したDOMの最下部に到達するたびに次のデータを読み込むコールバックが呼ばれます。 SPAで作るのであれば、このコールバック内でmicroCMS APIを呼び出して次のデータを取得すれば良いのですが、SSGではもちろんできません。 SSGではビルド時にレンダリングが行われるので、<code>getStaticProps</code>で全データを取得しておく必要があります。 以下のようにして実装してみました。<pre><code>const Home: React.FC&lt;Props&gt; = ({articles}) =&gt; {
 const itemsPerScroll = 10;
 const [hasMore, setHasMore] = useState(articles.length &gt; 10);
 const [items, setItems] = useState&lt;ArticleType[]&gt;(articles.slice(0, itemsPerScroll))

 const loadMore = (page: number) =&gt; {
 const startIdx = page * itemsPerScroll;
 const endIdx = startIdx + itemsPerScroll;
 setTimeout(() =&gt; {
 setItems(items.concat(articles.slice(startIdx, endIdx)))
 if (endIdx &gt; articles.length) setHasMore(false);
 }, 500)
 }

 return (
 &lt;div&gt;
 &lt;InfiniteScroll
 pageStart={0}
 initialLoad={false}
 loadMore={loadMore}
 hasMore={hasMore}
 loader={&lt;Loader key="loader"&gt;&lt;Loading/&gt;&lt;/Loader&gt;}
 &gt;
 {
 &lt;ul&gt;
 {items.map((item) =&gt; (
 // 記事一覧を表示する処理
 ))}
 &lt;/ul&gt;
 }
 &lt;/InfiniteScroll&gt;
 &lt;/div&gt;
 )
}

export default Home;

export const getStaticProps = async () =&gt; {
 let articles: ArticleType[] = [];
 const limit = 10;
 let offset = 0;

 while (true) {
 const data: ArticleListType = await client.get(
 {
 endpoint: "articles",
 queries: {limit: limit, offset: offset}
 }
 );

 if (data.contents.length === 0) break;

 articles = articles.concat(data.contents);
 offset += limit;
 }

 return {
 props: { articles: articles }
 }
}</code></pre> データ自体は事前に全取得しておきコンポーネントに渡します。 コンポーネントでは一度のローディングで表示したいデータ数を制限し、ページ最下部に到達してloadMoreコールバックが呼ばれた時に、次のデータセットを読み込んでいます。 <h3 id="h5fcec0cf90">所感</h3>Next.jsでの静的サイト生成は<code>getStaticProps</code>、<code>getStaticPaths</code>という便利なメソッドが提供されているため非常に簡単に実装できました。 公式ドキュメントもすごくわかりやすく書かれているので、つまづくところはあまりなかったです。 microCMSも、普通のブログを作るだけなら画面ぽちぽちでサクッとAPIを作れるしUIもわかりやすいし、非常に便利だと思います。 強いて言えばMarkdownでもっと記事が書きやすくなればな...というくらいです。 ひとまず最小限の機能で作ったので、今後は検索機能やSEO対策など拡張していきたいと思います。 それではまた。

Next.js + microCMS で自作ブログを構築しました

こんにちは。 初めましての人は初めまして。 「ばんが」と申します。 普段はWebエンジニアとして働いています。(バックエンド多め、フロントもちょこちょこやります） 最近フリーランスになったのもあり、あまりアウトプットの習慣が身についてないなぁ...と焦りを覚えたのでブログを始めてみました。 日々の業務や趣味の開発の技術的な知見をできるだけアウトプットしていこうと思います。 技術ブログのつもりで作ったのですが、ゲームや漫画、お酒も好きなのでそういう話も残していけたらなと考えてます。 最近はAPEXに没頭する日々です...笑 ちなみにこのブログはNext.js + microcms + vercelで作りました。(自分でブログを作れば継続するかなと思ったので) それについてはまた別の記事でまとめを残そうと思います。 それでは。