ライブビューイングできる勉強会があるようなので、初勉強会だけど参加してみた(´ω｀)
いつもスライドだけ見てたけど、ライブ感すごい。。次は現地にいきたい。。
Roppongi.vueのふんいき
はじまってます〜 #roppongi_vue pic.twitter.com/rT4NXg6cer
— める (@c5meru) May 27, 2019
登壇者からはこんな感じに見えます #roppongi_vue pic.twitter.com/VnWilcv4S9
— める (@c5meru) May 27, 2019
Roppongi.vueのロゴとビジュアルのデザインをしました！テック感よりおしゃれ感を強めにしました。なぜなら六本木はおしゃれな人がおおいし、おしゃれなものがおおいからです。（浅い）イベントに参加した皆さんの気持ちがアガるお手伝いができたら幸いです🙌#roppongi_vuehttps://t.co/9VxE2prRUA pic.twitter.com/r0UbVH54YT
— 風樹/Fuki (@fukiworks) May 13, 2019
わあい、ステッカーだ！
— める (@c5meru) May 27, 2019
今日のハッシュタグはこちらです！ #roppongi_vue pic.twitter.com/GXCh1SmvXz
ケータリングやべえ #roppongi_vue pic.twitter.com/hXL6MJc4Fo
— める (@c5meru) May 27, 2019
豪華すぎる…#roppongi_vue pic.twitter.com/2k5FKXpcPO
— ワツヨ@Nuxt×TypeScript (@watsuyo_2) May 27, 2019
始まる #roppongi_vue pic.twitter.com/hgZZoOX2oC
— 水月 涼 (@mizuki_r) May 27, 2019
懇親会は〜じま〜るよ〜！#roppongi_vue pic.twitter.com/h2iJ2D0BBv
— 風樹/Fuki (@fukiworks) May 27, 2019
リモートだけど、たのしそう。。おいしそう。。がすごく伝わる。。
LT1 Go Tadanoさん: JavaScriptで実装したVueJS プロジェクトをTypeScriptへ移行する話
スライドとか
スライド: (見つけられなかったので、見つけたら更新する予定。。)
かんそうぶん
TS移行の話。VueJSアプリをVueCLIと使ってどう置き換えていくかの話。
普段はNuxtなので、VueCLIってどんなものかわからなかったので新鮮(´ω｀)
TS化ってモジュールを入れた後に、なにするかがわからないので、
こういうのは、ありがたい知見。。
Vueクラスの話だけじゃなく、JSXやTypeScriptに入門したときのメリデメもあり、
これからTypeScriptをはじめるひと/少しずつ始めるときによいスライド♪
実プロダクトだと一気にはできないので、ある程度、手順化できるところ、
型を整備していくような少しずつ整えていくとことかもありそう。。
VUE CLIでTypeScriptモジュールを追加できるのか。。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
Nuxtばかりだからしらなかった。。#roppongi_vue
型を書かなくてもいいってのは、
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
型推論の話のだろうか(・・?
一部の方を付けておけば、推論して型が決まっていく的な。https://t.co/QGv0jV6JVG#roppongi_vue
TSのanyの話、移行ってことだとそこからな気がする。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
一気に全部はできないので、部分的にやってる必要があるなぁ。。
型はその過程で揃えていく感じになるのかな。。#roppongi_vue
LT2 サトウジョンさん: propsについて考える
スライドとか
Twitter: @SatohJohn
スライド: propsについて考える - Google スライド
かんそうぶん
設計の話。。propsとはなにかを設計の観点から考える話。
propsの使い方からはじまるので、初級者に優しい内容(´ω｀)
前半は、propsとはどんなものか、どういう種類があるのか、
引数とpropsの関係が、わかりやすく説明されていて、すてきだった。。
後半は、設計の観点からpropsとはなにか、どう使うとよいかの話。
propsを定義することで、コンポーネントのインターフェースを定義でき、
Require/Type/Validatorを利用することで、受け取る値の説明を加えれる。
OOPでいうところの、propsはinterfaceであり、
それを使うコンポーネントはそのインターフェースの実装ぽい感じ。
このLTに関してはリプにも良い話も多く、
設計談義っぽくなっておもしろかった(´ω｀)
私のとこでもpropsはちゃんと定義するようにしてる。
— plum (@plum_eule) May 27, 2019
コンポーネント分割するとやっぱり必須だなと。
#roppongi_vue
コンポーネントでstoreの値を使うと、使い回せなくなるから微妙だなと。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
storeの値は、pageレベルだけが自然な気がするけどどうなんだろ(・・?#roppongi_vue
コンポーネントの機能として定義できるならpropsとしてルールを明示すべきだけど、サービスグローバルな（あるいはコンポーネントの責務範囲を超える）ルールを持ち込むのは避けるように考えてる #roppongi_vue
— 水月 涼 (@mizuki_r) May 27, 2019
storeの参照についてはpages/container-componentくらいまでにしてますねー。コンテキストを持つべきコンポーネントかどうかでみるとだいたいそれくらいの粒度になる感 #roppongi_vue
— 水月 涼 (@mizuki_r) May 27, 2019
コンポーネントの機能として定義できるならpropsとしてルールを明示すべきだけど、サービスグローバルな（あるいはコンポーネントの責務範囲を超える）ルールを持ち込むのは避けるように考えてる #roppongi_vue
— 水月 涼 (@mizuki_r) May 27, 2019
子コンポーネントには極力propsで渡していきたいけど、階層深くなるとなかなかにしんどくなる時はある。
— シマムラ🥃 (@shimamura1111) May 27, 2019
#roppongi_vue
規模の問題かもしれないけど、あまりcomponentのバケツリレーで困ったことないんだよな... 面倒くさいってのはあるけど、コンポーネントの機能単位で考えるとあまりバケツリレーしてる感ない #roppongi_vue
— 水月 涼 (@mizuki_r) May 27, 2019
storeの分割方法/基準も悩むけど、componentの分割方法/基準も悩む。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
最初はべた書きで、2回以上書く必要が出たら分割とかでもでもいいのかな(・・?
チーム開発だとコードレビュー時に相談/すり合わせするとか(・・?#roppongi_vue
emit vs store は2階層以上の emit 発生したら、 store でそのコンポーネントの名前空間切って ... というような指針にすることが多いかなあ。#roppongi_vue
— \\ uto-usui // (@uto_ao) May 27, 2019
コンポーネントごとのつながりはemitで
— ハリネズミ＠改めて駆け出してみた (@shunsuke_hys) May 27, 2019
コンポーネントごとはstoredeすると管理が楽#roppongi_vue
設計の話は、いいなぁ(*´ω｀*)
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
いろんな背景や条件の話も聞けて、おもしろい(*´ω｀*)#roppongi_vue
LT3 kahirokunnさん: SSRの話
スライドとか
Twitter: @kahirokunn
スライド: SSRの話
かんそうぶん
ディープな話。。SSRの中身を紐解く話。。
デモを交えて、SSRがどういうものかという、わかりやすい説明(´ω｀)
普段はNuxtを使っている＆そこまで入り組んだことをしていないので、
あまり気にしていない部分だったけど、
こういう技術で構成されているのか！という感じで、深い話だった。。
なんとなく使えているけど、どう動いているかが、
透けて見えるくらいの知識は必要だなと。。
Storeは単一状態木という見解もおもしろいし、わかりやすいかった。。
サーバのときの状態をクライアント側で復元するために、
単一状態木を受け渡しするという考え方なのか。。と。
話の流れもデモもわかりやすくて、すごくよかった(´ω｀)
Vuexは単一状態木#roppongi_vue
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
課題
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
サーバからフロントにコンポーネントの状態を正しく復元する必要がある。
→ 単一状態木(store)が役立つ
なるほど。。#roppongi_vue
ハイドレーション...
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
vue-ssrのドキュメントにもあった。。
しらなかった。。https://t.co/hrl6h9QK8C#roppongi_vue
LT4 果物リンさん: Nuxt(SPA)でもOGPしたい
スライドとか
Twitter: @FruitRiin
スライド: Nuxt(SPA)でもOGPしたい - Speaker Deck
かんそうぶん
黒魔術の話。。というか、現場感が強い話。。
SPAモードで作成済みのNuxtアプリで、OPG対応を求められるも、
SPA前提の実装のため、Universalモードで動かないときの対処法。
nuxt startでサーバ起動するのではなく、
node app.jsを呼び出して、生成したHTMLを改ざんする。
正攻法はUniversal+SSRで書き直すだけれども、
移行コスト+検証コストを踏まえると、良い方法だと思う。
負債は残るが、ニーズには答えられる感じ。
デメリットの話やまとめでも書いてあるけど、
「Universalモードでできるなら本当にそのほうがいい」
「要件に合わせてSPAモードで開発を進めていいか今一度考えよう」
大事。
今後の要件でも出てこないのか。
リスクが有ることをちゃんと理解して進めているのか。
ってのは、いつだって大事。。
スライドも見やすくて、話も軽快なので、楽しかった！
さすが大トリ！という感じ(´ω｀)
でも、これは新しい技術を早く取り入れたときのぶつかるよくある話な気がする。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
それを、コスト見合いを含め、カバーできる手法と実装できるのはすごい#roppongi_vue
おわりに
ライブビューイングなので、参加できた感ある。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
すごいよかった。。
次もあったり参加したい。。(*´ω｀*)#roppongi_vue
はじめての勉強会だったけど、すごいよかった。。
— きらぷか@i18n補助ツール『トランスノート』開発者&自由業 (@kira_puka) May 27, 2019
あまり外に出ないからあれだけど、
ライブビューイングでこれだけだったら、
現地に行くともっといいんだろうな。。
機会があったら、いろいろ行ってみようっと。#roppongi_vue
ライブビューイングだと、会場の準備だけじゃなく、機材の設置とか配信もあり、
普通の勉強会よりも大変なのに、すごくスムーズに対応されててすごいし、ありがたかった。。｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡
広告とかもあって、開催者にちゃんと還元されつつ、ライブビューイングがもっと普及するといいなと！
ひきこもりだけど、ライブビューイング見たおかげで、
「勉強会っておもしろそうなところだな。。」
「次はいってみたいな。。」
「ちょっと外に出てみようかな？」
とおもいました！
Roppongi.vueがすてきだったのもあるけど(´ω｀)
みなさま、ありがとうございました！
いろんな勉強会、ちょっと参加してしようかな。。
