AgileTs isn't bound to any specific Style-Guide, but there are some you may get inspired from.
To give you an idea of possible structures for applications using AgileTs as a state management framework, we have prepared some inspiration guides for you. Feel free to choose one of them and adapt it to your needs.
In this Style-Guide, we have a so-called
core at the top-level of our
src folder beside our UI-Components.
core is thought to be the brain of our application and should contain all business logic
and logic in general, that isn't specifically bound to a Component.
This outsourcing of our logic makes our code more decoupled,
portable, and above all easy testable.
Below you can see where our
core should be located.
To represent the
core for a better understanding visual, I use one of a TODO application.
This application has two main Entities, that can be handled by AgileTs.
The User and of course the TODO-Item. These two parts are mapped in our
Each property that you can find in the above shown graph, is described in detail below ⬇️.
Our Todo-List has to communicate to a Backend, therefore we need something that creates http/s requests for us. I am using the AgileTs API but you can use whatever you want.
To make simple rest calls possible, we initialize our api class here. These defined API instance gets mainly used in the route section of an Entity.
core consists of several entities, which exist apart from each other, having their own independent existence. Each
Entity manages its Data separately by doing rest calls or mutating States. This separation makes our
structured, readable, and improves maintainability.
A User Entity should only treat the whole logic of the User and shouldn't do rest calls for the Todo Entity.
An action is any piece of code that modifies our
In principle, actions always happen in response to an event. For example, a button got clicked.
The creation of a Todo-Item in the UI-Layer triggers the
addTodo action, which then mutates our State and makes rest calls.
The Controller of an Entity holds and controls States, Collections, .. for that Entity. These Agile Sub Instances might get modified by actions or bound to a Component in the UI-Layer.
interface section can be ignored by non Typescript users!
If you are a Typescript user, you properly want to create an interface for your entity. These interfaces belonging to this entity should be defined here.
In case of the TODO-Entity, it contains a TodoInterface.
To communicate to our server, we have to create rest calls. For better maintainability, these rest calls are provided here in function shape and should only be used in actions of the Entity. It's not recommended calling them from outside the corresponding Entity.
In this file, we create our main
Agile Instance and configure it to meet our needs.
For example, we determine here with which UI framework AgileTs works together.
States, Collections, etc. then can be created with help of this Instance.
It's not recommended having multiple
Agile Instances in one Application!!
Here we export our
core entities so that each entity can be reached without any detours.
For instance, we might import the
core in our UI-Layer.
There we than just import our
core and mutate each entity from it like
There is no second Inspiration yet, but feel free to share your own 'style guide' inspiration here. Every contribution is welcome. :D