Elementのすすめ

Transcript

1. Elementのすすめ Laravel/Vue.js勉強会#4 株式会社FABRIC TOKYO CTO 中筋丈⼈

2. ⾃⼰紹介 中筋 丈⼈ 株式会社FABRIC TOKYO CTO 略歴： - 陸上⾃衛隊 重迫撃砲副砲⼿

   - SIer インフラ構築/業務システム開発など - MSP サービス企画/インフラエンジニア - Amazon Distribution Center エンジニア - 現職 @takenakasuji
3. None

4. 3 keywords to know FABRIC TOKYO %$ܕϏδωεϞσϧ Direct to Consumer

   1 εϚʔτΦʔμʔ Smart Order 2 ϚεɾΧελϚΠθʔγϣϯ Mass Customization 3  ͭ ͷ Ω ʔ ϫ ʔ υ

5. %  $ ܕ Ϗ δ ω ε Ϟ σ

   ϧ 1 ࣗΒ͕ϝʔΧʔͰ͋Γɺ ࣗࣾͰاըɺ੡଄ͨ͠঎඼Λ ࣗࣾͷ&$αΠτͰൢച͢ΔϞσϧ Direct to Consumer

6. 2 ε Ϛ ʔ τ Φ ʔ μ ʔ Smart

   Order ମܕαΠζΛΫϥ΢υอଘɺ ͋ͱ͸ΦϯϥΠϯͰΦʔμʔ

7. 3 Ϛ ε ɾ Χ ε λ Ϛ Π θ

   ʔ γ ϣ ϯ Mass Customization େྔੜ࢈ͱਅٯͷΞϓϩʔνͰɺ ༸෰Λ఺఺ੜ࢈͢Δ੡଄ख๏

8. EC ⽣産管理 システム 織り メーカー 縫製⼯場 物流 DB システム概要 サイズ登録

   注⽂ 製作依頼 検品・出荷 依頼 配送 レガシーが数多く残るオーダー業界だが、ワークフロー含めて全てシステム化を⾏い⾼いUXを提供 発注

9. 今⽇話すこと 社内システムにElementを導⼊した話 • Elementの概要 • 採⽤した理由 • 実装⾯の考慮

10. Elementとは？ • Vue.js⽤のUI Framework • Github Star数: 25,619 • npm

    trends: TOP (Vue.jsのUI Framework)

11. 豊富なComponent • Input, Button, Selectなどフォームによ く使われるComponentは⼀通り揃ってい る • Table Componentは配列でデータを渡す

    とloopを書かずに⼀覧を⽣成してくれる など、実装が楽になるための機構が考慮 されている • Componentのデザインもフラットデザイ ンによりすぎず汎⽤的に使えそうな印象

12. 整備されたドキュメント • 実際に動作するUIや使⽤例、パラメータ の定義などしっかりと整備されている • 各使⽤例ごとにjsfiddleのリンクがあり、 すぐにカスタムして動作を確認できる

13. 検討のきっかけ • オーダースーツの不良品の原因を管理をする機能開発 • どの部位が何cmくらいずれていた • ボタンの種類が間違っていた • 不良の原因を⼤分類、中分類、⼩分類に分けて、親分類の選択内容に応じ て⼦分類の選択内容が切り替わる機能要件

    • それぞれセレクトボックスを設けて制御できるけど、操作順など考慮して しっかりと実装するのは⾯倒。。 • 楽をできないものか。。

14. こういうのを求めていた

15. cascaderの使い⽅ • stateにcascaderで表⽰する項⽬を定義 • valueはロジックであつかうもの、labelは表⽰ されるもの • そのstateを:optionsでバインディング • あとは勝⼿に表⽰してくれるのでとても楽

    • 実構成では、マスターデータの更新を考慮して、 componentには直接定義せず、APIからの取得

16. データ取得構成 Backend Elementで扱いやすいデータ構造にAPIを設計 Frontend get: /api/get_repair_cause_list “repairLargeCause”: [ {...}, ”repairMiddleCause”:

    [ .... ] ] cascaderでそのまま扱える構造で jsonを返却 state 受け取ったjsonを構造そ のままにstateに保持

17. できあがったもの

18. データ送信の構造も考えてみる • cascaderは選択した項⽬のvalueを配列で保持する • 以下の例だと、[1, 1, 1] の配列となる • どういったデータになるかはvalueの定義次第なのでstringでも可

    • valueにどういったデータを持たせるかはスキーマの設計と相談(後述)

19. データ送信構成 Backend 余計なmappingやparseを必要としない構成 Frontend post: /api/save_repair_cause...[1, 1, 1] state [1,

    1, 1] status: 200 DB 配列を分解し各フィールドに格納

20. リレーション 各マスターはデータ取得時のAPIのレスポンスにも使⽤し不整合が⽣じない構成 不良品原因ID - repair_large_cause_id - repair_middle_cause_id - repair_small_cause_id 不良品原因テーブル

    原因⼤分類ID - name - priority 原因⼤分類マスター 原因中分類ID - name - priority 原因中分類マスター 原因⼩分類ID - name - priority 原因⼩分類マスター

21. 本⽇のまとめ • Elementの各Componentの仕様がProgrammableな設計と なっており開発がしやすい • 豊富なComponentをもつFrameworkはデザイン・実装の両⾯ で統⼀感をもたせるのに寄与する

22. Weʼre Hiring!! • サーバサイドエンジニア • フロントエンドエンジニア • UIデザイナー 少しでも興味ある⽅はこの後の懇親会でお声がけください！！