Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Elementのすすめ
Search
Taketo Nakasuji
April 26, 2018
0
3.9k
Elementのすすめ
Laravel/Vue.js勉強会#4で話した資料です。
https://laravue.connpass.com/event/82296/
Taketo Nakasuji
April 26, 2018
Tweet
Share
More Decks by Taketo Nakasuji
See All by Taketo Nakasuji
デザイナーが D2Cビジネスに身をおいてわかったこと
takenakasuji
2
8.7k
新規システムのためのLaravel導入とユースケース駆動開発の話
takenakasuji
1
560
Vue.jsを使ったら幸せになった話
takenakasuji
1
4k
IoTで実現するリアルストア戦略
takenakasuji
0
1.9k
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
How STYLIGHT went responsive
nonsquared
100
5.7k
Designing for Performance
lara
610
69k
Side Projects
sachag
455
43k
Scaling GitHub
holman
461
140k
Optimizing for Happiness
mojombo
379
70k
The Cult of Friendly URLs
andyhume
79
6.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Building an army of robots
kneath
306
45k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Transcript
Elementのすすめ Laravel/Vue.js勉強会#4 株式会社FABRIC TOKYO CTO 中筋丈⼈
⾃⼰紹介 中筋 丈⼈ 株式会社FABRIC TOKYO CTO 略歴: - 陸上⾃衛隊 重迫撃砲副砲⼿
- SIer インフラ構築/業務システム開発など - MSP サービス企画/インフラエンジニア - Amazon Distribution Center エンジニア - 現職 @takenakasuji
None
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デザイナー 少しでも興味ある⽅はこの後の懇親会でお声がけください!!