This article focuses on different limitations of the Reactive Extensions implementation of FRP paradigm.
Reactive Extensions is a family of frameworks that allow for functionally-reactive programming in imperative programming languages. One of the greatest factors that allow us to treat all of the implementations as a part of one family is the fact that all of them bring identical concepts to the table, which is reflected in similar primitives naming, operators semantics and life-cycle control tools. The advantages of x for commercial projects include:
Right now we will, however, take a tour on 3 aspects of Reactive Extensions that showcase the limitations of the modern popular implementations. …
In this article, I would like to discuss the concept of an adventurous and thoughtful error handling in a modern iOS application.
The concept consists of two major aspects:
All the code presented in this article can be found and fiddled around with here.
Error tree is a compound data structure that is designed to make it easy to see what exactly is the reason behind a failure of a complex operation.
— literally me, writing this very article.
The main premise here is to treat your error objects as regular models, identical to the objects that your view would use to configure itself during positive, error less use case. This emphasis dictates that the creation of an erroneous model to be used by a view may or may not be just as complex as a creation of any other model. In a typical heavyweight architecture you would see that the creation of a model that view sees is preceded by some intermediate steps such as creation of an abstraction over the network’s response, a so-called “data transfer object”, that encapsulates the deserialization logic while not carrying anything related to the business rules of the application. …