複雑化したcomponent群と向き合う / #241106_plk_frontend

Slide 1

Slide 1 text

Slide 2

Slide 2 text

目次 Agenda ● 自己紹介 ● 複雑化って・・？ ● 向き合う ● 終わりに

Slide 3

Slide 3 text

自己紹介

Slide 4

Slide 4 text

Slide 5

Slide 5 text

5 © LayerX Inc. 事業紹介稟議・支払申請・経費精算仕訳・支払処理効率化法人カードの発行・管理帳票保存・ストレージ帳票発行 * 経費精算のSlack連携は申請内容の通知のみ・AIが領収書を５秒でデータ化・スマホアプリとSlack連携あり・領収書の重複申請などミス防止機能・AIが請求書を５秒でデータ化・仕訳・振込データを自動作成・稟議から会計までスムーズに連携・年会費無料で何枚でも発行可・インボイス制度・電帳法対応・すべての決済で1%以上の還元・AIが書類を5秒でデータ化・あらゆる書類の電子保管に対応・電子取引・スキャナ保存に完全対応・帳票の一括作成も個別作成も自由自在・帳票の作成・稟議・送付・保存を一本化・レイアウトや項目のカスタマイズも可能

Slide 6

Slide 6 text

6 © LayerX Inc. 事業紹介稟議・支払申請・経費精算仕訳・支払処理効率化法人カードの発行・管理帳票保存・ストレージ帳票発行 * 経費精算のSlack連携は申請内容の通知のみ・AIが領収書を５秒でデータ化・スマホアプリとSlack連携あり・領収書の重複申請などミス防止機能・AIが請求書を５秒でデータ化・仕訳・振込データを自動作成・稟議から会計までスムーズに連携・年会費無料で何枚でも発行可・インボイス制度・電帳法対応・すべての決済で1%以上の還元・AIが書類を5秒でデータ化・あらゆる書類の電子保管に対応・電子取引・スキャナ保存に完全対応・帳票の一括作成も個別作成も自由自在・帳票の作成・稟議・送付・保存を一本化・レイアウトや項目のカスタマイズも可能

Slide 7

Slide 7 text

© LayerX Inc. 7 基本的な機能 2021年の4月リリースのNuxt製のアプリ支払申請・購買申請・経費精算などなど複数の申請種別の申請・承認を扱うプロダクト - 申請種別ごとにいろんな種類のvalidationがあったり、 - 設定で色々経路をいじれたり、 - OCRでデータを読み込んだりとにかく場面場面でいろんな入力が入ってきてハンドリングが必要なプロダクトですバクラク申請経費精算について

Slide 8

Slide 8 text

複雑化って・・？

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© LayerX Inc. 10 色々な申請種別を扱うという複雑なドメインが atomic designのパーツを下位のレイヤーから組み立てる思想と合わせにくかった ● 下位のcomponentは不要な共通化が行われ再利用・修正が難しい ○ 例：すごく汎用的なみたいなものが存在していた ○ 実際はvalidation、クリックした時の挙動、入力した時の挙動までとにかく多岐にわたる ○ 色々なロジックに対応するためpropsをたくさん受け取って何をするcomponentなのか分からない ● 上位のcomponentは責務とともに実装も膨らむ ○ サーバからデータを取る、propsに渡すデータ・関数を作成するで実装が膨らむ atomic designとどう相性が悪かったのか

Slide 11

Slide 11 text

© LayerX Inc. 11 Vue2からVue3への移行の難しさ ● Vue2時代の型との相性の悪さを引きずる ○ Vue2時代は型checkを全て通すことをやっておらずその余波でせっかく型を付けても正しくチェックができないことが多数 ● Options APIからComposition APIを使ってcomposableへロジックの切り出しをしたいが元々の実装箇所が多くて置き換えきれていない

Slide 12

Slide 12 text

© LayerX Inc. 12 1. 😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢下位のcomponentの不要な共通化 b. 😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 2. 😢vue２からvue3への移行の難しさ a. 😢vue2時代の型の相性の悪さを引きずって型チェックができていない b. 😢options APIとcomposition APIの混在この２大巨頭によって思わぬところに影響が出て実装がとても難しいうえに時間が経つにつれて悪化の一途をたどっている😢😢😢 複雑な状況まとめ

Slide 13

Slide 13 text

向き合う

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© LayerX Inc. 15 ディレクトリベースの漸進的な改善 atomic designベースのディレクトリに機能単位のディレクトリを新しく切った狙い 1. 😢→☺ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→☺上位のcomponentの責務が大きくなりでかすぎるcomponentがいる新規のものは基本的にfeatures/に入れるように ● 明らかに汎用的なもの以外はfeaturesに入れて過度の汎用化を防いだ ● featuresに閉じたロジックはcomposableを経由するようにして上位の componentの肥大化を防いだ

Slide 16

Slide 16 text

© LayerX Inc. 16 ディレクトリベースの漸進的な改善現実 1. 😢→😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる新しい下位のcomponentによる複雑さは増えなくなった☺ 上位のcomponentは責務が大きいまま😢 だけど責務が膨らんで行くことは少なくなった☺

Slide 17

Slide 17 text

© LayerX Inc. 17 力あるのみ ● 根気のあるチームメンバーの手によってそれはもうたくさんあった型エラーが0に・・😭 ● 進め方は色々工夫してはいたものの型エラーが残っていると伝播してすぐ増えてしまうので何だかんだ時間と気持ちの戦い・・ ● ただただ偉業型エラーを全て直す予定通りの結果 ● 😢→😐vue２からvue3への移行の難しさ ○ 😢→☺☺vue2時代の型の相性の悪さを引きずって型チェックができていない ○ 😢options APIとcomposition APIの混在

Slide 18

Slide 18 text

© LayerX Inc. 18 1. 😢→😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 2. 😢→😐vue２からvue3への移行の難しさ a. 😢→☺☺vue2時代の型の相性の悪さを引きずって型チェックができていない b. 😢options APIとcomposition APIの混在複雑さの現在地