OOP to FP

Walking through refactoring a simple controller to be more functional.

Transcript

1. Refactoring OOP to FP How and why to write functionally in JS
2. • Massive reduction of dependencies makes code that's easier to understand. • Be DRYer than DRY by having more agnostic code that’s highly reusable. • Accidental future proofing through malleable code that’s composable to change the intent. • Less refactor time by instilling less dictatorial patterns on every class. • Better unit tests by reducing the use of mocks and fixtures (they have a very bad code smell). • Better semantic variable naming over comments (which easily become outdated). • Code is easier to reason about because it’s not affected by state mutations in other classes. * Also look into Immutable data structures because they reset the performance characteristics to make code that’s easier to engineers to reason about also be performant for the CPU. The Goals of Functional Programming
3. We’ll take a simple Controller that is built to manage multiple approvals and rejections for a business management process. It is written using standard OOP practices that we’ll walk through a refactor to FP and discuss the trade-off and FP terminology. Sample Project
4. Brief tour of the Controller
6. Refactoring approval types from loops to mapping
16. Refactor template fetching. Using agnostic, typeless, functions
25. Finding all approvals pending. compose everything
30. Which approval needs action. raising from local to private scope
37. Get the last approval date. composing and transforming
43. Sorting approval by importance. using closures immutable configurations
51. Minor cleanup. remove ‘this’ to enforce statelessness
55. Interface cleanup. making a gradual transition to functional
58. Review and wrap up. The power of composing agnostic functions
64. How to start thinking functional learn the vocabulary and deconstruct everything
66. Why Functional Programming? 1. Simple functions are easy to reuse and easy to test. 2. Functions can be reused in ways you didn't think of when it was created. 3. Simple functions are easy to understand. 4. Refactoring FP compared to OOP happens less frequently. 5. Encapsulate dependencies so other external functions don't need to know about it. Curry more. How to be Functional. 1. Operate on a single simple object first. 2. Compose all things. 3. Think in terms of transforming an object from one structure to another; not step by step operations. 4. Don't micro-optimize (don't worry about lots of little allocations). If you have bigger operations look into immutable data. 5. Just like when thinking of class method, think about a function’s arguments and order. Functions with the exact same argument count (and sometimes type) can be reused in order functions.