Decoupling Packages From Your Framework

It's really fun to build a package that adds some awesome functionality to your favourite framework. If you're not careful however, you can end up releasing something that nobody could use outside of Framework-X no matter how hard they try.

In this talk, I'll walkthrough building a framework agnostic package. You'll learn about important OO design principles like dependency injection, interfaces, and encapsulation, and see how we can integrate our package with a modern framework like Laravel, or the messiest legacy codebase you've ever seen.

Transcript

1. DECOUPLING PACKAGES FROM YOUR FRAMEWORK @ADAMWATHAN
2. @ADAMWATHAN ▸ Software developer ▸ Host of Full Stack Radio ▸ Former Audio engineer ▸ Competitive powerlifter
3. @ADAMWATHAN ▸ Software developer ▸ Host of Full Stack Radio ▸ Former Audio engineer ▸ Competitive powerlifter ▸ ...Batman?
7. 42,288 PACKAGES
8. 413,057,365 PACKAGES INSTALLED
10. An example...
11. FLUENT FORM BUILDER
12. 1. REPOPULATE FORM WITH OLD INPUT IF SUBMISSION FAILS
13. Ditch this...
14. ...for just this:
15. 2. ABLE TO RETRIEVE ERROR MESSAGES FOR EACH ELEMENT
16. Something like this...
17. #1: RETRIEVING OLD INPUT
18. Probably this sort of thing...
19. In Laravel...
20. In Laravel...
21. So maybe...
22. Nope.
23. Composer.json...
24. The whole truth...
25. What about...
26. No dependencies !== NO COUPLING
27. So what's the answer?
28. Dependency INJECTION
29. Dependency injection is a software design pattern that implements inversion of control and allows a program design to follow the dependency inversion principle. 1 1 http://en.wikipedia.org/wiki/Dependency_injection
30. ...Come again?
31. INSTEAD OF AN OBJECT GETTING IT'S OWN DEPENDENCIES, WE SHOULD GIVE THEM TO THE OBJECT OURSELVES.
32. So this...
33. Becomes this...
34. THIS IS BETTER BUT...
35. We're still coupled...
36. DEPEND ON INTERFACES not implementations
37. Something like...
38. INTERFACES 101
39. INTERFACES 101 ▸ Like a contract
40. INTERFACES 101 ▸ Like a contract ▸ Describes public API of a role
41. INTERFACES 101 ▸ Like a contract ▸ Describes public API of a role ▸ Does not provide any implementation
42. INTERFACES 101 ▸ Like a contract ▸ Describes public API of a role ▸ Does not provide any implementation ▸ Great as documentation in a package
43. An implementation...
44. Now instead of this...
45. ...we can do this:
46. What about OTHER frameworks?
47. What about NON-FRAMEWORK applications?
48. Aww yeah
49. #2: ERROR MESSAGES
50. Something like this would be cool...
51. So we need these badboys...
52. Could do this...
53. Let's add it to the interface...
54. ...and the implementation:
55. Looks good right?
56. Why a SESSION?
57. Identify the right ABSTRACTIONS
58. 1. Somewhere to get OLD INPUT
59. 2. Somewhere to get ERRORS
60. Somewhere to get old input...
61. Somewhere to get errors...
62. Somewhere to get old input...
63. Somewhere to get errors...
64. Updated Form Builder...
65. Laravel Old Input...
66. Laravel Error Store...
67. Legacy Old Input...
68. Legacy Error Store...
69. Symfony Old Input...
70. Focus on ONE JOB
71. Bootstrap prototype...
72. Bootstrap prototype...
73. Bootstrap boilerplate...
74. ...reduced to this:
75. Optimize for COMPOSABILITY
76. BootForms dependencies...
77. Composabilitize!
79. YOU DON'T HAVE TO SUPPORT EVERY FRAMEWORK OUT OF THE BOX... JUST DON'T GET IN THE WAY.
80. Why?
81. ENCOURAGES COMMUNITY COLLABORATION
82. IT'S JUST GOOD CODE.
83. @ADAMWATHAN ADAMWATHAN.ME FULLSTACKRADIO.COM JOIND.IN/12711