- Inside Frontendに参加してきました。
| # | タイトル | 発表者 |
|---|---|---|
| A-1 | TypeScript: Why and how we adopted it at Slack | Felix Rieseberg |
| A-2 | Introduction to Lucet | Adam Foltzer |
| A-3 | Nuxt.jsで中規模サービスを統合した話 | Koichi Sawada Hajime Sasanuma |
| B-3 | Making less of the web with feature policy | Andrew Betts |
| C-3 | デザインエンジニアとフロントエンド | Shinichi Kogiso |
| A-4 | formの送信ログから反省する、本当は必要だったvalidationや機能たち | Yuta Ide |
| B-4 | Web App Checklist 〜高品質のWebアプリケーションをつくるために〜 | Kazunari Hara Marina Toki |
| C-4 | いちからデザインシステムを作ってみて学んだこと | Kengo Haruno |
| A-5 | BFFのDeveloper Experience | Yosuke Kurami |
| B-5 | strobo.fm公開収録 | Shogo Sensui Hiroki Tani |
| C-5 | AbemaTVにおけるCSS is too fragile問題に対する解 | Shota Kubota |
| A-6 | 世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト | Mariko Kosaka |
| B-6 | Loading Performanceとの向き合い方 | Sho Miyamoto |
| C-6 | 品質と開発速度を両立させるために捨てたものと守ったもの | Tsuyoshi Wada Soichi Masuda |
TypeScript: Why and how we adopted it at Slack
- Felix Riesebergさん(Slack)
SlackのデスクトップアプリをTSに移行した話
- Electronを使ってる
- JSにバグが有るとクラッシュする
- 構造化されたコードを書かないといけない
- JSDocでドキュメント化
- TSのよさ
- 型がある
- エディタの補助がきく
- KOAをつかったけどドキュメントを開くことなく開発できた
- 型と補完のおかげ
- ESLintはすばらしいがTSLintはまだそこまでいってないe
- ESLintがTSサポート始めた
- JavaScriptしかやったことない人は型を知らない
- そういう人にとっては型が難しい
Introduction to Lucet
- Adam Foltzerさん(Fastly)
Lucet
- https://github.com/fastly/lucet
- Lucetは
- コンパイラ
- runtime
- WebAssemblyを開発するためのツール群
- WebAssembly -> Lucet -> x86-64
- Rustは安全
Web Assembly
- 低レイヤーの言語
- 高パフォーマンス
- ブラウザで動く
- サーバでも動く
- ブラウザ内でも安全に動く
- WebAssemblyに変換できる言語
- Rust, C, C++ TS, go, swift
Terrarium
- RustやTSでかいたWebAssemblyをアップロードできるWebサイト
Nuxt.jsで中規模サービスを統合した話
- Koichi Sawadaさん(yahoo)
- Hajime Sasanumaさん(yahoo)
ebook japan
開発体制
- FE -> yahoo
- yahooの資産が利用できる
- API + DB -> ebook
- 旧ebookの表船機能/データ
- vue × Nuxt
- vueはデザイナーが理解しやすい
- ライブラリアップデートの手間削減
- 初心者向けに日本語ドキュメント
- Reactは(当時)ライセンスの問題
- node + express
風土の違い
AtomicDesignへの挑戦
- なぜ?
- 新規回月なので途中導入より入れやすい
- デザイン変更が多発が予想できたから
- UIの一貫性を保ちたかったから
- 苦労したこと
実装上の苦労したこと
- apiから返ってくるデータが大きい
- 使わない情報もたくさん入って返ってくる
- 開発機関制約の中で大は小をかねた形
- mixinsを使ってget処理をまとめた
リリース後の改善
体制
- 動くものを見せるとこに集中しすぎた
- エラー処理やシステム面での改善が放置気味
- 経験豊富なエンジニアがいない
- フロントエンドのサポートチーム追加
- PRのレビューや実装の相談をうける
システム(パフォーマンス改善)
- api呼び出しフローの改善
Promise.allできるものはまとめる- 描画語でいいものは描画後に取得
- レスポンスサイズ削減
- apiから取得したデータを削ってからclientに返す
- JSファイル改善
- Webpack Bundle Analyzer
- 不要コンポーネントを見つけて削除
いちからデザインシステムを作ってみて学んだこと
- Kengo Harunoさん(yahoo)
デザインシステムを作るきっかけ
- 多くのサービス多くの関係者
- 20サービス関係者1000人(デザイナー/エンジニア/ビジネス/業務委託)
- デザインがサービスでばらばら
- 一貫性確保
- デザイン開発効率化
- 何を作る?
- スタイルガイド
- デザインキット
- コンポーネントライブラリ
デザインシステム開発(デザイン編)
デザインガイドラインの策定
- デザインの定義
- 抽象的なスタイル定義
- 具体的なルール
コンポーネントのリストアップ
- 名前をつけていく(時間かかった)
- 汎用的過ぎて名前むずい
- 業務固有すぎてしっくりこない
- 見た目にとらわれずどんな役割をもっているかを考えて選ぶ
- 全員が納得するものにした(納得しない=適切でない)
スタイルガイドの制作
- sketchでデザイン作成
- あらゆるケースや状態を考慮しないといけないので大変だった
- 種類×サイズ×状態分作る
- デザインルールをドキュメント化
- デザインルールを文字化するの難しい
- 不明瞭な部分が残らないように
- レビューは全員(4人)がOK出すまでやる
- 共通認識を担保
デザインシステム開発(フロントエンド編)
コンポーネントライブラリの提供方法
- 最初はhtml/css/jsでの提供
- コーディング設計
- BEM記法
- Fractal
方向転換
Reactでコンポーネントライブラリ
- Storybookベースのものに変更
- CSS Modules with Sass
- TS
- 有識者はいなかった
- 性的チェックでエラー気づきやすい
- エディタ補完便利
- 型でデザインをより厳格化できる
- スタイルガイドをGatsbyで静的ページとして作った
- コンポーネントを取り込んでるのでずれが起きない
振り返って
- デザインから実装までこなすのはとても大変だった
- デザインシステムは巨大なプロダクト
- 使う人とのコミュニケーションが大事
BFFのDeveloper Experience
- Yosuke Kuramiさん(FOLIO)
BFF
- Backends for Frontends
- UX視点
- パフォーマンス
- UIに必要十分なAPI
- 統一したUI
- マイクロサービス視点
- ドメインに注力
- シンプルで再利用性の高いAPPI
- サービスこどの技術得意製
- これらをつなぐためにBFF
FOLIOのBFFの役割
BFFのいいところ
BFFを効率的に開発するために
バックエンドを待たない
- IDL driven development
- Interface Definition Language
- FOLIOではThrift
- IDLからコードを生成
サービスの仮データ
- 開発中のAPIはモックに差し替えたい
- 開発済みならテスト環境につなぎたい
- BFFのコードはどちらにつないでも変わらないようにしたい
- Direct Proxy
Developer向けの機能
- BFFはフロントエンドがいじるので開発者用のAPI作ってUIを作ることもできる
- stateを変える画面作って画面のバリエーションを試せたり
世界中誰もが使えるサービスを目指して、Web標準で作るガラケーサイト
- Mariko Kosakaさん(Google)
今の時代のガラケー
- スマートフィーチャーフォンのこと
- 昔のガラケーではない
- 機能
- KaiOS
- モダンブラウザ搭載
- アフリカ、インド、インネシアではやってる
- 安いから
- 画面小さい、タッチスクリーンない、十字キー
- キャリアがアプリを握っているからWebで提供するようにした方がいい
ゲームを作ってみる
どうやって開発したか
- チームスペック
- フロントエンドエンジニア3人
- kaiOS初めて
- WebGL初めて
- どこまでやるか
- 1コードベースで作る
- a11y対応も
- パフォーマンス第一
- コード
- ゲームロジック
- Stateサービス
- UIサービス
- 描画処理
- 前者2つはWebWorkerで動かす
- FW
- WebWorkerとのやりとりはComlink
- preact