To run the project, clone the repo, and run
pod install from the root directory first.
RxComposableArchitecture is a modern Rx library for building applications in a consistent way, with composition and testing.
Usually developers come to Functional Reactive Programming whith just in mind the idea of “reactive”, or that everything is a stream of data. Basically it’s true but there is a caveat. In fact we should remember that we are working in functional world, which means that we should keep in mind some principle as: the state immutability and composition.
State immutability is a misleading concept. Obviously the state should mutate, in fact our aim is to transform informations. But we must do it in a consistent way. And this is where comes from the idea of the Composable Architecture.
Every feature is defined by some types and values that model your domain:
- State: A type that describes the data your feature needs to perform its logic and render its UI.
- Action: A type that represents all of the actions that can happen in your feature, such as user actions, http requests, access to a DB and more.
- Environment: A type that holds any dependencies the feature needs, such as API clients, analytics clients, and more.
- Reducer: A function that describes how to evolve the current state of the app to the next state given an action. The reducer is also responsible for returning any effects that should be run, such as API requests, which can be done by returning an Effect value.
- Store: The runtime that actually drives your feature. You send all user actions to the store so that the store can run the reducer and effects, and you can observe state changes in the store so that you can update UI.
The benefits of doing this is that you will instantly unlock testability of your feature, and you will be able to break large, complex features into smaller domains that can be glued together.
Every feature is testable in isolation and the power of the Composable Architecture is the ability to glue together two or more features in order to create a brand new one.
For example the gameSessionViewReducer is build on the composition of the user login, bootstrap and the game session session. And even the appReducer is build on the composition of the GameView and the Leaderboard.
This lead to an another concept: the sharing state. In fact, every time a session is completed, the collection of sessions is updated and shared between the single Session and the Leaderboard, please refer to AppState
Engineering for Testability
A type that holds any dependencies the feature needs, for WhoSigns we have client for Musixmatch API.
- WhoSings: is the live implementation
- WhoSingsMock : a bunch of different scenarioss for manual testing and development
The folder UI Application contains all the Views and ViewControllers and is isolated from the features domain.
Features domain and Business logic
GameView is the main feature and is composed on three sub-features.
- Bootstrap: is responsible to fetch properly the APIs. Download a bunch of TopSongs in Italy and for every track fetch the corresponding lyrics. In addition download a list of artists.
- Game Session: once start is called a new game session is created based on the Bootstrap results.
- Login: handle a simple login session in local
Simply contains the game user session completed.
Pods for testing
Jean Raphaël Bordet, [email protected]