がみぶろ

#がみぶろ

@jumpei_ikegami

We Are JavaScripters!@16th まとめ

勉強会 お仕事/キャリア

しがないラジオパーソナリティのgamiです.

さて、2/22(木)に【We Are JavaScripters!@16th】に参加したので、その内容についてまとめました！ 公開されていない資料については、見つけ次第追加していきます。

イベント自体の詳細は、こちら！

wajs.connpass.com

スポンサーLT(moffers)

moffers.jp

サービス紹介

  • 年収確約型スカウトサービス
  • 中途採用向け
  • moffersに登録してください！

LT1: Riot.jsの今とこれから @kuwahara_ngv5

資料

speakerdeck.com

自己紹介

  • ゆめみ
  • Node.js
  • Riot.jsのコミッター

コミュニティ

  • Ionicスタッフ
  • DISTスタッフ
  • MDN翻訳

Riotとは？

  • シンプルでエレガントなコンポーネントベースのUIライブラリ
  • Reactをベースに、シンプルにしたもの

特徴

  • カスタムタグで実装
    • タグの中に、HTML/JS/CSSを書いたものを、マウント
  • シンプルで軽量

現在

  • v2.9.0
  • GitHub star 12,782
    • Vue.jsは約80,000
  • size: 10.74kb
    • Vue.jsの1/3

事例

  • 日本のサイト
    • exvirte
    • cacoo
  • Made with riotのサイトに掲載あり

パフォーマンス問題

  • 10,000行のリスト要素描画
    • v2.4.1に比べて、v3.7.2は約1/9

エコシステム

  • 色んなものを組み合わせることが可能
  • ジャンル
    • Basics
    • SPA(routing)
    • Others
    • State management
    • Compile
    • Design and animations

v4

  • なくなるもの
    • this.tags
    • riot-observable
    • shourUpdate
  • ":root" -> ":scope"
  • parser/compilerを作り直してパフォーマンス改善
  • 今年の夏頃リリース予定？

質疑応答

Riotを好きになった理由は？

  • Riotは個人開発で簡単に使えるので、惚れた

v2からv3への破壊的な変更は？

  • コアのメソッドが使えなくなった
  • 繰り返し処理の使い方が変わった

LT2: 【ビ】emacs helm likeな WebExtensions を作った話 @kumabook

資料

  • 404

自己紹介

  • Hiroki Kumamoto
  • Spincoaster
    • 音楽系スタートアップ

WebExtensionとは？

  • ブラウザの機能を拡張するもの
  • HTML+JS+CSS
  • クロスブラウザ
    • 元はChromeのExtension
    • extensionAPIが標準仕様になった
    • ブラウザ間の差異はある

できること

自作したWebExtensions

  • Emacs helm on WebExtensions
  • クエリで候補を絞り込んで、アクションを実行
  • 検索履歴を消したりが、マウス無しでできる

元ネタ

  • Vimperator for Firefox
  • 似たようなものはあったが、シンプルに自分で作った

WebExtensionsのアーキテクチャ

  • background script
  • popup
  • content script
  • options ui

アーキテクチャ

  • react, redux, redux-sagaで作った
  • popupもoptions uiもreduxを使った
    • 2つのredux間では、storage apiでstate共有
  • redux-sagaのchannelを仕様

質問

ブラウザ毎に違う記述が必要なケースはある？

  • Chromeだとディスプレイサイズが取れないなど、無い機能はある

LT3: ES2015のProxyを使ってみた(仮) @tipo159

資料

  • 404

なぜProxyについて話すのか

  • WebComponentsを調べていた
  • 「Proxyオブジェクトを使うと、ObjectObservableみたいなことができるよ」

Proxy概要

  • プロパティの検索、代入、列挙、関数起動などについて、独自の動作を定義できる
  • 構文
    • var p = new Proxy(target, handler);
  • 引数
    • target: ターゲットのオブジェクト
    • handler
  • pとtargetは同じ名前でも良い

サポート状況

  • IEは...
  • モダンなブラウザであれば、使える

Vue3のProxy関連情報

  • Vue2では、配列のプロパティへの値の設定や動的なプロパティの追加は、Vue.setで行う必要がある
  • Vue3では、配列のプロパティへの値の設定や動的なプロパティの追加も、Proxyで他のプロパティと同様に扱える

メタプログラミングの例

  • 無限にチェイン可能なAPIを作成
  • meghod missingフックの実装
  • 列挙型からin演算子などを隠蔽
  • Object.observeの実装

LT4: 僕のフロントエンド奮闘記 @Nao-bt

自己紹介

  • 文系出身
  • プログラミング歴5年
  • AngularやReactを触ってきた
  • 今はレガシーな環境をVue.jsでリプレースする仕事

趣旨

コンポーネント志向

  • 画面をUIパーツ毎に分割して作り、組み合わせる
  • 再利用がしやすい
  • 分業やテストがしやすい

やりとり

  • 親→子: props down
    • 親は子を必ず知っている
  • 子→親: event up
    • 子は親を知らなくてもいい

どのくらいの細かさで切るか？

  • Atomic Designとの出会い

Atomic Design

  • Atoms: 原子
  • Moledules: 分子
  • Organisms: 有機体
  • Templates
  • Pages

Atomic Designを使った結果

  • 再利用するのか？という場合もある
  • 回数制限を設けるケースもあるらしい
  • 開発が進むにつれて楽になった
  • toCだと、同じようなコンポーネントがたくさんできそうで辛そう

Vuex

  • Reduxリスペクト
  • アプリの状態をコンポーネントから分離できる
  • バケツリレーしなくていいなんて素敵！

Vuexを使った結果

  • バケツリレーの代わりに、Vuex用の記載が増えていって辛い
  • どんなActionがあるか知らないと成立しないコンポーネントをたくさん作ってしまった
    • 親も子もVuexを知らないといけない
    • 再利用できない
  • PagesコンポーネントにVuexをまとめて、そこから下はバケツリレーすべきだった

まとめ

  • 流行りだからって何も考えずに取り入れるとやばい

LT5: 【ビ】アプリ開発未経験者がReactNativeでProgateアプリをリリースした話 @wyvernMurai

資料

speakerdeck.com

自己紹介

  • 村井謙太
  • Progate CTO

技術

  • Rails
  • Node.js
  • React
  • インフラ

Progateアプリ

  • 教育カテゴリで一瞬1位
  • キーボード部分だけが、オリジナル
  • ReactNativeファンになった！

ReactNative

コード

偉大な点

1. 開発プロセスがWebとほぼ同じ！

  • xcode使わなくていい
  • npmでpackage管理
  • スタイルはCSSで書ける(CSS in JS)
  • reduxなどでstate管理
    • 9割くらいは、reduxを書く時間となる
  • axiosやfetchでAPIリクエスト

2. ビルド速すぎて最高！

  • ライブリロード、ホットリロードが設定不要で使える
  • コードを書いて約3秒で動作確認できる

3. react-devtools最高！

辛い点

1. 日本語の情報が少なすぎる

  • 英語のドキュメントを読み込む必要がある
  • ソースコードを読む必要性が多々ある

2. たまにネイティブコードを書く必要性あり

  • 外部ライブラリのセッティングなど
  • コピペで動かないケースがある
  • Progateリポジトリでは、20行程度

リリースして得られた知見

1. redux使おう

  • 洗練されている
  • 迷ったら使うべき

2. 静的型付けしよう

  • アプリ開発は、状態が多くて複雑になりやすい
  • 関数の入出力が安定していないと、バグを起こしやすい
  • flowかtypescriptを使うべき

3. テストは早めから書こう

  • 複雑なロジックは、テストが無いと詰む
  • jestが入っているので、初期から書くべき

4. パフォーマンスチューニングは必須

  • 以下を使ってチェックすべき
    • ReactNativeの簡易プロファイラ
    • Chromeのperformanceツール
    • xcodeのInstruments
  • デバッグビルドとリリースビルドでは、アプリの動作速度がまるで違う

スポンサーLT(マイクロソフト): JavaScriptでパワポを作ろう@sakkuru

資料

www.slideshare.net

宣伝

自己紹介

JavaScript API for Office

  • Officeドキュメント内のコンテンツを操作できるJS API
  • Word, Excel, PowerPoint...
  • HTML, CSS, JSを使える

アーキテクチャ

アドインの作り方

開発中のアドインの使い方

  • PowerPointから、アドイン > 開発者向けアドイン
  • PowerPointの画面内に、Webアプリケーションを表示できる
    • クリック時のハンドラに、PowerPoint側の操作を記述できる

LT7: 学生に戻った気持ちで例文で理解しよう！JavaScriptに関する用語達！ @fukamiiiiinmin

資料

  • 404

自己紹介

  • taskey株式会社
  • 深見将一
  • peepリリース

背景

  • 新入社員がやって来る！
    • 「◯◯って何ですか？」
  • 文章として説明できる？

説明・例文

jQuery

  • JavaScriptをパワーアップしたもので、JSで書くと長いものが簡単に書ける
  • 全ブラウザで同じように動く

HTML, CSS, JS

  • 研究者が、文字や画像を共有したくてHTML
  • デザインを作りたいときは、CSS
  • ブラウザに動きが必要だとJSが必要
  • JSすごい！

ajax

  • 同期通信と非同期通信の2つがある
    • 画面が白くなるかどうか

React, Angular, Vue

  • 設計図を元に画面を作ってくれる

まとめ

  • 言葉にすると、自分の中で整理されてとてもよい
  • エンジニアとして、「ここを省いたらやばい！」ということもあるけど、理解できるかどうかが大事

LT8: 【ビ】Unit testing for React components @camcam_lemon

資料

  • 404

自己紹介

  • 日本事務器

使っているテストライブラリ

  • mocha
  • power-assert
  • jsdom
  • enzyme
  • testdouble

テストでつまりそうなポイント

refコールバック

  • rnzyme@3.0.0からref情報を読み込むようになった
  • disabledLifeCycleMethodsをtrueにすると、いきなりcomponentDidMoutが実行されないようになる

DOMオブジェクトへのアクセス

  • DOMの情報は、テスト環境では空オブジェクト
  • shallowでテストしたい

引数有りのイベントハンドラ

  • simulate()の第二引数以降にモックオブジェクトを渡すことができる
  • instance()から実行もできる

時間が絡む処理

  • testdouble-timersを使う

グローバルオブジェクトへのアクセス

  • jsdomのuserAgentやlocationは直接書き換えできない
    • setterが無いので、ヘルパーを書いた
  • windowを明示するかどうかで、テストの仕方と難易度が変わる

LT9: モジュールと名前空間について @chikoski

資料

  • 404

script type="module"

  • chromeだとデフォルトで使える
  • webpackのmodule export的なことを、ブラウザでやってくれる
  • script type="nomodule"で、フォールバックできる

変数とは

  • value = 1
    • 代入: 手続き的な概念
    • 束縛: 関数的な概念

束縛

  • データに対して名前を付ける

スコープ

  • 名前の有効範囲
  • JSでもやっとブロックスコープができた

環境(lexical environment)

  • 名前と値の対応表
  • スコープ毎に作られる
  • クロージャーも、環境自体を参照できる

例

  • Global environment
  • Module environment
  • Function environment

名前空間

  • 良い名前思いつかない問題
  • スコープなどとは違う単位で、名前を区切るもの

JSには名前空間がなかった

  • 無名関数の即時実行で頑張っていた

common.js

ES2016 module

  • 1ファイルが、1名前空間
  • exportを付けたものだけが、外部から使える
  • export 値
  • export default: 名前を指定せずに読み込んだ場合

import: 依存するモジュールの読み込み

  • import {add} from "module_a";
    • read only
  • importしたものをexportすることもできる

モジュールのいいところ

  • 「この名前使っていいかな？」を考えなくていい
  • グローバルを汚染しない
  • 外へ露出しない関数やクラスを作れる
  • 他人の作ったものを、自分の好きな名前で呼べる

依存関係のネットワーク(サイクルも解決可能！)

  • 循環依存も解決可能！

テストをどうするか？

  • 露出しない関数はどうテストする？

テストを埋め込む

  • テスト自体も、モジュールに埋め込めるメリット
  • doTest関数を露出

名前を隠すモジュールを別に作る

  • それ用のモジュールを作ってしまう手もある

Scriptsとの違い

  • 強制strictモード
  • 非同期
  • グローバル変数は、windowに明示的に追加する必要がある