Edited at

YYTypeScript#8「セミコロンは省略すべき?」「Vueと一緒にTSも導入すべき?」「Vueテンプレートの型、みんなどうやってる?」「TSの罠にハマった体験談と対策」「Composition APIについて聞きたい」「default exportは避けるべき?」「TypeScriptのバージョンアップのタイミングはいつ?」「TS+Vue+Electronって大丈夫?」「TSX+Vueなら、Reactで良くない?」

これは2019年11月8日に開催したTypeScriptイベントYYTypeScript#8のイベントレポートです。

YYTypeScriptは一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆるく・ワイワイ話しながらTypeScripter同士の交流を深める「双方向的な座談会」の形式になります。集まった人たちで「今日話たいこと」「聞きたいこと」をいくつか挙げていき、それをテーマに雑談していきます。

今回の配信動画

過去回の配信動画YouTubeプレイリスト「YYTypeScript」

前回YYTypeScript#7「他の言語からTSに来てみての感想は?」「チームにTSをどう導入していったか?」「フロント開発環境、Docker使ってる?」「TS開発時の鉄板構成は何?」「Reactのクラスコンポーネントとファンクショナルコンポーネントどう違う?」「フロントエンドで採用すべき、おすすめアーキテクチャ」 - Qiita


雑談


セミコロンは省略すべき?

意見を聞きたい。

・・・


  • JSとTSで事情が異なるのでは?

  • JSはつたほうがいい、TSは付けなくていいと思っている。

  • JSはセミコロンを付けないと落とし穴がいくつかある

return

{
// オブジェクトリテラル
}

即時関数はハマる

(() => ())(); // セミコロンがないとだめ 

doSomething()

hoge()

(() => { /* */ })()


Vueと一緒にTSも導入すべき?

最近、(たぶん、フロントエンドフレームワーク経験なしの)会社でVueを入れよう、勉強していこうという話が出てきた。

それにTSも入れるべきか?

・・・


  • デメリットはない?

  • 学習コストがある?

  • ゆるい型もあるからおすすめしちゃってもいいかな。

  • TSを導入するデメリットは最初の導入コストだけな気がする。lintを弱めればJS likeでも書けるので。

  • 型だけ導入するってのもあり??

  • こだわり過ぎなければ大丈夫。

  • 凝りすぎると時間が溶けるかも。

  • とりあえずおすすめしようとおもう!かんしゃ!


Vueテンプレートの型、みんなどうやってる?

以前話題にでた、クラスで書くか関数で書くか問題のときに、デコレータを使うとクラス構文で書くと思うが、わざわざデコレータを使うためにクラス構文を使うのか?

wonderful-panda/vue-tsx-support: TSX (JSX for TypeScript) support library for Vue

こういうのもあるので、実際どうやって型を指定しているのか聞きたい。

・・・


  • 自分はTSX使って無いです。


    • テンプレートの型は諦めてます。

    • TSXを使うと、それだったらReactで良くない?という気持ちになるので……

    • VueのHTMLとCSSとJSを分けて書いていく世界観が好きなのでTSXは好きじゃないです。

    • オブジェクトを掘り下げて参照することがあれば、getterなどで定義しておく。


      • テンプレートには変数名だけ参照するようなシンプルなものにする工夫をしている。





  • 自分もTSXを使ってないです。


    • かたしんさんのvuterの実験機能を、半年前に試した。

    • クラスの書き方が限定されるらしくて、もしかしたら使えないプロジェクトがあるかも?

    • テンプレートの型解釈部分も完璧でない記憶があった。

    • 補助くらいの気持ちで使っていけばいいんじゃないかなと。



  • テンプレートの中で型チェックが必要になるような書き方は避けて、型ないと心配な部分はscriptのほうに書くようにする


    • 一応 prop の部分はチェックしてもらえるので。



  • デコレータ+クラス構文

  • Vue.extendとデコレータどっちも使ってます。


TSの罠にハマった体験談と対策を聞きたい

例えば、抽象クラスからそのサブクラスを参照するとTSが死ぬ。

interface XxxSpecification {

and(other: XxxSpecficition): XxxSpecifition
}
abstract class AbsXxxSpecification implements XxxSpecification {
and(other: XxxSpecficition): XxxSpecification {
return new XxxAndSpecification()
}
}

class XxxAndSpecification extends AbsXxxSpecification { }

// 最終的には関数化
function and(...specs: XxxSpecification[]): XxxSpecification {
/**/
}


  • コンパイルは通るし、エディタも問題ない

  • トランスパイル後、実行するとエラーになる。

・・・

継承で同じ変数を宣言できないところ、トランスコンパイル後に一つのクラスになるから同じ変数名を宣言していることになる。

// 確かこんな感じだった。関数だったかな??(くろれ)

abstract class AbsHoge {
abc:string;
}

class Hoge extends AbsHoge {
abc:number; // ←エラーになる。JSに展開したときに重複した変数となってしまう。

hoge(){
// Javaならこうやって使用できる。
console.log(this.abc); // number型
console.log(super.abc); // string型
}
}


  • Javaだとsuper.abcで参照できる。

・・・

interface FooInterface {

get(fieldName: string): void
}

class Foo implements FooInterface {
get(fieldName: 'a'): void { // ←コンパイルエラーにならない!

}
}


Composition APIについて聞きたい

Vueの新しい機能。Reactのhook相当なもの。今もプラグインとして入れることができるらしい。使ったことある人がいたら聞きたい。

・・・

会場には使ったことある人、試したことある人がいなかった。


Static TypeScriptについて見てみよう

・・・


STSでは、withやeval、プロトタイプベースの継承、argumentsキーワード、あるいは.applyメソッドなど、JavaScriptの最も動的な機能が削除されている。thisポインタとnew構文は、クラス外や非クラス型では使用できない。ジェネレータやawait、async function式、あるいはファイルベースのモジュールなど、最近になってJavaScript言語に追加された機能も実装していない。


・・・


default exportはしないほうがいい?

・・・


  • googleのTSのコーディング規約で上記内容に触れていた気がします


    • 実務では default export はIDEの補完との相性が良くないと感じ使っていません



  • みんなどう思ってます?

  • export defaultはimport先で任意に名前がつけ直されてしまって、grepに引っかからなくなる。

  • IntelliJだとexport defaultだと補完がきかない


    • VS Codeだと大丈夫



  • default exportはnpmのモジュール先で使われてるだけで、自分のコードでは書かないですね。

  • index.d.tsをつくれば参照できるのかな?2度手間??

  • export defaultのメリットが思いつかなかった。

  • export = nanika も駄目ですよね?


    • 最近あんまり見ない気が……

    • library 作るなら export default 考慮するのかも?と思う所はあるけど普段は使わないですね

    • Reactがもろにexport = React;




  • # CommonJS と ES6の import/export で迷うなら - Qiita



    • export = はcommonjsの名残?




TypeScriptのバージョンアップ、どのタイミングでやってる?


  • FWがTypeScriptのバージョンを指定してたら。開発中の場合はバージョンを上げない。新規だと最新。

  • 個人だと出たタイミング

  • 会社でも上げていったほうがいいと思う。

  • すぐ上げれるようにする仕組みがあったほうがいいと思う。

  • 一回追いつけなくなると、もう追いつけなくなりそう。

  • TS後方互換ってどうなってるの?


    • 一応セマンティックバージョニングなのでは?



  • 基本後方互換性のある対応だと思っているので、公私問わずあげますね


    • 上げてなにかwarningが出ていれば(またはテストがこけるなら)対応。対応しきれなければ戻す。がいつもの流れですね



  • TS「セマンティックバージョニングには従わない」


    • でも、stable releaseである限り、互換性はある。



  • テストとかってどうしてます?


    • フロントでもロジックにまつわる部分はテスト書きます。

    • 画面表示の部分は変わりやすいので、テスト書いてない。



  • たまにver-upの影響をanyで回避しちゃうことある

  • 3.5にあげるときに、オブジェクトの型の取り扱いが変わったようだったので、コンパイルしてみてエラーになっている部分を直して、テストが壊れていないのを確認して、開発環境に上げた。


    • 重要なところやややこしいっところは画面のテストで触って確認した。



  • Angularだと、Angularのバージョンを上げるためにTSのバージョンも上げないといけない


Electronで何か作りたいけど TS+Vue+Electron で大丈夫?


  • 作りたいもの → 10画面ぐらいのツール、OSS化したい

  • 知りたいこと → 相性とか

  • ビッグバン気味


    • ビッグバンとは…w


      • ビッグバン・アプローチ → いっぺんに色々導入すること

      • ブラックホール・アプローチ





・・・


  • 最近ElectronがApp Storeで公開できなくなった。


    • Electronがprivate APIを使っているため。

    • 解決の目処が立ってないらしい?



  • Electron + Vueは問題なかった。

  • 気になるのはElectronのAPIの型がちゃんとしているかどうか。


    • 公式でちゃんとサポートされている



  • では、electron以外でウェブ知識でネイティブ作れる選択肢ってないんでしょうか・・・


    • React Nativeはデスクトップでは動かない?

    • Flutter!

    • Cordovaどうなった?


      • いけるかもしれないけど分からない



    • nwjs



  • electron でAppStoreは使わないが情報多くて無難ですかね?


    • いまは、つかえないけど今後対応するかもー、ですね。




Vue3.0でTSXを正式にサポートするそうですがそうなってくるとReactと書き方そんな変わんないんじゃという気もするのですが、それでもVue使ったりするのってエコシステムが充実してるとかなんですかね。。。


  • Vueはデザイナーと相性がいいと聞く

  • TSXまでいくとVueって何だっけなる

  • TSXとSFCを組み合わせてもいいわけで

  • Vueの良さを生かして書くのがいいかなと

  • Reactの人はデザイナーさんとの相性どう考えてるの?


    • デザイナーさんに教えるしかない


      • コーダーに近い



    • コード化までしないで、コード化はフロントエンドエンジニアがやるとか?



  • ReactとVueってどういう使い分け?


    • 大規模で複雑さが多いのはReact, そうでないのはVueがいいよねってのは言われる



  • アトミックデザイン


    • 出発地がグラフィックデザインなので、複雑さを解決するためのモジュール化に必ずしも向いているわけではない。



  • オブジェクトベースなUIデザイン|Yoko Nishida|note


開始前の雑談


  • サーバ障害のときの電話の着信音


    • ポケモンとかドラクエの戦闘BGMにしたほうが、緊迫感出るのでは?

    • Evaの使徒襲来もいいかも。

    • あんまり曲がガチすぎるとストレスになるかもw


      • 曲が嫌いになりそうですねw






参加してよかったこと(参加者の感想)


  • 毎回、有益な情報を得られてます!

  • 新しいTSの知識を手に入れられる。しかもそれはちゃんと業務で使っている人たちの知識であるというのがよい

  • 自分が思っていた疑問が解決したこと

  • youtubeの遅延が少なかったこと

  • STS知らなかったので、ここで知ることができて良かったです

  • コンポーネントの作り方や作る時の考え方等、お話したりお話聞けたりしたのが嬉しかった + 楽しかったです


YYTypeScriptは毎週やってます

YYTypeScriptについてワイワイ話したい方は、YYTypeScriptのイベント情報をチェックしてみて下さい。

以上、YYTypeScriptのレポートでした。次回もワイワイやっていきたいと思います! では、また来週!