Splitting up 8Ball and building/sharing components

Transcript

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