CYDAS Developer's Blog

サイダス技術者ブログ

【イベントレポート】LaravelConf Taiwan 2019 で登壇してきました!

こんにちは!エンジニアの こぶかた@_kobuuukata)です!
7/13(土) に行われた LaravelConf Taiwan 2019 で登壇してきましたのでそのレポートです!

LaravelConf Taiwan とは?

LaravelConf Taiwan は 2017 年にスタートし、今年で 3 回目の開催でした!

https://laravelconf.tw/

今年のテーマは「Magic」で、下記のような発表内容を募集していました。
・サービス開発で Laravel のどのような素敵な機能を使ったか
・他の利用者に知られていない Laravel の機能を紹介したい

募集人数 550 人に対して、530 人 もの参加申し込みがあったようなので、かなり注目されているイベントのようです!

そして、弊社もスポンサーしました!
f:id:aym413:20190718183828p:plain:w500

発表した内容

今回は Laravel のイベントということで、以下 3 つの視点でお話をしてきました!
・弊社のサービスである「banto」でどのような機能を使っているのか
・サービス開発をする上でのチーム運営の工夫
・どうやって Laravel の勉強しているのか

通訳さんがいるとのことで日本語で発表させてもらいました〜
聴講者は 150 人くらいはいたと思います(感謝!)

発表資料はこちら↓


発表の様子はこんな感じでした↓
f:id:aym413:20190718201056j:plain:w400
f:id:aym413:20190718200940j:plain:w400

懇親会

懇親会では、エンジニアのみなさんと交流するだけでなく、ビンゴゲームと Laravel や PHPに関するクイズゲームもやりました!

ビンゴカードには Laravel に関する技術以外にも、スポンサーやスピーカーの名前が書かれていました!
f:id:aym413:20190718210351p:plain:w300

f:id:aym413:20190718210548p:plain:w300

残念ながらビンゴにはなりませんでしたが、とっても楽しかったです^^

Laravel Conf Taiwan 全体の感想

・20代前半〜30代前半くらいの若いエンジニアがたくさん参加していた
・日本語を喋れる人が結構多い(みんな日本のアニメやドラマ、歌が好き)
・通訳は AUXALA というオンラインのストリーミングサービスを使っていた(https://www.auxala.com/
・台北では Laragirls という Laravel の女子会がある
・台北でも勉強会での女性参加は全体の 5% くらい

来年の LaravelConf Taiwan は 2020年7月に開催予定のようです!


発表後、モブプロに関する質問をしてくださった方がいたり、「発表よかったです!」DM で送ってくれた現地の方もいて、とっても嬉しかったです!
また、台湾の方のおもてなしが素晴らしく、空港からの送迎や日本からの参加は 4 名だったにも関わらず通訳を用意してくださったり、イベント翌日も台北を案内してくれたりと今後海外からスピーカーを呼んだりする際には見習わないといけないなと思いました!
台湾最高でした!!また必ず行きます!!!

AWS Summit Tokyo 番外編

こんにちは、たじりん(@ayaka_pespes)です。

AWS Summit Tokyo 2019に参加してきました。 セッション以外にもたくさんの魅力があったので、紹介します。

Deepracerリーグ

Deepracerのリーグが開催されていました。
1位になるとre:Inventに招待されます。
常に100分越えの待ち時間で、大盛況でした。
時間帯によっては160分待ちになっていた時もありました。
ちなみに6/14(金)の東京ディズニーシーで一番混雑していたのは「トイストーリーマニア」だったのですが、最長待ち時間は170分でした。
Deepracerの待ち時間はほぼディズニーですね。

タイムが早かった方にはインタビューもあり、本当のカーレースのようです。
映像でみましたが、本当に早い方はマシンがコースアウトすることなく、スムーズに動いていました。
リーグの上位にはDNP(大日本印刷)の方が並びました。
DNP社では機械学習の教育としてDeepracerを活用しているそうです。
japan.zdnet.com

きっとAWS SUMMITに来ていた多くの方がDNPという会社名を覚えて帰ったことかと思います。
優勝タイムは世界最速だそうで、日本だけでなく、世界に対して宣伝効果があっただろうなと想像しています。

f:id:tajirim4989:20190620213258j:plain
Deepracerリーグに挑む弊社CTO

スポンサーブース

AWS Summitでは様々が会社がスポンサーとなっており、スポンサーとなっている企業がブースを出していました。
ブースを出している会社は受託開発の会社が目立ちました。
ブースをまわっていて感じたことは、すでにAlexaも受託開発でビジネスになってきているということです。
Alexaの受託開発をされている方のお話を詳しく聞けて、参考になることもありました。
会社のノベルティもたくさんもらいましたが、一番嬉しかったのはプリングルスサワークリームオニオンでした。(ちゃんと会社のロゴは入ってました)

認定者ラウンジ

認定者ラウンジに初潜入しました。
はじめに認定者バッジを提示して入るのですが、認定者ノベルティをもらえました。
2日目に入ったのですが、どうやら早く行くとステンレスボトルがもらえたようです。私が行った時には無くなっていました。
認定者ラウンドは会場で使えるwifiとは別のwifiが飛んでいるので、少しだけ快適にネットが使えました。
一番嬉しかったのではコンセントがたくさん設置してあったので、充電ができたことです。

re:MIX

2日目の夜にre:MIXというイベントがありました。
懇親会的なものです。お酒と軽食が提供されていました。
AWSウルトラクイズが開催され、上位3名はre:Inventのチケットがもらえます。
結構いいところまで行きましたが、残念ながら上位3名には残れませんでした。

その他

今回サイレントセッションが4トラックありました。サイレントセッションはスピーカーから音を出さずに、全員がレシーバーにイヤホンをさして聞く形でした。
隣のトラックと壁が無い状態だったので、そう行った形式だったようです。
目の前にいるのにレシーバーで聞くのは同時通訳以外では初めての体験でした。
ただ、サイレントセッションのトラックは全てライブ配信されていたので、家でのんびり見る方が快適だったのかなと思ったりもします。

まとめ

2日目、3日目の参加でしたが、楽しい2日間でした。 学びもあり、刺激になりました。

AWS Summit Tokyo 3日目に参加してきました

こんにちは、たじりん(@ayaka_pespes)です。

AWS Summit Tokyo 2019の3日目に参加してきました。 そのレポートになります。

基調講演

AWSのサービスをテーマごとに紹介していました。
中でも印象に残っているのは機械学習の事例として紹介されていた、SyntheticGestalt社の事例です。
機械学習を用いて人間の代わりにロボットに実験をさせ、創薬に繋げるということをしているそうです。
その機械学習の部分でAWSを用いているとのことでした。
現状、創薬にはコストがかかってしまい、社会保障費を圧迫しているという問題があり、それの解決手段として機械学習を使用されていました。
すごく未来的な話のように感じましたが、根本には課題や問題があり、それの解決手段として機械学習を使っていました。
ついつい、技術にばかり目が行ってしまいますが、技術は手段であることを忘れないでおきたいです。

Amazon DynamoDB Deep Dive

DynamoDBの機能の説明とNoSQLのデータモデリングの話です。

データモデリングについては下記がセッション内で紹介されていました。 aws.amazon.com

www.slideshare.net

DynamoDBのテーブルを設計する場合もER図までは作成することが大事だそうです。

Alexaのスキルを作成するときにDynamoDBを使っていましたが、データモデリングを考えずにDynamoDBを触っていたので、今後は紹介されていたスライドを見ながら、より適切にDynamoDBを使っていこうと思います。

サーバーレスアプリケーションのためのセキュリティアーキテクチャ

サーバーレスでセキュアに構築する方法の話でした。
AWS Well-Architected Frameworkに「Serverless Applications Lens」というドキュメントが公開されており、そこにセキュアなアーキテクチャについても載っています。

以下のような質問をあげ、それに回答していく形で、セキュアなアーキテクチャを紹介していました。

  1. APIアクセス制限をどのようにしていますか?
  2. lambdaファンクションがアクセスできるAWSサービスをどのように保護していますか?
  3. ログをどのように分析していますか?
  4. 依存関係や脆弱性をどのように監視していますか?
  5. lambdaファンクションがアクセスできるVPC内のAWSリソースに対してどのように保護していますか?
  6. サーバーレスアプリケーション内の機微な情報をどうしていますか?
  7. どのように入力値をチェックしていますか?

それぞれ、以下の方法が紹介されていました。

  • 1、2 Cognito、IAM、lambdaAuthorizer
  • 3、4 Cloud Watch Logs、X-Ray
  • 5 WAF、Security Group
  • 6、7 System Manager Parameter Store、Secret Manager

侵入テストでCloudFront、lambdaも申請不要になったというお話もありました。

サーバーレスで作るときもセキュリティを意識して作りたいなと身を引き締めました。 英語ではありますが、サーバーレスなAWSのサービスを使うときは、AWS Well-Architected Frameworkを読みながら使おうと思います。

めざせ!サーバーレスプロフェッショナル

サーバレスで開発をする際の具体的な話でした。

複数環境にデプロイする方法がとても参考になりました。 alexaのスキルを公開していますが、特に開発用環境や評価用環境、本番用環境を分けずに作成してしまっており、今後変更を加えるときにどうしようか考えていました。 SAMで環境変数を用いて複数環境にデプロイできるそうなので、試してみたいと思います。

他にもアーキテクチャのデザインパターンの話をしていましたが、時間がなくなりあまり詳しく聞けなかったです。 後日スライドを公開するとのことなので、公開を楽しみにしておこうと思います。

AWS & Alexa Automotive : worldwide Automotive industry trends

車とalexaのお話でした。 アメリカではすでに車内で使うecho autoが発売されており、車内でalexaを使うということが進んでいます。 車で使うスキルもローンチされており、日本では日産がすでにスキルを公開しているそうです。

またamazon社のとったアンケートから次のようなことがわかったそうです。

  • 家の中で使っているVUIエージェントと車の中で使うVUIエージェントは同一の方がいいと思っている人が76%
  • 車の中で使いたいのはナビゲーション、MUSIC、Driver Warning

現在、alexaは100以上の機器に搭載され、世界で公開されているスキルは80000以上に登るそうです。 AVSを使ったデバイスが今後も増え、利用シーンが増えそうだと感じました。 今後は利用シーンも考えながらスキルを作ったりすると、便利で快適な体験を増やせるのではないかと思っています。

3日目まとめ

技術的なことを多くインプットした1日でした。 私個人としてはサーバーレスをalexaのスキルを作る際に使用しており、すぐにスキルの開発で使えそうなインプットが多くありました。

AWS Summit Tokyo 2日目に参加してきました

こんにちは、たじりん(@ayaka_pespes)です。

AWS Summit Tokyo 2019の2日目に参加してきました。 そのレポートになります。

Serverless/AppSync によるモバイル開発の今

AppSyncとは何か、どういうメリットがあるか、というような内容でした。 AppSyncはGraghQLのマネージドサービスで、セッションを通してGraghQL便利そうだなと思いました。

事例としてグノシーの方が登壇されていました。 以下のような内容を話されていました。

  • グノシースポーツというサービスでAppSyncを使用している
  • リアルタイム更新、スキーマファーストになる、複雑かつnestな構造のデータが取得が可能 といった理由から、AppSyncを選択
  • リアルタイム更新
    • Dynamoに更新があるたびにリアルタイム通知する
  • スキーマファースト
    • GraghQLは先にスキーマを定義し、それに合わせてサーバサイドを実装するため、スキーマファーストとならざるを得ない
  • REST APIだとAPI仕様書が必要だが、API仕様書を記載するコストが高い
  • REST APIだとUIを変更するたびにAPIも修正する必要があったが、GraghQLではそういったことがない
  • バックエンドはUIがデータにアクセスする方法を提供
  • Tips
    • GSI(Dynamo)だけでなく、ElasticSearchも使うと良い
    • lambdaをdatasourceにするときは慎重に(ホットスタート/コールドスタートの問題など)
    • 最適な環境をシュッと作れる

私自身RESTで実装していた時に、API仕様書の記述が面倒・ちょっとした画面の変更でもAPIを直さなければならないことは面倒に感じていました。 GraghQLを使うと、そういった問題が解決できそうです。 今後APIを作成するときはGraghQLも候補に入れて行きたいと思いました。

最後にライブでデモをしていました。 いくつかのコマンドを実行し、少しコードを修正して、簡単にwebサイトが動いていました。

CEO ジム・ローズ来日:CI/CDが変革する開発現場・ビジネスとしてのCircleCIの未来

CircleCIは日本に注力をしているそうです。 日本APAC拡大へのHUBにするといった考えもあり、日本での採用を増やしているそうです。

CD(Continuous Deployment)の話をその後話していていました。 結局本番環境にリリースしてみないとわからないという話でした。 切り戻しが容易にできる、修正がすぐにリリースできれば本番環境にリリースし、問題があればすぐに切り戻したり、修正してリリースすることができます。

開発環境と本番環境の差異やリリース後に仕様が違うと言われることはあると思います。 本番にリリースした後、大丈夫かなとよく不安になります。 しかし、修正してすぐにリリースができれば、リリースのハードルが下がります。 CI/CDちゃんとやりたいなと改めて思いました。

Amazon Alexa音声インターフェースへの新しい挑戦。スマートホームを実現するAWS IoT

スマートホームの話です。 しかし、スマートホームの話だけでなく、使われるスキルを作るヒントを得ることができました。

赤外線リモコンを発売されているラトックシステム様が事例として登場されていました。 以下のようなお話をされていました。

  • AWS IoTを使った赤外線リモコンを発売している
  • スマートホームAPI
    • APIがサポートするデバイスと機能のみ
    • 発話がプリセットされている
    • スキルの呼び出し名不要
    • アカウントリンク必要
  • Alexaで赤外線リモコンを操作するとき
    • Echo → skill → lambda → AWS IoT Core → 赤外線リモコン
  • スマホリモコンから赤外線リモコンを操作するとき
    • スマホアプリ → AWS IoT Core → 赤外線リモコン
  • カスタムスキル
    • 発話を覚えられない
    • 発話が複雑になりがち
    • スキル名を言う必要がある
  • スマートホームスキル
    • 発話がシンプル
    • 発話が統一されている

alexaに対応している赤外線リモコンが10万ユーザーに登り、大ヒット商品となったそうです。 また、作成したスキルは作成したdeveloper以外の人にテストしてもらうのが大事だそうです。 シンプルな発話は大事だと言われてはっとしました。 ついつい、なんでもできる方がいいと思いがちですが、使いやすいのはシンプルなものだったりします。 特に音声で操作するときは一度に提示できる情報が多くないので、いかにシンプルにするかは、かなり重要だなと思いました。

2日目まとめ

他にも2日目にはre:MIXというイベントがありました。 AWSウルトラクイズで上位3名はre:Inventにいけるという特典がありました。 クイズは初心者から上級者まで楽しめて、想像以上に楽しかったです。 セッションやイベントなど、内容が濃く新しい知識を得られた1日でした。

サイダス技術部に5月からジョインしました、たじりんです

初めまして、たじりん(@ayaka_pespes)です。 5月からサイダスにジョインしました。 ちょうど1ヶ月が経ったので、入社エントリーを書きます。

入社までの経緯

2019/2/23にJAWS DAYSに参加したことがきっかけでした。 以前にもサイダスの方がイベントで登壇されているのを拝見して興味を持っていました。

JAWS DAYSの二次会で酔っ払って騒いで転職したいという話をしていたところ、CTOの吉田さんから、サイダスを受けてみないかというお話をしていただきました。 それがきっかけになり、wantedlyから応募をして、ジョインさせていただくことになりました。

入社してよかったこと

  • 1on1やOKRを積極的に行っている
    定期的にCTOとの1on1があります。 1on1を通して、自身のキャリアや今後の目標を改めて考えることができました。 1on1ではOKRの話もします。目標を設定し、共有します。 やはり目標がある方が具体的なアクションをしやすくなると思いました。

  • コミュニティ活動をやりやすい
    サイダスはコミュニティや勉強会などへの参加を推奨しています。 特に登壇は機会があるなら、積極的に登壇することを良しとしています。 私以外にもイベントを開催したり、社外で登壇するような人が多数おり、気持ち的にとても動きやすくなりました。 また、イベントをやる、登壇するという時に応援してもらえるので、前よりも積極的に動けるようになりました。

  • モブワークでコミュニケーションを取りやすい
    私は今チームで開発を行っており、常にzoomをつないだ状態で仕事をしています。 雑談も交えながら、すぐに質問ができ、とてもコミュニケーションを取りやすいです。 まだ、入社して1ヶ月ですが、社内でもくもく会したいと言った時にも参加してくれる人がたくさんいました。 よかったら一緒に勉強しましょうと言いやすい雰囲気だったからこそ、もくもく会もできたと思っています。

  • 会社がおしゃれ
    沖縄本社はとても綺麗です。カフェみたいです。 今はマンスリーマンションに住んでいるのですが、マンスリーよりも会社が好きで、土日も会社にいることが増えました。

入社後のギャップ

  • 日本人以外の方も結構いる
    良いギャップです。 入社前は日本人ばかりかと思っていましたが、日本人以外の人も複数名います。 またこの後も何名か外国の方が増えるようです。 基本は日本語でコミュニケーションをとりますが、私も英語喋れた方がいいと思うようになりました。 基本的にどの国の方でも日本語は厳しいけど、英語はOKという方が多いので、私が英語を喋れることで、コミュニケーションがもっと円滑に取れるのではないかと考えています。

  • 技術部以外の方との交流が少ない
    技術部以外の方はフロアが分かれているため、あまり交流がありません。 一ヶ月に一回納会と言う名の飲み会があり、そこでは交流の機会があります。 しかし、人見知りを発揮してしまい、あまり交流ができなかったので、後悔しています。

そんな感じで1ヶ月が過ぎました。 もっとインプットとアウトプットを増やしていきたいと思っています。 本を読む、勉強会に行くと言ったようなインプットを増やし、ブログや登壇等でアウトプットしたいと思っています。
とても居心地よく感じているので、会社に対してもっと貢献できることを増やしたいです。 またこの技術ブログにも今後登場すると思うので、よろしくお願いします!

Introduction to installable feature of PWA

This article will introduce PWA installable feature which makes web app looks like a native app.

What is a Progressive Web Apps

PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features

There are some key principles a web app should try to observe to be identified as a PWA. It should be:

  • Discoverable: so the contents can be found through search engines.
  • Installable: so it's available on the device's home screen
  • Linkable: so you can share it by simply sending a URL
  • Network independent: so it works offline or with a poor network connection
  • Progressive: so it's still usable on a basic level on old browsers, but fully-functional on the latest ones.
  • Re-engageable: so it's able to send notifications whenever there's new content available
  • Responsive, so it's usable on any device with a screen and a browser -- mobile phones, tablets, laptops, TVs, fridges, etc
  • Safe: so the connection between you an the app is secured against any third parties trying to get access to your sensitive data.

In this article, We just focus on the Installable feature.

Install a PWA web app

The demo web app is here: https://tsq-blog-demo.github.io/coinmarket . It's a SPA and built with Vue.js.

We will use Chrome on Mac, Windows, Android and use Safari on iPhone.

Installation on Mac

mac

Installation on Windows

windows

Installation on iPhone

iPhone

Installation on android

android

How make a website installable

To make the website installable, it needs the following things in place:

  • A web manifest, with the correct fields filled in
  • The website to be served from a secure(HTTPS) domain
  • An icon to represent the app on the device

The key element is a web manifest file, which lists all the information about the website in a JSON.

We can create a file named manifest.json. It should be included in the <head> section of the index.html file via the following line of code:

<link rel="manifest" href="manifest.json">

The content of the file looks like this:

{
  "name": "COINMARKET",
  "short_name": "COINMARKET",
  "description": "An App that displays the mark cap rankings, price, details and more for the top 100 larget crytocurrencies based on overall market cap.",
  "icons": [
    {
      "src": "./img/icons/android-chrome-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "./img/icons/android-chrome-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "start_url": "./index.html",
  "display": "standalone",
  "background_color": "#fff",
  "theme_color": "#00d1b2"
}

let's break down the document and explain them in detail:

  • name: The full name of your webapp
  • short_name: Short name to be shown on the home screen
  • description: A sentence or two explaining what your app does
  • icons: A bunch of icon information, source URLs, sizes and types. Be sure to include at least a few, so that one that files best will be chosen for the user's device.
  • start_url: The index document to launch when starting the app
  • display: How the app is displayed: can be fullscreen, shandalone, minimal-ui, or browser
  • background_color: A color for background, used during install and on the splash screen
  • theme_color: A primary color for the UI, used by operating system

The bare minimum requirement for a web manifest is name and at least one icon (with src, size and type). The description, short_name and start_url and recommended.

Summary

Installable is a very cool feature which makes your website look like a native app. Even though, it's not supportted by all browsers now, I think it will become more and more popular in the future.

If you want to learn more about PWA, the MDN web docs is a good place.

VuexとAtomic Design

f:id:kfukuyama:20190522213224p:plain

大阪からこんにちは、福山健@kenfdev)です。

フロントエンドに関わっているエンジニアであればAtomic Designというのを聞いたことがあるかもしれません。

フロントエンドの開発をしていく上で大事なことの一つに、画面の部品をどのようにComponentに分割していくかというものがあります。

きっとたくさんのフロントエンドエンジニアがこの点については毎回悩まれると思います。

そこで、どのように分割していくと良いかという指標の一つとしてAtomic Designという考え方があると僕は解釈しています。

Atomic DesignはBrad Frostさんという方が提唱したもので、英語であれば下記にて公開されていますし、本を注文することもできます。

atomicdesign.bradfrost.com

また、日本では下の書籍がReactを使って具体的にわかりやすく説明されています。(ただし、SPAフレームワークを触ったことが無いとちょっとつらいかも)

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

この記事ではAtomic Designについては詳しく見ないので、そもそもAtomic Designについて知りたい方は上の書籍や、わかりやすいブログ記事も多数あるのでそれらを先に読むことをおすすめします!

ではこの記事で何を述べるかと言うと、Vue.jsのVuexを使ったプロジェクトでAtomic Designを採用した場合に、VuexのStoreとAtomic DesignのComponentがどのようにやり取りすると良いかを紹介します。

あくまでこのやり方は1例に過ぎず、やり方は多数ありますので迷っている方の参考になればと思います!(CYDASでもやり方は日々アップデートしています!)

Atomic DesignとVuexで何に迷うのか

これは「Atomic Designだから」、という問題では無いのですが「誰がVuexを意識するのか?」という課題が常につきまとってきます。

具体的には:

  • 誰がVuex StoreからStateを受け取ることができるのか
  • 誰がVuex StoreにActionをdispatchしていいのか

という2点がポイントになってきます。ここに一定のルールを設けないと、そこら中からStateを受け取ったり、そこら中からActionをdispatchしたりしてどこで何が起きているのかかなり追いづらくなってしまいます。

イメージとしては下図のような状況です。

f:id:kfukuyama:20190521072408p:plain
フローが追いにくい関係

「Pages, Templates, OrganismsはPropsを受け取ることもあれば、Storeからstateを受け取ることもあり、eventを$emitすることもあればStoreにdispatchすることもある。」のがわかります。

これでは流れが追いにくかったり、実装するときも迷いが生じやすくなります。

Atomic DesignとVuexの良い関係

そこで、僕が今のところ良いと思っているAtomic DesignとVuexの関係は下図のようになります。

f:id:kfukuyama:20190521091719p:plain
追いやすくしたフロー

言語化すると、

  • Storeからstateを受け取るのはPagesのみ
  • Pages以外はPropsでしか入力を受け付けない
  • Storeにdispatchして良いのはPagesとTemplatesのみ
  • Pages, Templates以外はdispatchしてはいけない(イベントは$emitするのみ)

というルールになります。

StoreはPagesのみが意識すべきでは?

ここで出てきそうなのが「StoreはPagesのみが意識すべき」という意見です。

ルールとしてはわかりやすいんですけど、実際にやってみるとTemplates→Pagesにeventを$emitして、PagesからStoreにdispatchするのが冗長に思いました。

f:id:kfukuyama:20190522192314p:plain
Templates→Pagesのコピペ感がつらい

Templates→Pagesへの$emitが増えるほどPagesでもイベントハンドラが増えてしまうのです。。。(やり方はいくつかあるにせよ冗長さは避けられないと思います)

そういうわけでCYDASでは「dispatchに関してはTemplatesからやってもいいのでは?」という意見もあってTemplatesまではStoreを意識して良いルールにしています。

Pagesはいつdispatchする?

Templatesがdispatchするなら、むしろPagesはいつdispatchするのか?という疑問も出てくると思います。

基本的にOrganismsより下の層から$emitされたイベントについてはTemplatesからStoreにdispatchします。

なので、Pagesがdispatchするタイミングはmountedなどの、ページ初期化時などのタイミングくらいしか無いのかなと思っています。

TemplatesにPropsは必要なのか?

Templatesからdispatchができるなら、いっそのことstateもStoreから持ってこればいいのでは?という疑問も出てきます。

それをやってしまうともはやPagesが必要なくなると思うのですが、あくまでデータはProps経由でもらうというルールにしています。

というのも、Atomic Design(にこれも限らずですが)とStorybookを組み合わせて使うことも多いかと思います。

storybook.js.org

このStorybook上でTemplatesを表現する際に、Propsで制御できたほうがVuexのセットアップ(gettersだったりstateだったり)が必要なくなります。

標準のVue.jsで、Propsにデータを差し込むだけでいろいろなデータを流し込めるので、変に手間のかかることをせずに済むと思っています。

そういったわけで、TemplatesはPropsでデータを受け取るようにしています。

まとめ

この記事で述べているやり方はあくまで1例にすぎません!大事なのは皆が好き勝手違う書き方をしてしまわないようにルール(コーディング規約)をある程度決めておくことだと思います。

そしてやってみて、フィットしなかったらもっと良いと思う方法に変えていけば良いんだと思います(手戻りは発生してしまうのは覚悟の上で)!

参考