What I wish I could tell my younger self about FRP (from a RAC perspective):

  1. Before diving into FRP, start using functional aspects that Swift gives you for free. Like: map, flatMap, filter, reduce, or create your own. This will make the usage of high order functions more intuitive. Without this, you will struggle and feel demotivated.
  2. Dive deeper into Functional aspects and start using Result, instead of the recommended do/try/catch. You will start to appreciated composition. This will provide you a mental framework for what a Monad is.
  3. Do not underestimate Result's NoError. It will help describing your system better, by making it simpler.
  4. If you have the time, read Learn you a Haskell for Great Good.
  5. Start as soon as you can and be consistent with your study. Learning FRP takes time. Not only you are exposed to a new paradigm, it takes time to get used to the framework (syntax, operators and behaviour).
  6. Initially you will feel that most of the operators don't fit your needs, but as you learn more, you will see that in fact they do. Rarely I had the need to create new operators. My recommendation is to make an extra effort and exhaust your options, before creating a new one.
  7. 99% of the time you won't care about hot and cold signals. Until you do and lose hours of work. Take a bit of time to understand the difference.
  8. You will feel tremendously tempted to use a given result (e.g. [FooBars]) inside the startWithNext closure. Always strive for binding, instead of setting values manually. Binding, not only makes the code more readable, it also makes memory management easier.
  9. Because you don't know how to manipulate streams of events, you will feel compelled to create flags (boolean properties) inside your class. Nothing is worst than FRP mixed with highly stateful code. A solution in this case, is to ask around in the ReactiveCocoa's Slack channel. The next step is to learn from the best resources.
  10. You app architecture will dramatically change when you start seeing it as small blocks of work. Your network layer, won't know what parsing is, or how you persist your model objects. This will be true for most of your app. A lot of small pieces abstracted via protocols. This will make your code highly reusable and easily testable.
  11. Because you now know about composition and how easy it is to pass values between different blocks of work via flatMap, certain things like logging and analytics, won't clutter the core of your app. You can just plug-in whatever you want easily.
  12. FRP can be applied to many different problems.
  13. Good things take time.

Post idea by Tiago Almeida