Splitting up 8ball &
Building &
Sharing Components:
Our Plan for 2015
Slide 2
Slide 2 text
go/8ballcomponents
Slide 3
Slide 3 text
Part 1: App Split
Slide 4
Slide 4 text
What’s the plan?
Slide 5
Slide 5 text
Split up the app.
Create more server-side modules.
Package up flows, dynamic and static
components.
Slide 6
Slide 6 text
Building
Slide 7
Slide 7 text
Why split up the app?
Slide 8
Slide 8 text
Faster/easier releases
Benefit #1 !
!
!
Slide 9
Slide 9 text
Independent releases.
Can’t block each other.
Less cross-team merge conflicts.
Slide 10
Slide 10 text
Improved focus
Benefit #2 !
!
!
Slide 11
Slide 11 text
Remove the noise.
Write small, focused modules.
Better code, better docs, better tests.
Easier ramp up time for new devs.
Slide 12
Slide 12 text
More stable
Benefit #3 !
!
!
Slide 13
Slide 13 text
Errors and crashes are more contained.
Kinda sad, but this is a nice feature. =)
Slide 14
Slide 14 text
Able to move forward
Benefit #4 !
!
!
Slide 15
Slide 15 text
It’s hard to change a monolith.
It’s easy to change a small app.
Easier to experiment.
Slide 16
Slide 16 text
Push Schedule
2/24 - settingsnodeweb LTS
March - Credit App LTS
April - Transfer App LTS
Slide 17
Slide 17 text
Okay, so how do components
fit into this?
Slide 18
Slide 18 text
Part 2: Components
Slide 19
Slide 19 text
Modularize the common parts.
Reason #1 !
!
!
Slide 20
Slide 20 text
Modularize the common parts.
Slide 21
Slide 21 text
consumerweb-* modules
Slide 22
Slide 22 text
consumerweb-* TODOs
Some failing unit tests.
No ESLint.
Need to add CI ASAP. Any takers? =)
Slide 23
Slide 23 text
Create value ($$$)
Reason #2 !
!
!
Slide 24
Slide 24 text
P2P and Add Bank everywhere.
Drive more people to Consumer Web.
Slide 25
Slide 25 text
Unified Login… Unified Add Bank?
Slide 26
Slide 26 text
Components are really tough.
Slide 27
Slide 27 text
Highly recommended!
Slide 28
Slide 28 text
No consistent UI platform.
Difficult to share code with teams.
No Kraken for the UI.
No consistent component APIs.
Slide 29
Slide 29 text
Delivering UI components
Slide 30
Slide 30 text
Web Components
Option #1 !
!
!
Slide 31
Slide 31 text
End all be all?
!
Encapsulation.
Shadow DOM.
Natural components.
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
iframes
Option #2 !
!
!
Slide 34
Slide 34 text
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.
Slide 35
Slide 35 text
The Bad Parts
You can’t pick what you want, you get it all.
Multiple versions of jQuery, etc.
Could have performance implications.
Slide 36
Slide 36 text
Example:
P2P 1-line iframe integration
Slide 37
Slide 37 text
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”
Slide 38
Slide 38 text
Great part is this is super re-usable.
<script src=“loader.js?path=/myaccount/wallet/bank/add” />
<script src=“loader.js?path=/myaccount/settings/address” />
…
Slide 39
Slide 39 text
redirectUrl
Option #3 !
!
!
Slide 40
Slide 40 text
Common pattern.
Useful for flows (P2P, Add Bank, etc.)
Least amount of risk.
Crappiest UX.
Slide 41
Slide 41 text
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.
Slide 42
Slide 42 text
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 =)