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. …
The future is very promising and here are my primary reasons:
In the Apple programming world there has been a debate. Should the reactive programming framework propagate errors as:
And there you go: `ReactiveCocoa` being at times more or less popular did the second thing, where its `Observable` required 2 type parameters, second of which was the type for the `onError` event. ReactiveX, being a more generic, semantically portable concept available for numerous platforms pulled the first way. …
Swift is a great language to write applications in. However, being more or less proficient in numerous other programming platforms, one will of course acknowledge that one of the most flexible and truly powerful programming languages out there is ECMAScript. In this article I am going to talk about such a syntactic construct as the anonymous class. Consider this little gist.
This one is not the class in its entirety, but just the dynamic behavior I would occasionally end up looking for while working on a project. …