Services in Entitas for Flutter
This is the second article on Entitas for Flutter. If you missed the first one, please do at least scan through it. As I will not repeat concepts that I mentioned in the first article again.
What do I mean by services?
Services are simple classes (or maybe even just functions), which implement some behaviour. They are different from systems as systems are executed periodically and services are rather helpers or utilities which are used by systems, or maybe directly by widgets.
To make it all a bit less theoretical, lets dive into an example.
This time I took an example from flutter_redux code base. It is the example, where a user can search through GitHub repositories.
As always lets start with browsing through component type definitions:
First of all, we have a SearchState enum and a SearchStateComponent. The SearchState enum represents our general application state. none means that we just initialised the app and should ask user to perform the first search.
empty indicates that the search was performed but there was no repositories found matching the given query.
loading is probably self explanatory. We show the loading indicator while the query is in process.
error means that the query could not finish successfully. We might have lost internet connection, or there is something wrong with github.com
And last but not least done symbols that we got an non empty list back and are displaying it to the user.
The SearchStateComponent is a unique component which holds the value of the state. It is unique because we don’t want our application to be in multiple states at the same time and it is generally there, so we can observe it and display different views when it gets added or updated.
SearchStateComponent is a typical example, if we want to implement something like a state machine on top of Entitas. By replacing the state we are triggering the state transformation logic. But more on it a bit later, lets continue with other components.
NameComponent, UrlComponent and AvatarUrlComponent are components which represent the results coming from Github. Put them all together on an entity and you got yourself a repository instance.
Last and the most important component for this article is the GithubApiComponent, which is unique and holds a reference to GithubService.
What is GithubService?
It is a class which handles making HTTP requests and transforming the received data to entities. It is also setting itself as GithubApiComponent on construction (see line 13).
This wayGithubApiComponent exposes an instance of this class to everyone who has access to entity manager.
Here we see the main widget representing the Github search app. On lines 21-22 we see that the onSubmit callback is calling the service through, entity manager. This way EntityManager is handling the job of a so called Service Locator.
On lines 26–34 you can see the implementation of a state machine which I mentioned before. The EntityObservingWidget is observing the unique entity which holds SearchStateComponent and will rebuild the overlay each time its value is changed.
I am very happy to announce that I released version 0.1.0 of EntitasFF on Github and you can find this and other examples from previous article here:
In last article I always presented two solutions for an example. One which is based purely on state and observing widgets and another which moves computations from the widgets to systems. This time I will write a separate article, where I will explain how to build a more sophisticated Github search app with systems.
State tuned and thank you for reading. As always, I would appreciate a clap.
