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

⾃⼰紹介 中筋 丈⼈ 株式会社FABRIC TOKYO CTO 略歴： - 陸上⾃衛隊 重迫撃砲副砲⼿ - SIer インフラ構築/業務システム開発など - MSP サービス企画/インフラエンジニア - Amazon Distribution Center エンジニア - 現職 @takenakasuji

No content

3 keywords to know FABRIC TOKYO %$ܕϏδωεϞσϧ Direct to Consumer 1 εϚʔτΦʔμʔ Smart Order 2 ϚεɾΧελϚΠθʔγϣϯ Mass Customization 3 ͭ ͷ Ω ʔ ϫ ʔ υ

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

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

3 Ϛ ε ɾ Χ ε λ Ϛ Π θ ʔ γ ϣ ϯ Mass Customization େྔੜ࢈ͱਅٯͷΞϓϩʔνͰɺ ༸෰Λ఺఺ੜ࢈͢Δ੡଄ख๏

EC ⽣産管理 システム 織り メーカー 縫製⼯場 物流 DB システム概要 サイズ登録 注⽂ 製作依頼 検品・出荷 依頼 配送 レガシーが数多く残るオーダー業界だが、ワークフロー含めて全てシステム化を⾏い⾼いUXを提供 発注

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

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

豊富なComponent • Input, Button, Selectなどフォームによ く使われるComponentは⼀通り揃ってい る • Table Componentは配列でデータを渡す とloopを書かずに⼀覧を⽣成してくれる など、実装が楽になるための機構が考慮 されている • Componentのデザインもフラットデザイ ンによりすぎず汎⽤的に使えそうな印象

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

検討のきっかけ • オーダースーツの不良品の原因を管理をする機能開発 • どの部位が何cmくらいずれていた • ボタンの種類が間違っていた • 不良の原因を⼤分類、中分類、⼩分類に分けて、親分類の選択内容に応じ て⼦分類の選択内容が切り替わる機能要件 • それぞれセレクトボックスを設けて制御できるけど、操作順など考慮して しっかりと実装するのは⾯倒。。 • 楽をできないものか。。

こういうのを求めていた

cascaderの使い⽅ • stateにcascaderで表⽰する項⽬を定義 • valueはロジックであつかうもの、labelは表⽰ されるもの • そのstateを:optionsでバインディング • あとは勝⼿に表⽰してくれるのでとても楽 • 実構成では、マスターデータの更新を考慮して、 componentには直接定義せず、APIからの取得

データ取得構成 Backend Elementで扱いやすいデータ構造にAPIを設計 Frontend get: /api/get_repair_cause_list “repairLargeCause”: [ {...}, ”repairMiddleCause”: [ .... ] ] cascaderでそのまま扱える構造で jsonを返却 state 受け取ったjsonを構造そ のままにstateに保持

できあがったもの

データ送信の構造も考えてみる • cascaderは選択した項⽬のvalueを配列で保持する • 以下の例だと、[1, 1, 1] の配列となる • どういったデータになるかはvalueの定義次第なのでstringでも可 • valueにどういったデータを持たせるかはスキーマの設計と相談(後述)

データ送信構成 Backend 余計なmappingやparseを必要としない構成 Frontend post: /api/save_repair_cause...[1, 1, 1] state [1, 1, 1] status: 200 DB 配列を分解し各フィールドに格納

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

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

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