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.8k
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.4k
新規システムのためのLaravel導入とユースケース駆動開発の話
takenakasuji
1
510
Vue.jsを使ったら幸せになった話
takenakasuji
1
3.8k
IoTで実現するリアルストア戦略
takenakasuji
0
1.9k
Featured
See All Featured
How GitHub (no longer) Works
holman
311
140k
Visualization
eitanlees
146
15k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
4 Signs Your Business is Dying
shpigford
181
21k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
BBQ
matthewcrist
85
9.4k
Faster Mobile Websites
deanohume
305
30k
How STYLIGHT went responsive
nonsquared
95
5.2k
How to Ace a Technical Interview
jacobian
276
23k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
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デザイナー 少しでも興味ある⽅はこの後の懇親会でお声がけください!!