これは2019年11月8日に開催したTypeScriptイベントYYTypeScript#8のイベントレポートです。
YYTypeScriptは一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆるく・ワイワイ話しながらTypeScripter同士の交流を深める「双方向的な座談会」の形式になります。集まった人たちで「今日話たいこと」「聞きたいこと」をいくつか挙げていき、それをテーマに雑談していきます。
今回の配信動画
YYTypeScript #8 の配信の収録画像をアップしました!https://t.co/LTJkmfxAkO
— suin❄️Terraformエンジニア募集中 (固定ツイ参照) (@suin) November 8, 2019
過去回の配信動画 → YouTubeプレイリスト「YYTypeScript」
前回 → YYTypeScript#7「他の言語からTSに来てみての感想は?」「チームにTSをどう導入していったか?」「フロント開発環境、Docker使ってる?」「TS開発時の鉄板構成は何?」「Reactのクラスコンポーネントとファンクショナルコンポーネントどう違う?」「フロントエンドで採用すべき、おすすめアーキテクチャ」 - Qiita
雑談
セミコロンは省略すべき?
意見を聞きたい。
・・・
- JSとTSで事情が異なるのでは?
- JSはつたほうがいい、TSは付けなくていいと思っている。
- JSはセミコロンを付けないと落とし穴がいくつかある
return
{
// オブジェクトリテラル
}
即時関数はハマる
(() => ())(); // セミコロンがないとだめ
doSomething()
hoge()
(() => { /* */ })()
- JSは書かないと怖い
- TSでも似たような現象がある
- いちいち気にするなら、セミコロン全部付ける派
- prettierに任せる派
- 必要なところはかってにいれてくれ
- セミコロン付ける派は63%
- 基本的にセミコロン入れたほうが無難
- セミコロン推論に自信がないチームは入れたほうがいいと思う
- 本の虫: JavaScriptの自動セミコロン挿入
-
JavaScriptの行末セミコロンは省略すべきか | blog.tai2.net
- Hacker Newsでのアンケート では、90%がセミコロンを付ける派でした。
- JavaScriptの話なのでTSとはちょっと話が違うかもしれません。あと記事が古い
- Vueってセミコロン省略が多くないですか?
- Microsoftが作っているVS Codeのソースコードはセミコロンついてた。
- Angularもセミコロンつける派。
- 他は?
- 付ける: deno, @types, nest
- 付けない: vue-next, nuxt
- IntelliJのデフォルトもセミコロン付ける派
- 結論、迷ったらつけろで良い気がする。
- チームの負荷を下げるという意味では、つけちゃうほうがいいかも?
- ECMA262によると、付けるのを推奨しているとのこと
- Evan You (Vue作った人)のセミコロンの見解
-
「Turns out semicolon-less style is easier and safer in TS because most gotcha edge cases are type invalid as well.」 / Twitter
- TSではセミコロンなしのスタイルがより簡単で安全になったよね、ということ?
- 「Re semicolons: ASI can bite whether you use semicolons or not. Either learn the rules of ASI, or use a linter that guards you against unwanted behavior.」 / Twitter
-
「Turns out semicolon-less style is easier and safer in TS because most gotcha edge cases are type invalid as well.」 / Twitter
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について見てみよう
- Microsoft、組み込みデバイスをターゲットとしたTypeScriptの高速サブセット”Static TypeScript”を発表
- 組み込みデバイスでTSが実行できるようになるよ。
- 組み込みというとJavaとかCのイメージでしたが、TSも使えるようになるんですね。
・・・
STSでは、withやeval、プロトタイプベースの継承、argumentsキーワード、あるいは.applyメソッドなど、JavaScriptの最も動的な機能が削除されている。thisポインタとnew構文は、クラス外や非クラス型では使用できない。ジェネレータやawait、async function式、あるいはファイルベースのモジュールなど、最近になってJavaScript言語に追加された機能も実装していない。
・・・
- 完全なTSと同じ構文ではなく、TSのサブセット、TSっぽいコードで書けるという言語らしい。
- 組み込みでTSを使うメリット?
- Javaはそんなに軽いデバイスで動かない?
- かといってCで書くのは大変
- 高級言語だけど、そういうデバイスで動かせるというニーズがあるのでは。
- Nominal Typingなので型システムが全然違いそう。
- TypeScriptはStractural Subtyping
- MicrosoftはIoTで失敗ばかりしている印象。
- P言語とかどこ行ったんでしょうね〜
- int8とかint16とかいう型が増える?
- WebAssemblyに持ってけたりする?
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
- ビッグバン・アプローチ → いっぺんに色々導入すること
- ブラックホール・アプローチ
- ビッグバンとは…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のレポートでした。次回もワイワイやっていきたいと思います! では、また来週!