00:05
はい、おはようございます。僕は朝9時ですね。5月26日朝9時を回ってますけども。
今日の東京もあいにくの曇りですけどもね。はい、みなさんいかがお過ごしでしょうか。ゆめみのくわはらです。
沢山ですね、ご参加いただきありがとうございます。今始めたばっかりです。
で、本日も朝活を始めていきたいかなと思います。
で、今日はですね、タイトルにもあります通り、Next.jsのLayouts RFCというページがあってですね、そこの
プロポータル?
リクエストの方をちょっと読んでみたいかなと思います。
視聴者さんもご参加いただきありがとうございます。
はい、Next.jsのドキュメントを読んでいこうかなと思っています。
ではですね、Next.jsのLayouts RFCですね。
最終更新は2日前だそうですね。
4名の方で書いていただいているというところで、英語なのでいつも通り
DeepLを使って翻訳しながら、ちょっとずつ読んでいこうかなと思っています。
では、えっと
出てます。This is RFC翻訳を受け取りたいと思います。このRFCというのは
2016年に書かれているものっぽいですね。
に導入されたNext.jsの
最大のアップデートの概要を説明するものだそうです。
なるほど。
で、その中にいくつか機能が入っているんですけど、
1つはNestedLayoutsですね。
これは、ネストされたルートで複雑なアプリケーションを構築できるようになりますよというのと、
サーバーコンポーネンツを再設計したという感じですかね。
これは
サブツリーナビゲーションに最適化したようなものですよと言ってますね。
続いて、データフェッチングの改善ですね。
で、
データのフローのところですね。
ウォーターホールというワードを使っているがちょっと、ん?ってなったけど、
そのウォーターホールを回避しながらレイアウトでも取得できるようになりますよと。
これバケツリレーの話かな?
わかんないです。ちょっと後ほど読んでいきましょうかね。
で、続いてリアクト18の機能を使い、導入して、それに対応しましたよということだそうですね。
はい、これはストリーミングとトランジッションのサスペンスですね。
はい、機能を読んだ内容をそのままNextでも対応しますよと言っていますね。
で、クライアントとサーバーのルーティングですね。
いわゆるSPAのような動作でサーバー中心のルーティングも行えるようにできますよというような感じですね。
で、続いて、
100%の段階的な導入ができるようになりますよと。
いわゆるその破壊的変更というのがなく、
徐々に徐々にちょっと採用することもできますよと。
で、ラストに、
高度なルーティングの規約的なものを入れていると。
03:00
規約ですか。
で、何ですか、オフスクリーンのスタッシングであったり、
インスタントトランジッションなどとかを導入してますよと。
そういう感じなんですね。
で、これが2016年に言っていたその大きな変更だそうですね。
これすごい、2016年の時にそれをもう既に企画してたってことですね。
で、新しいNext.jsのルーターというのが、
最近リリースされたリアクト18の機能の上に構築される予定ですと。
今から、なるほどですね。
で、もうこれらの新機能を採用してですね、
それらが解決する利点とか活用できるように、
デフォルトや規約を導入する予定ですと。
今準備中、だからRFCなんですね。
タイトルが、はいはい。
で、それらまた一個一個ちょっと入ってきますけど、
まずタイムラインからですね。
タイムラインとは、はい。
このRFCというのは2つのパートに分かれているというふうに書いてますね。
パート1っていうのが、この投稿自体のものですね。
この投稿自体は、新しいルーティングシステムの概要と、
それがリアクトサーバーコンポーネンツとか、
データフェッチングとどのように統合されるのかっていうのに言及をしてます。
で、パート2として次の投稿ですね。
高度なルーティングの例と、規約、そしてNext.jsが
ストリーミングと選択的なハイドレーションとサスペンスを
裏で使用する方法っていうのを、次回の方で書いているってことですね。
はい。
で、続いてモチベーションの話をするそうですね。
モチベーションですね。
我々はGitHubとかDiscord、Redditおよび開発者の調査から、
Next.jsにおけるルーティングの現在の制限について、
コミュニティのフィードバックを収集しています。
現在もかな。で、その結果以下のことが分かりました。
で、大きく2つには分かれていて、
1つ目がレイアウトを作成する際の開発者のエクスペリエンスを
向上させることができるようになると。
で、ネスト可能でかつルート間で共有も可能になりますと。
で、ナビゲーション時に状態が保持されるレイアウトを
簡単に作成するようにすべきですよねっていうのが
今のところの1つの結論ですね。
で、2つ目がNext.jsのアプリケーションの多くっていうのは
やっぱりダッシュボードであったりコンソールであったり
より高度なルーティングソリューションの恩恵を受けることが
できるようになりますよねっていうこと。
これが2つ目のモチベーションだそうですね。
はい。で、引き続き読んでいくと、
現在のルーティングシステムっていうのは
Next.jsの初期からうまく機能していますけども、
我々は開発者がよりパフォーマンスと機能の高い
ウェブアプリケーションを簡単に構築できるように
したいと考えています。
で、またフレームワークのメンテナーとして
広報互換性があって、リアクトの将来と
方向性とかと一致するルーティングシステム
っていうのも構築したいと考えています。
はぁ、大事なことですね。
広報互換性やっぱり欲しいですもんね。
これだけ大きいフレームワークですと。
06:00
で、注意として、
いくつかのルーティング規約っていうのは
そのサンバーコンポーネンツのいくつかの機能が
もともと開発されたメタのリレーベースのルーターとか
リアクトルーターやエンバージェイスなどの
クライアントサイドルーターに触発されたものだと
言ってますね。
リレーベースだったんですね。
リアクトルーターとエンバージェイス。
エンバージェイスの要素とかから触発されてたんですね。
それは知らなかった。
今回のレイアウトジェイスのファイル規約っていうのは
Svelteキットで行われた作業からもヒントを得ました。
はぁ、なるほど。
で、またレイアウトに関する初期のRFCを
開いてくれた、書いてくれた
書いてくれた
カシッティっていう人かな?
に感謝はしますよと言ってます。
はいはい。
で、一応このARIA RFC on Layoutsっていう
ドキュメントが別途書かれていて
それのリンクも貼ってあるので
それは後ほどですね。
ちょっと今日はこれ読んでいくと大変なので
割愛します。
では、続いて
知らない単語だな。なんだ?
ターミノロジー、用語解説。
あぁ、そんな言葉があったんですね。
はい、じゃあ次で用語解説だそうです。
このRFCでは新しいルーティングの規約と
公文を導入しています。
で、用語っていうのは
リアクトと標準的なウェブプラットフォームの
用語に基づいていますと。
で、RFC全体を通して
これらの用語は以下の定義にリンクされています。
一つ目がツリーですね。
ツリーっていうのはもちろんそのまんまです。
階層構造を視覚化するための規則で
例えばその親子のコンポーネントを持つ
コンポーネントツリーとか
フォルダ構造とか
一般的なツリーと思ってもらえればいいそうです。
で、次はサブツリーですけど
サブツリーっていうのはそのツリーの一部で
ルートですね。
先頭から始まり、末尾で終わるものだと。
はい。
これもそのままの
今までのものと何も変わらないですね。
ただちょっとドキュメントはちゃんと図があるので
大変申し訳ないけど図を表示できないのは
ちょっとあれですけどね。
でも一般的なツリー構造を想像してもらえれば
全然問題ないのかなと思ってます。
で、続いてURLパスです。
これもURLのうちドメインの後に来る部分ですね。
はいはいはい、なるほどね。
それをURLパスと今回のドキュメントが読んでます。
で、ラストURLセグメントですね。
セグメントはもちろんスラッシュで区切られた
URLパスの一部のことをセグメントと言ってます。
はい。なのでセグメントは複数
発生することもあり得るよねってことですね。
で、そのセグメント全部交えたものを
パスだと言ってます。
はい。
が、今回のドキュメントの定義ですね。
では、続いての話、どんどん読んでいきますけども。
次がHow Routing Currently Worksですね。
はい、現在どんなふうに動いてますかってことだそうですけど。
現在Next.jsっていうのは
そのファイルシステムを利用していて
Pages Directoryにある個々のフォルダとかファイルを
URLでアクセスできるように
ルートにマッピングをしています。
はい。
で、各Pagesファイルっていうのは
Reactコンポーネントをエクスポートして
09:01
ファイルに基づいたルーティングを持っています。
例えばっていうのが
そのまさに図で書いてあるんですけど。
Pagesの下にindex.jsがあったら
それはドメインスラッシュの
本当にインデックスのページですね。
で、Pagesの下に
例えばダッシュボードっていう
ディレクトリを切っておいて
その中にindex.jsとか
settings.jsみたいに作っておくと
index.jsの方が
スラッシュやダッシュボードっていうURLにリンクして
settings.jsの方が
スラッシュやダッシュボードを
スラッシュやセッティング
っていうところにルーティングするように
next.jsは解釈をしますと。
これは我々が今知っている
next.jsの認識と一致していると思いますね。
next.jsっていうのは
仮括弧のpass.jsとか
仮括弧のparam.jsとか
仮括弧二つ重ねて
paramとかっていうような規約で
ダイナミックルーティングですね。
キャッチオールバリエーションも含むものにも
対応していますよと。
これいわゆるあれですね。
ワイルドカード的に
特定の名前ではなくて
仮括弧で文字列として受け取るよ
みたいな感じですね。
っていうようなダイナミックルーティングも
一応できますと。
レイアウトの話ですね、次は。
レイアウトは
シンプルなコンポーネントベースのレイアウトで
コンポーネントプロパティによる
ページ単位のレイアウト
カスタムアプリケーションによる
単一のグローバルレイアウトも
サポートしていますよっていうですね。
これが今の
NEXTのレイアウトディレクトですかね。
で、次データフェッチングですけども
データフェッチングっていうのは
NEXTがページもしくはルートレベルでの
利用可能なデータ取得メソッド
例えばGetStaticPropsとか
GetServerSidePropsですね。
を提供していますと。
で、これらのメソッドっていうのが
ページがスタティックジェネレート
GetStaticPropsのほうか
ServerSideRenderですね。
GetServerSidePropsの
メソッド化を判断するために
利用していますと。
で、さらに
インクリメンタルスタティックジェネレーションですね。
リジェネレーションか。ISRです。
を使用すると
サイトを構築後に
静的ページを作成または更新することも
できますよと。
これがやはり便利ですよね。
NEXTのかなり大きな機能一つだと思います。
で、ラストにレンダリングですね。
レンダリングっていうのは
NEXT.jsに3つのレンダリングオプションがあって
一つは動的な生成と
もう一つがサーバーサイドレンダリングと
最後はクライアントサイドレンダリングですね。
で、デフォルトは
ブロッキングデータ取得の要件
GetServerSidePropsがない限り
ページは静的に生成するように
設定されていますと。
はい、そうですね。
ここが
現在のNEXTの挙動ですよね。
で、ここから
Introducing the App Folder
次はApp Folderの話に移るんですね。
はい。
で、App Folderは
新しい改良を確実に段階的に採用し
変更を壊さないようにするために
Appという新しいディレクトリを提案しますと。
12:01
ここから新しい話に入っていくわけですね。
ふんふん。
で、ここもちょっと図があるんですけど
Pages Directoryはさっきのまんまで
それに加えてAppっていうディレクトリが
一個生えるそうですね。
で、App Directoryっていうのは
Pages Directoryと並行して動作をすると。
で、広報互換性のために
Pages Directoryの動作をそのまま維持しておいて
引き続きサポートもする予定だと。
アプリケーションの一部を
新しいApp Directoryに移動して
新機能を活用することができますと。
はいはいはい、なるほどね。
既存のままだったら
そのPagesのまま使ってくださいと。
で、新しい機能を使いたければ
App Directoryに移行してくださいってことだな、これは。
で、それはなんでだ。
で、続いてディフィニッティングルートなので
ルートの定義の話をするそうですね。
で、続いて読んでいきますと
アプリ内のフォルダ回想を一回利用して
ルートを定義することができるようになりますと。
で、ルートっていうのは
ルートフォルダから最適なリフォルダまで
まったんですね。
サブツリーフォルダまでの回想をたどる
ネストされたフォルダの単一のパスですよと言ってます。
あー、はいはいはい。
さっきのPagesってやつと
構成は基本的に一緒ですね。
Appにしても。
で、同じように回想構造を
ネクストの中の方で
作っていくんじゃないかな。
で、それを認識していくんだと思いますね。
で、例えば
えーっと
例えばこれどういうことだ。
例えばApp Directoryに
新しい2つのフォルダを入れ子にすることで
新しいダッシュボードセッティングスルートを
追加することができると。
あー、だからこれはさっきの
Pages Directoryの構成をそのまま
やっぱりAppに
同じものを持ってきたら
同じことできますよと言って感じですね。
図的にも同じことを言ってました。
で、注意事項がもう1個出てきてます。
今回その新しいシステムっていうのは
フォルダでルートを定義して
ファイルでUIを定義します。
例えばLayout.js、Pages.jsとか。
RFCの第2部では
Loading.jsといった新しいファイル規約も
使用するそうですね。
次の記事をちょっと見てみましょうかね。
これによって独自のプロジェクトファイル
UIコンポーネントとかテストファイルとか
ストーリーなどを
App Directoryの中に配置することができて
これは現在のところPagesでは不可能ですと。
あー、そうですね。
それはそうですね。
Pagesの中では本当Pages定義の.jsファイルしか
今のところ機能しないはずなので
これが今後アプリケーション
App Directoryの中の方で
コンポーネント単位とかで
ディレクトリを切って
その中に定義、テスト用のファイル
ストーリーブックの定義ファイルとかも
置けるようになりますよと言ってますね。
これはこれで確か新しいとか
嬉しい変更だなと思いますね。
15:00
続いてルートセグメントですね。
ルートセグメントの話ですけど
サブツリー内の各フォルダーっていうのは
ルートセグメントを表している。
各ルートセグメントっていうのは
URLパスに対応するセグメントと
マップされますよと言ってますね。
図のやつを説明していくと
まずApp Directoryの中ですね。
App Directoryってのは基本的に
URLパスでいうスラッシュですね。
トップレベルのインデックスだと思います。
続いてその下にダッシュボードって
ディレクトリを切ったら
そのダッシュボードセグメントが
一個生えて
さらにその下にセッティングか
っていうディレクトリを切ると
そのセグメントが切られて
パス的にもスラッシュ、ダッシュボード
スラッシュセッティングになるよ
って言ってますね。
もう一個そこに注意事項があって
名前については気をつけてくださいと。
予約している名前もあったりするらしいんで
そこを使わないようにと。
そのURLパスっていう別のリンクがあるんで
そこも参照してくださいね
っていう風に言ってますね。
続いてレイアウトアウトクリエイティングUIですね。
ではその話ですけど
新しいファイル規約ですね。
先ほどがちょこちょこ出てきている
レイアウト.jsっていうファイルの
新しい規約のことを次は言及してます。
これまでアプリケーションのルートを
定義するためにフォルダを使ってきましたけど
しかし空のフォルダをそれだけでは
ぶっちゃけ何も意味しないよ
ということですので
新しいファイル規約っていうのを使って
これらのルートに対してレンダリングされる
UIを定義する方法について
ちょっと説明していこうかなと思ってます。
レイアウトはサブツリー内の
ルートセグメント間で共有される
UIであります。
レイアウトっていうのは
URLパスには影響しないで
ユーザーが同じレイアウトを
共有するセグメント間を移動しても
再レンダリングされません。
リアクトの状態はその他に保持されますよ
と言ってますね。
サブツリー内のルートセグメント間で
共有されるUIです。
UIも共有すると。
レイアウトはURLパスには影響しなくて
ユーザーが同じレイアウトを共有する
セグメント間を移動しても
再レンダリングもされません。
なるほどですね。
レイアウトはデフォルトで
レイアウト.jsファイルから
リアクトコンポーネントを
エクスポートすることでも定義できます。
このコンポーネントっていうのが
チェルドレンプロップを指定して
渡していくと。
チェルドレンプロップには
レイアウトを含むセグメントを
入力するようにしますよと言ってますね。
現在のところの設計では
レイアウトは2種類分かれているよと言って
一つはルートレイアウト
もう一つはレギュラーレイアウト
ってやつですね。
ルートレイアウトは名前の通り
全てのルートに適用されるレイアウトですね。
もう一個が特別なセグメントだけに
18:00
適用されるレイアウトだと。
ルートとレギュラーって
二つの概念があるらしいですね。
全部に共通するものを定義したければ
ルートレイアウトの方に定義すればよいと。
それらについては
Nested Layoutsの方で言及をしているので
そっちも一緒に読んでもらえると
いいなかなと思っていると書いてますね。
今出た二つの説明を
ちょっとずつ一個一個説明されてますね。
まずルートレイアウトの方から見ていきますが
ルートレイアウトですね。
アプリケーションアップですね。
APPフォルダ内に
レイアウト.jsファイルを追加することで
アプリケーションの全てのルートに適用される
ルートレイアウトを作成することができます。
このレイアウト.jsっていうのは
もうこの名前じゃないとダメっぽいですね。
注意としては
ルートレイアウトっていうのは
全てのルートに適用されるため
カスタムアップ
例えば既存のunderbar.app.jsファイルとか
カスタムドキュメントですね。
underbar.document.jsファイルとかの
必要性とかも置き換えてしまうようになりますよと。
ルートレイアウトを利用して
最初のドキュメントシェル
HTMLタグとかボディタグとか
をカスタマイズすることもできるようになりますよと。
ルートレイアウトです。
および他のレイアウト内部で
データ取得メソッドを使用できるようになりますと。
なるほどですね。
今までと同じようなことが
レイアウトでもちろんできますし
新しいファイルですので
既存のapp.jsとドキュメント.jsとかの書き方も
ふわ書きできるようになるのかなと思いますね。
これどっちが優先されるんだ?
どっち優先されるかは言及されていないので
この辺は触ってみないと何とも言えないですね。
少なくとも既存の機能はできるし
appとかドキュメントではなくて
新しくレイアウトを定義したければ
app.appdirectの中に
レイアウト.jsを作って定義すればいいということですね。
ここはまだ既存の運用方法であったり
設計等の兼ね合いがあると思うので
一旦好みで決めてもいい気がしますね。
レイアウトに関しては既存のappとドキュメントで
定義をしていくのも全然いいと思ってます。
ただ新機能を使いたければ
やっぱりapp.appdirectを切るっていうのは
やっぱり必須だと思うので
そこをどこまで導入するかというのと
いっぺんにガンってやるんじゃなくて
NEXT公式が何度も言って
レースの段階的な導入をしていくっていうのを
プロジェクトとかプロダクトごとに
相談をすることになるのかなと思いましたね。
続いてレギュラーレイアウトですね。
こちらは特定のフォルダ内に
レイアウト.jsファイルを追加することで
アプリケーションの一部にのみ
適用されるレイアウトを作成することができます。
例えばさっきのappdirectoryの配下に
ダッシュボードっていうディレクトリを切った場合
そのディレクトリの中に
21:01
レイアウト.jsファイルを作成してしまえば
このダッシュボードっていうセグメントのみに
適用されるレイアウトっていうのが
定義できるっぽいですね。
ここもあまり言及されてないですけど
次の焦点ありましたね。
ネスティングレイアウトですね。
トップにもレイアウトがあって
セグメントの方にもレイアウトがあった場合
どうするのっていう話が次出てきてますね。
次が
レイアウトってのは基本的に
デフォルトでネストされるようになりますよと。
例えば
Appディレクトリの下にそのレイアウト.jsを作って
そのダッシュボードディレクトリの下に
さらにレイアウト.jsを作っていった場合ですね。
っていうのはルートのレイアウトですね。
App直下のレイアウト.jsっていうのの設定は
もちろんダッシュボードレイアウトにも
適用されるんですけど
その下に作られた
ダッシュボードの下のレイアウトは
これが上書きをするっぽいですね。
末端の方にあるレイアウト.jsの方が
最終的に適用されるんじゃないかなと思いますね。
なるほど。
続いてPagesのお話に移っていきますが
残り時間があと5分近く
あってきたので
全部はさすがに読み切れないので
どっかで区切ろうと思いますね、今日も。
明日続きを読んでいこうかなと思いますが。
では次ですね。
新しいファイル規約Pagesの話ですね。
既存にもPagesディレクトリあるんですけど
今回からはPages.jsっていうファイルが
新しい規約として導入されるようになるってことですね。
Pagesとはルートセグメントに固有のUIで
ルートが有効であるために必要なものだと言ってます。
このルートっていうのは
ドキュメントルート的なルートではなくて
ルーティングの方のルートですね。
フォルダ内にPages.jsファイルを追加することで
ページを作成することができます。
先ほども言っておきました
例えばAppDirectoryの下に
ダッシュボードっていうディレクトリを切っていて
ダッシュボードディレクトリの下に
一旦Layout.jsを置いておきます。
それぞれのページっていうのを
ダッシュボードの中でもページがいくつかあると思ってて
今回の公式のドキュメントの例でいくと
セッティングスとアナリティクスっていう
2つのディレクトリを切ってますね。
それぞれがダッシュボードの中のページだと思うんですけど
ページとして機能させたいんであれば
それぞれのディレクトリの下に
Pages.jsを作ってくださいという感じですね。
なのでちょっとファイル構造のネストが
増えていく感じになりますね。
新しいネクストのルートのいくと。
それを作ることでユーザーが
スラッシュダッシュボードをスラッシュセッティングスとか
スラッシュダッシュボードをスラッシュアナリティクスとか
にアクセスしたら
ちゃんとページとして表示されるようになりますよと言ってますね。
24:02
さらにそのサブツリーのさらに上に存在するレイアウトも
ラップしてレンダリングすると。
なのでレイアウトはちゃんと
そのページのとこにも適用されるようになりますよ
ということを言ってますね。
この辺も図はありますけど
文号でも十分伝わるかなという感じはあるかな。
続きましてもうちょっとページ図のお話が出てきますね。
注意書きまでもう一遍に翻訳しちゃいますね。
続いてダッシュボードホルダー内に
直接ページ.jsファイルを作成して
そのスラッシュダッシュボードルートと一致させることもできますよと。
先ほどの例だとダッシュボードの下に
アナリティクスとかセッティングスとかディレクトリを切って
その下にページ.jsを作っていて
ダッシュボードっていうページ自体作られてなかったけど
もちろんダッシュボードっていうページを作りたければ
ディレクトリの下にページ.jsを作っておけば良いと。
もちろんここにも先ほど定義したレイアウトというのは
適用されますよと言ってますね。
セグメントの話はさっきと被るので割愛ですね。
同じことを言ってますね。
注意書きです。
ルートが有効であるためには
そのサブツリーのところのセグメントにページがある必要があります。
そうでない場合は基本ルートは404を表示するようになりますよと。
さっきのようにアップディレクトリの下の
ダッシュボードディレクトリの下にページ.jsを作ってなければ
スラッシュダッシュボードってアクセスしても
404になるってことですね。
ページ.jsファイルっていうのはデフォルトで
Reactコンポーネントにエクスポートをする必要があります。
Reactコンポーネントとして定義しろと。
名前はpage.js or jsx or ts or tsx
どれかで作ってねってことを言ってますね。
ページコンポーネントエクスポートしない場合は
next.jsはエラーを投げますよと言ってます。
はい、なるほどですね。
なのでpage.jsっていう名前も予約しっかり定義されてるので
この名前で定義してねってことだそうですね。
あと2分か。いけるか?いけない気がするな。
続いてのお話がレイアウト&ページビヘイビアということで
レイアウトとページの挙動についてのお話なんですけども
ちょっと時間足らない気がするので
しかもかつ中途半端な話になりそうなので
ここで一旦切りたいと思いますね。
続いては明日に引き続きしたいと思いますけど
明日お話するのは今言ったレイアウト&ページビヘイビアで
前の話とリアクトサーバーコンポーネンツについての言及と
リアクトサーバーコンポーネンツが結構長いですね。
これがサブセクションに分かれて結構ワーって書いてあるんで
これ明日結構時間かかりそうですね。
27:01
なおかつ明日はソースコードが結構例に出てくるお話ばっかりなので
ちょっとこの配信音声だけだと伝わらない可能性が
多いにあるかもしれないので大変申し訳ないですね。
まあしょうがない。音声の限界はあります。
で、サーバーコンポーネンツ終わったらデータフェッチングの話をして
最後なんだ、ペヘイビア&プライオリティですね。
振る舞いとプライオリティ、優先度の話をしてますね。
で、データフェッチング&レンダリングwithリアクトサーバーコンポーネンツ
ハイハイハイっていうのを使った、実践的な話っぽいですね。
リアクトサーバーコンポーネントを使ったレンダリングとデータフェッチングの話があって
コンクルージョン、結論が出てきて終わりって感じですね。
明日もちょっとギリギリになるかもしれない気がしますけど。
明日もNext.jsのレイアウトのお話を続き読んでいきたいかなと思っております。
9時半になりましたので、今日はこちらで以上にしたいかなと思います。
ご参加いただいた皆さん、大変にありがとうございました。
明日もゆるりとやっていくので、のんびり参加いただけたら嬉しいなと思っています。
では本日も頑張っていきましょう。おつかれさまです。
