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
Splitting up 8Ball and building/sharing components
Search
Mark Stuart
February 19, 2015
Programming
0
110
Splitting up 8Ball and building/sharing components
Mark Stuart
February 19, 2015
Tweet
Share
More Decks by Mark Stuart
See All by Mark Stuart
JS@PayPal 2015 - Insanely fast rendering w/ Service Workers and Early Flushing
mstuart
0
970
Midwest JS 2014 - Securing your Node.js & Single Page Apps
mstuart
2
350
enterJS 2014 - Securing your Node.js & Single Page Apps
mstuart
4
630
HTML5DevConf 2014 - Securing your JavaScript apps
mstuart
0
180
Other Decks in Programming
See All in Programming
Modern Angular with Signals and Signal Store:New Rules for Your Architecture @enterJS Advanced Angular Day 2025
manfredsteyer
PRO
0
220
イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code
nrslib
2
800
ふつうの技術スタックでアート作品を作ってみる
akira888
1
820
生成AI時代のコンポーネントライブラリの作り方
touyou
1
210
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
120
PicoRuby on Rails
makicamel
2
130
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
160
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
820
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
150
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
120
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
160
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
52
33k
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
A designer walks into a library…
pauljervisheath
207
24k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Facilitating Awesome Meetings
lara
54
6.4k
Code Review Best Practice
trishagee
69
18k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
Docker and Python
trallard
44
3.5k
Balancing Empowerment & Direction
lara
1
430
How STYLIGHT went responsive
nonsquared
100
5.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Transcript
Splitting up 8ball & Building & Sharing Components: Our Plan
for 2015
go/8ballcomponents
Part 1: App Split
What’s the plan?
Split up the app. Create more server-side modules. Package up
flows, dynamic and static components.
Building
Why split up the app?
Faster/easier releases Benefit #1 ! ! !
Independent releases. Can’t block each other. Less cross-team merge conflicts.
Improved focus Benefit #2 ! ! !
Remove the noise. Write small, focused modules. Better code, better
docs, better tests. Easier ramp up time for new devs.
More stable Benefit #3 ! ! !
Errors and crashes are more contained. Kinda sad, but this
is a nice feature. =)
Able to move forward Benefit #4 ! ! !
It’s hard to change a monolith. It’s easy to change
a small app. Easier to experiment.
Push Schedule 2/24 - settingsnodeweb LTS March - Credit App
LTS April - Transfer App LTS
Okay, so how do components fit into this?
Part 2: Components
Modularize the common parts. Reason #1 ! ! !
Modularize the common parts.
consumerweb-* modules
consumerweb-* TODOs Some failing unit tests. No ESLint. Need to
add CI ASAP. Any takers? =)
Create value ($$$) Reason #2 ! ! !
P2P and Add Bank everywhere. Drive more people to Consumer
Web.
Unified Login… Unified Add Bank?
Components are really tough.
Highly recommended!
No consistent UI platform. Difficult to share code with teams.
No Kraken for the UI. No consistent component APIs.
Delivering UI components
Web Components Option #1 ! ! !
End all be all? ! Encapsulation. Shadow DOM. Natural components.
None
iframes Option #2 ! ! !
The Good Parts (tm) Super old and works everywhere. Easy
to implement. Server-side or Client-side rendered. Encapsulated. UI platform agnostic. Communication via postMessage.
The Bad Parts You can’t pick what you want, you
get it all. Multiple versions of jQuery, etc. Could have performance implications.
Example: P2P 1-line iframe integration
<script src=“loader.js?path=/myaccount/transfer” /> 1. Fetches and loads loader.js 2. loader.js
scrapes off “path” from itself 3. Creates an iframe 4. Sets the iframe’s URL to the “path”
Great part is this is super re-usable. <script src=“loader.js?path=/myaccount/transfer/send” />
<script src=“loader.js?path=/myaccount/wallet/bank/add” /> <script src=“loader.js?path=/myaccount/settings/address” /> …
redirectUrl Option #3 ! ! !
Common pattern. Useful for flows (P2P, Add Bank, etc.) Least
amount of risk. Crappiest UX.
paypal.com/myaccount/transfer?redirectUrl=/merchant/home 1. Store redirectUrl in session. 2. /myaccount/transfer is rendered.
3. If the user exits, redirect to redirectUrl. 4. If the user completes, redirect to redirectUrl.
Next steps Split out as many apps as possible. Keep
building server-side modules. Build UI components for dust/Backbone. Hopefully within 2-3 months =)
Packaging components
Bower out. npm in.
component-creditmodule npm postinstall script Copies files into public/ ! dependencies,
peerDependencies
If you’d like to help out, let me know!