Chapter 14. Adding FRP to existing projects

 

This chapter covers

  • Changing over to immutable data structures
  • Replacing callbacks with streams and cells
  • Program-initialization techniques
  • Combining information sources extensibly with Junctions

Cast your mind back to the beginning of the book where we told the sad tale of a project hitting the complexity wall. The authors have both lived through this. It’s actually the underlying motivation for our interest in FRP.

We think software quality and the costs of achieving it are a serious issue for industry. Software is being called on to solve more and more complex problems. There are many reasons for this, but parallelism will be an increasingly important factor. Existing methods are coming under strain. We need stronger techniques to deal with this greater complexity, and that’s why industry is looking to what functional programming can offer. FRP is part of that. We think that for certain types of projects—anywhere there’s a lot of event handling—FRP can help turn intractable code into maintainable code so you can navigate the complexity wall barrier.

14.1. Where can FRP help?

Here are some situations where you might consider adding FRP to an existing project:

14.2. Changing to immutable data structures

14.3. Stream as a drop-in replacement for callbacks

14.4. Program initialization with one big transaction

14.5. Module extensibility with junction/client registry

14.6. Cells can replace mutable variables

14.7. Summary