【勉強会メモ】関西Node学園 梅田キャンパス 1時限目
- 日時:2018/04/20(金) 19:00 〜 21:30
- 場所:さくらインターネット株式会社 大阪本社
Node.jsのユーザーグループによるNode学園が関西で立ち上がって初開催でした。学生の人もけっこういたりで、盛り上がりを感じました。ちなみに私は個人的に使うレベルなので勉強したいと思って参加してきましたが、あまり詳しくないのでなんとか話についていってメモして帰ってきたという感じです…
ついこないだまで4や5を使っていた印象なのにもうすぐ10が出るとのことでフロントエンド界隈の時間の流れは本当に速いと感じます。ユニットテストの話はJSに限らない気もしますが、速い時間の流れに置いていかれたレガシーなコードも少しずつテストを書いていこうと思える内容でした。
春からはじめる新しいNode.js - Node.js v10
@shisama_さん
※遅刻してしまったので途中からのメモです。
新しいNode.jsを実習
最新のNode.js
master
が最新のソースコード- Node 10.0.0.0pre
Node.js ビルド
- Makeするだけ
- 時間もそんなにかからない
さらに新しい機能を試す
- フラグをつけると使える
node --experimental-modles
harmonyフラグ
- EcmaScriptの機能を使えるようにする
- shipping:リリース済み(フラグなしで実行可能)
- staged:ほぼ完成 --harmonyフラグ
- in progress:開発中
node -v8-options
で使える機能を確認
Node.jsに実装されていない機能
- Babelでトランスパイル
- EcmaScript 全機能をカバーしているわけではない
まとめ
- Node.jsのサポート期間を意識しよう
- Node.js v10は来週リリース
TypeScript + Express
@kamiyamさん
www.slideshare.net
TypeScript
⇒大きめのシステムでJSより少しきっちり使いたい時などに使われる言語
TypeScript導入(not Express)
npx
tsconfig.json
…設定any
…なんでも使える型⇒基本的には使わない
型定義を準備する
- 文字通り型のないJavaScriptに型を定義する
- 型定義 (d.ts) ファイルを作成(参照)する
- 多くは@types/xxxから探すことができる
- 自分で定義することもできる
- tsファイル内
types/***
で定義
- tsファイル内
- interface使える
- enumも使える
ES2017使いたい
- コンパイルオプション使う
tsconfig.json
compilerOptions
のtarget
に"ES2017"
を指定
tslint
- 入れたほうが幸せ
TypeScript+Express
TypeScriptへの置き換え
※参考
Babel7.xで変わること
@mochiya98さん
主な破壊的変更
- scoped modleへの変更
- es20xx系のプリセットが非推奨
- JSではなくブラウザを基準に指定
- scoped modlesはpresetがフル表記に
- カンマ区切りのpresetsがエラーに
追加機能
- .babelrc.jsのサポート
- TypeScriptのサポート
細かい変更を知るには
- Planning for 7.0
- 若干古いので注意
- Nearning the 7.0 Release
- この記事を観てわからなければPlanning~を見る
- Upgrade to Babel7
- 意向メインならここを見る
- 次のリリースであるBabel7の主な変更点まとめ - 技術探し
- より細かい情報
最新の情報はBabel公式ブログを見れば安心
多くのプロジェクトに対応するのは大変
- コマンド1つで自動修正
npm bable-upgrade
- 6から7にマイグレーションしてくれる
JavaScriptユニットテストの理想と現実
きりん@sota1235さん
- 現実のつらみからテストを書ける状態にもっていく話
テストの必要性
- なぜテストは必要か?
- 品質担保のため
- 品質とは
- 意図したとおりに動作するか
- きれいなコード
- 想定していない入力に耐性があるか
- あるモジュールが単一の責務を果たしているかをテストする
- 最小粒度でのテスト
- モジュール単位のテスト
責務毎にテストを分ける
- 1テストケースがシンプルになる
- モジュールが責務ごとに分かれることが強制される
汚いコードはテストが書きづらい
- テストを書けるようにするとコードがきれいになりやすい
なぜテストを書きづらいか
全てのフロントエンドのコードがきれいって早々ない
現実との戦い
テストが書くのが難しくテストを書く文化もない
なぜテストが浸透していないのか
- フロントエンドのコードをモジュールでばらして書けるようになったのがここ数年
- フロントエンドの要件事態が複雑化
- 複雑化したロジックを保守する必要性が増した
フロントエンドis カオス
- ステートフルな世界
- UIとロジックの2つの世界
- 様々な外部要因
現 実 is カオス
- レガシーコード
- jQuery 1.x.0とか...
どう立ち向かうか
- 既存のロジックにユニットテストを書く
- コストパフォーマンスが重要
書いて終わりではない
- 運用、保守する必要がある
- ロジックが変わればテストも書き換える
- コスパが大事
コスパを考える
- テスト対象のモジュールが変更される可能性が高くないか
- テスト対象はロジックでなくUIではないか
例えば
- クリックされたら消費税を計算」
- 計算ロジックならテストしてよさそう
- jQueryで動的に生成されるDOMのclass名
- いろんな都合でclass名が変わる可能性がある
テストを書く場所の勘所
- UIのテストは無駄になることが多い
- E2Eテストが難しいと言われる所以
- コアのロジックは変わることが少ない
- 使いまわせる粒度に保てば再利用性も上がる
モジュールを切り出す
現実はだいたい多くの責務を持った何かがある
- ユーザーインタラクションとロジックを分離する
- 1つのイベントリスナに詰まっていたものをまずイベントリスナとそれ以外で分ける
- ロジックを分離する
- ロジックから2つのロジックを切り出す
つらい現実に立ち向かうには
- 今あるコードを紐解いていく
- 紐解く時の鍵はUIとロジック
- 紐解いてfunction化、module化したものにテストを追加していく
- 簡単なところから少しずつ
テストを書くという文化
- テストを書く文化がないなら積極的にアプローチ
- 1つ簡単なサンプルがあればみんな真似する
mochaのトレーニングリポジトリ
おまけ:次のつらさ
importをモックする
無理せずflowtypeを導入していく
まいける@h_michael_zさん
Flowの導入
TypeScriptとの違い
npm run flow
で実行
最初に読む
- 使い方:公式のusage
- 型付け:公式のtypes
- Try flowで動かしながら読み進める
- flow-type-cheat-sheet
- Editorの設定
flow-language-server
型をつけ始める
- はじめは無理に細かく型付けをしない
- Primitive,Array,Union,Object,Mixedでかける範囲で型を付ける
- Anyはなるべく使わるMixedかObjectを使う
- ObjectのpropertyがOptionalかどうか値がMaybe Typeかどうかどちらにもしない
- 慣れれば型の未定義なものでも1ファイル10分くらいで型付が終わる
3rd partyのライブラリにも型をつけたい
- flow-typedを使ってみる
- TypeScriptでいうDefinitely Typed
Flowのupgradeの話
- 一気にバージョン上げるのはつらいのでこまめに上げる
- 型安全を手に入れたいだけなので新しいfeaturはどうでもいい
- バージョンごとにlikely to cause new Flow errosがある
- バージョン上げるごとにより安全になる