General Concepts
Last updated
Last updated
Conan Data are capsules of data with TACOS.
I know you are curious about the TACOS part, (this is explained below), but first let's look at what data we want to encapsulate:
The key is to encapsulate the necessary logic and business data or meta data that needs to be managed to successfully deliver your requirements.
That is quite a mouthful, let's try again with some examples of Conan Data.
On a web application game, It could be the current score.
On an e-commerce application. The current progress for a shopper while on the checkout from a shopping cart.
On a tabs widget. It could be the current tab the user has selected.
On a CRM application. It could be the list of customers to be displayed on the screen.
On a timesheet applications. It could be the data and validations behind the form to enter the hours for the week.
Something interesting about this type of data, is that is better described not for what it is, but how you usually will want to use it.
And this is where the TACOS part of the description comes into play.
When you develop web applications / components, you are mostly mapping data to a user interface.
We have seen in the previous section how Conan Data lets you put this into capsules, but you will find that you also need to be able to manage it.
We cover this by providing the following attributes to each Conan Data element that you create.
Testable Testing state e2e is simple
Actionable If you can access the state, you can change it through an action
Composable You can create new state from already existing state easily.
Observable You can observe state and receive updates when the state changes.
Scalable You can have your state global, or you can scope it.
You can use the TACOS as mnemonic to remember the attributes.
Have a look at the docs for each the Conan State and Conan Flow to map these attributes to their sections in the documentation.
There are two flavours of Conan Data, their purpose is the same, to help you encapsulate and manage your application data, but they are better suited for your use case depending on the nature of the data that you want to map.
We like to think that the best way to think about this is to think on how many dimensions would better describe the data that you want to map.
This is likely to be how you are used to think about data.
1D data is data of the same shape that changes over time.
For instance, if you encapsulate the score for a game that you are developing through a Conan State, you can visualize it like this:
Status | State 1 | State 2 | State 3 | State 4 |
nextData | 0 | 100 | 200 | 300 |
For this use case, Conan State is the best fit to map your data.
There are sone cases where the data is best represented in a matrix, we also think that this is the main use case when working with flows.
Let's think about the authentication flow for instance, first thing that comes to mind, is that a flow has statuses:
notAuthenticated -> authenticating -> authenticated
Then each status will have its one type of data.
For instance, continuing with the authentication example, this could be the types mapped on each status
notAuthenticated -> type: string (reason) authenticating -> type: [username, password] authenticated -> credentials
Let's try to represent this visually:
Let's map a user with username 'username' and password 'password' trying to authenticate twice, the first time with the wrong password
Status | State 1 | State 2 | State 3 | State 4 | State 5 |
notAuthenticated | 'invalid password' | ||||
authenticating | [username/TACOS] | [username/password] | |||
authenticated | credentials |
If you pay attention to the tables above, even for Conan State, (which is a one dimension data structure) we have Statuses and State.
Conan State is in fact a Flow of one status (nextData).
In summary, in ConanJs all Conan Data has Statuses, and the statuses have states.
Status: A stream of states,
For Conan State, there is always only one status created for the user, 'nextData' - note that this is transparent to the end user of the Conan State.
For Conan Flow, the user decides how many statuses and their name
State: The representation of each data update received in a status.
Another cool feature of Conan data, is that you can start / stop it at your own convenience.
Note that for the sake of simplicity we have made both Conan State and Conan Flow to auto start when you create them (unless you explicitly say otherwise )
What this brings to the table, is the ability to help you to work with complex data structures like Streams
Note that as of v1.0 Streams and start / stop are not fully exploited, we would like to create out of the box Streams, add more Docs and Demos to cover for these use cases.
But there is nothing stopping you to explore this functionality on your own
This introduces a gap in the Conan Data where while it starts and while it stops is not yet in any status. And that's where the limbo statuses come to play.
$init: This is the status the Conan Data stays at while it performs all necessary actions to transition into its first state.
$stop: This is the status the Conan Data stays at while it performs all necessary actions to transition out of his last state.
Is good to be familiar with these two statuses since you are likely going to see them in your logs, you can listen to them...
At last, now you should be comfortable with the difference between statuses and states.
Steps and transitions are they counterpart methods.
Steps Are the methods available to produce a new state for a given status. In the case of the Conan State, these are the actions.
Transitions. Are the methods available to move from a given status to a new status with the provided state, they are explained in the Conan Flow section. Note that Conan State does not have a mechanism for transitions as it only has one status.
Note that ConanJs is agnostic to the UI framework (Angular, Vue, React..), as of v1.0 we provide with classes to use it with React, but we are hoping to add more frameworks soon.
There are 2 pairs of classes that wrap all the logic for the Conan Data.
Thread, and Thread Facade. Wrap all the logic for 1D state.
Flow, and Flow Facade. Wrap all the logic for 2D state.
We have not included detail documentation for this classes, but feel free to explore them if you want to learn the guts of the framework
''
