Functional Reactive Programming

by Stephen Blackheath, Anthony Jones

Overview

Summary

Functional Reactive Programming teaches the concepts and applications of FRP. It offers a careful walk-through of core FRP operations and introduces the concepts and techniques you'll need to use FRP in any language.

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.

About the Technology

Today's software is shifting to more asynchronous, event-based solutions. For decades, the Observer pattern has been the go-to event infrastructure, but it is known to be bug-prone. Functional reactive programming (FRP) replaces Observer, radically improving the quality of event-based code.

About the Book

Functional Reactive Programming teaches you how FRP works and how to use it. You'll begin by gaining an understanding of what FRP is and why it's so powerful. Then, you'll work through greenfield and legacy code as you learn to apply FRP to practical use cases. You'll find examples in this book from many application domains using both Java and JavaScript. When you're finished, you'll be able to use the FRP approach in the systems you build and spend less time fixing problems.

What's Inside

• Think differently about data and events
• FRP techniques for Java and JavaScript
• Eliminate Observer one listener at a time
• Explore Sodium, RxJS, and Kefir.js FRP systems

About the Reader

Readers need intermediate Java or JavaScript skills. No experience with functional programming or FRP required.

About the Authors

Stephen Blackheath and Anthony Jones are experienced software developers and the creators of the Sodium FRP library for multiple languages. Foreword by Heinrich Apfelmus. Illustrated by Duncan Hill.

Table of Contents

1. Stop listening!
2. Core FRP
3. Some everyday widget stuff
4. Writing a real application
5. New concepts
6. FRP on the web
7. Switch
8. Operational primitives
9. Continuous time
10. Battle of the paradigms
11. Programming in the real world
12. Helpers and patterns
13. Refactoring
14. Adding FRP to existing projects
15. Future directions

Product Details

ISBN-13:	9781633430105
Publisher:	Manning
Publication date:	08/20/2016
Edition description:	1st Edition
Pages:	360
Product dimensions:	7.30(w) x 9.20(h) x 0.80(d)

About the Author

Stephen Blackheath is a professional developer and FRP advocate. He's the primary author of the Sodium FRP library for Java.

Anthony Jones writes code for a living and has spent half a decade refactoring a Java based configuration GUI to a FRP based framework. He is a contributor to the Sodium project.

Table of Contents

Foreword xv

Preface xvii

Acknowledgments xviii

About this book xix

About the cover xxii

1 Stop listening! 1

1.1 Project, meet complexity wall 2

1.2 What is functional reactive programming? 3

A stricter definition 3

Introducing Sodium 4

1.3 Where does FRP fit in? The lay of the land 4

1.4 Interactive applications: what are events? 5

1.5 State machines are hard to reason about 6

1.6 Interactive applications without the bugs 7

1.7 Listeners are a mainstay of event handling, but… 7

1.8 Banishing the six plagues of listeners 8

1.9 Why not just fix listeners? 9

1.10 "Have you tried restarting it?" or why state is problematic 9

1.11 The benefit of FRP: dealing with complexity 10

1.12 How does FRP work? 11

Life cycle of an FRP program 13

1.13 Paradigm shift 14

Paradigm 14

Paradigm shift 15

1.14 Thinking in terms of dependency 15

1.15 Thinking declaratively: what the program is, not what it does 17

1.16 Conceptual vs. operational understanding of FRP 19

Opening your mind to FRP 20

What's really going on when the code runs? 21

1.17 Applying functional programming to event-based code 22

1.18 Summary 25

2 Core FRP 26

2.1 The Stream type: a stream of events 27

2.2 The map primitive: transforming a value 30

Transforming a stream 31

2.3 The components of an FRP system 32

Combining primitives 32

Separating I/O from logic 33

2.4 Referential transparency required 33

2.5 The Cell type: a value that changes over time 34

Why Stream and Cell? 36

The constant primitive: a cell with a constant value 37

Mapping cells 37

2.6 The merge primitive: merging streams 38

Simultaneous events 39

Collection variants of merge 42

How docs merge do its job? 42

2.7 The hold primitive: keeping state in a cell 43

2.8 The snapshot primitive: capturing the value of a cell 45

2.9 Looping hold and snapshot to create an accumulator 47

Forward references 47

Constructing FRP in an explicit transaction 48

Accumulator code 49

Does snapshot see the new value or the old value? 50

2.10 The filter primitive: propagating an event only sometimes 52

2.11 The lift primitive: combining cells 53

2.12 The never primitive: a stream that never fires 55

2.13 Referential transparency dos and don'ts 55

2.14 FRP cheat sheet 57

2.15 Summary 58

3 Some everyday widget stuff 60

3.1 Spinner as a standalone SWidget 60

3.2 Form validation 62

3.3 Summary 64

4 Writing a real application 65

4.1 The petrol pump example 66

4.2 Running the petrol pump example 68

4.3 Code, meet outside world 68

4.4 The life cycle of a petrol pump fill 73

Code for LifeCycle 75

4.5 Is this really better? 77

4.6 Counting liters delivered 78

4.7 Showing dollars' of fuel delivered 79

4.8 Communicating with the point-of-sale system 82

4.9 Modularity illustrated: a keypad module 85

4.10 Notes about modularity 87

The form of a module 87

Tuples vs. classes 88

Explicit wiring 88

When inputs and outputs proliferate 88

Some bugs are solved, some aren't 88

Testability 89

4.11 Adding a preset dollar amount 89

4.12 What have you achieved? 92

4.13 Summary 93

5 New concepts 94

5.1 In search of the mythical von Neumann machine 94

Why so slow? The cache 96

The madness of bus optimization 98

How does this relate to FRP? 101

5.2 Compositionality 101

When complexity gets out of control 101

Reductionism and engineering 102

Compositionality is no longer optional 104

5.3 Lack of compositionality illustrated 104

Why the 00 version leaks compositionality 105

5.4 Compositionality: eliminating whole classes of bugs 106

5.5 Don't pull out the rug: use immutable values 107

Immutable data structures 107

5.6 Clarity of intent 108

5.7 The consequences of cheap abstraction 109

5.8 Summary 109

6 FRP on the web 111

6.1 RxJS 112

6.2 Observable 112

Hot and cold observables 113

How to maintain state 114

A stateful accumulator with scan() 114

The most recent value of an observable with withLatestFrom() 115

6.3 Keeping state in RxJS, Kefir js, and Flapjax 116

StartWith() as shorthand for BehaviorSubject 119

The same again with Kefir.js 119

And now…Flapjax 120

6.4 The latest of two observables with combineLatest 121

Glitches in combine Latest 122

Merge isn't compositional 124

6.5 Creating your own hot observable 124

Don't use this to implement logic 125

6.6 Example: autocomplete the FRP way 125

6.7 RxJS/Sodium cheat sheet 129

6.8 Static typing preferred 130

6.9 Summary 130

7 Switch 131

7.1 The sample primitive: getting a cell's value 131

7.2 Switch 132

The concept of switch: a TV remote control 132

7.3 Switch use case #1: zombies 133

The end of the world 134

A simple human 135

Using sample in map or snapshot 136

A game loop 137

An enhanced obstacle-avoiding human 139

A flesh-eating zombie 141

Putting together the two characters 143

7.4 Transforming the game character with switch 145

If a tree falls…switch and memory management 146

7.5 Switch use case #2: creation and destruction of game characters 147

Not quite referentially transparent 153

Another "what are we doing this for?" moment 154

An exercise for you 156

7.6 The efficiency of big merges 156

Efficiency of this approach 157

7.7 Game characters and efficiency in RxJS 157

7.8 Switch use case #3: removing invalid states 163

And now, improved with flatMapLatest 165

7.9 Switch use case #4: switching between screens 166

7.10 Summary 168

8 Operational primitives 169

8.1 Interfacing FRP code with the rest of your program 170

Sending and listening to streams 170

Multiple send()s in a single transaction 171

Sending and listening to cells 172

Threading model and callback requirements 173

8.2 Laziness solves loop craziness 174

8.3 Transactions 174

Constructing FRP logic under an explicit transaction 176

8.4 Getting a stream from a cell with updates and value 177

Introducing updates and value 178

8.5 Spawning new transactional contexts with the split primitive 180

Deferring a single event to a new transaction 182

Ending up in the same transaction 183

8.6 Scalable addressing 183

8.7 Summary 185

9 Continuous time 186

9.1 Rasterizing time 186

9.2 Position as a function of time 187

9.3 The animation loop 191

9.4 Measuring time 193

Newtonian physics primer 195

Signals for quadratic motion 196

A natural representation of a bouncing ball 198

9.5 Summary 200

10 Battle of the paradigms 201

10.1 Classic state machine vs. FRP vs. actor model 201

Classic state machine 203

FRP 204 Actor model 205

And the winner is… 207

10.2 Let's add a feature: Shift key gives axis lock 208

10.3 Improvement: Shift key updates the document 211

Changing this in the classic paradigm 211

Changing this in FRP 212

Changing this in the actor model 213

How are the different paradigms doing? 213

State machines with long sequences 214

10.4 Summary 214

11 Programming in the real world 215

11.1 Dealing with I/O 216

Error-handling in FRP 217

Executing an I/O action 218

Putting the application together 219

11.2 Promises/Futures 220

A map viewer example using Promise 223

Initiating I/O with the spark idiom 226

11.3 Distributed processing 228

Sacrificing consistency 228

A stream that goes over a network connection 229

11.4 Unit testing 229

Unit-testing FRP code 229

We don't recommend test-driven development (TDD) 230

FRP is type-driven development 230

FRP code is safe to refactor 231

FRP code is inherently testable 231

Testing your logic 231

11.5 Summary 231

12 Helpers and patterns 232

12.1 Calming: removing duplicate values 233

12.2 Pausing a game 235

12.3 Junction or client registry 236

12.4 Writable remote values 239

12.5 Persistence 247

12.6 Unique ID generation 248

12.7 An FRP-based GUI system 249

Drawable 249

Fridget 250

Your first fridget: FrButton 251

Bringing a Fridget to life with FrView 253

Layout 255

A form with text fields 257

12.8 Summary 261

13 Refactoring 262

13.1 To refactor or not to refactor? 262

13.2 A drag-and-drop example 263

Coding it the traditional way 264

The FRP way: diagrams to code 266

13.3 Adding a feature: drawing the floating element 267

13.4 Fixing a bug: clicks are being treated as drags 268

13.5 FRP: refactoring is a breeze 269

13.6 Summary 272

14 Adding FRP to existing projects 273

14.1 Where can FRP help? 274

14.2 Changing to immutable data structures 274

14.3 Stream as a drop-in replacement for callbacks 275

Caveat: you can't send() inside a listener 277

Choosing the right chunk size 278

14.4 Program initialization with one big transaction 279

14.5 Module extensibility with junction/client registry 280

14.6 Cells can replace mutable variables 281

14.7 Summary 281

15 Future dierections 283

15.1 Performance 283

15.2 Precompiled FRP for performance or embedded systems 284

15.3 Parallelism 284

15.4 Syntax improvements 284

Auto-lifting 285

Implicit forward references 285

Infix operators 285

Type inference 285

15.5 Standardization and code reuse 286

Code reuse and FRP abstractions 286

FRP engine performance 286

Common syntax between languages 287

15.6 FRP database applications 287

15.7 Visualization and debugging tools 287

15.8 Visual programming 287

15.9 Refactoring tools 287

15.10 Summary 287

Appendix A Sodium API 289

Appendix B The six plagues of event handling 301

Appendix C Comparison of FRP systems 309

Appendix D A section for managers 312

Appendix E Denotational semantics of Sodium 315

Index 329