Task manager is an app created to simplifies and bring equality to the process of divide tasks, primarily thought to home-related tasks.
This project is intended to be an application of all the stuff I've learned from software development in general and full-stack development in particular. Thus, I intentionally avoid using boilerplates, not because they lack utility, but because my aim here is to test my knowledge and make the experiment of building things from scratch.
-
React
-
Node
-
Express
-
Webpack
-
Jest
-
Typescript
0.0.1 Milestones:
- Class diagram.
- Database diagram.
- Autentication flow, frontend.
- Implement TDD.
- Classes implementation.
- Database connection.
- API creation.
- New task viewer
- Pending tasks viewer
- Stats viewer
Statecharts are a formalism for modeling stateful, reactive systems. This project has been created to experiment with this concept. For the pourpose, I have used the XState library for creating, interpreting, and executing statecharts.
Statecharts are also a good way to document a system. Below is the diagram corresponding to the authentication flow(frontend):
Below is showed that the system has several states, depending on the actions performed by the user. The first state is iddle, where the user only can send credentials and send the SUBMIT transition to the wait state. In this state the correspondent transition is performed automatically by the system, and depending on the authentication success (which carries the system to the logged state) or failed (which carries the system to the secure_wait_after_login_fail state).
Being in the secure_wait_after_login_fail state means the system will fire automatically one transition conditionally. If there have been less than 5 authentication attempts, the system will return to the iddle state. Elsewhere, the system will fallback to a timeout, where the login will be disabled temporally, and then will be automatically fired a transition, also to the iddle state.
In the logged state, the system will have nested states to allow the authenticated user activity (to_do). There is also one last first-order state which is sesion_autoclosed, in which the logged state falls due to user inactivity. This state has a transition performed by the user to the iddle state.
Each state in machine state is related to a page.
- Each transition can be a user interaction (Button) or a transition (Promise resolved/rejected, timer). But must not be strictly related to the components.
How to search for style
- The definitions scales down from container to contained components.
And rules of style creation
-
May seem obvious but mobile-first: media-queries are only used in @min-x form.
-
Same-level definitions must be declared and adjusted Z-index.
Start each finding in top-level.
- .
Each state is related to a page. Each transition can be a user interaction (Button) or a transition (Promise resolved/rejected, timer). This is a powerful concept when drawing a state machine. But this should not be taken strictly into account when creating react components since it can be detrimental to the abstraction and re-utilization. Also, this can be detrimental to performance. This is because when dealing with different layers of the architecture(the business layer, solved by the state-machine model, and the UI layer, solved by the reactive model) some objects may apparently have a counterpart in the other layer. But this is a problem related to the creation of the objects itself. This is, in essence, always an abstraction. An arbitrary decision is taken to establish the cut in reality and to make phantasmagorically appear our objects. This desition can be taken more or less accurately, taking us to better or worse software design. But can never be infallible. the Achilles heel of object-oriented programming rests here. Enough talk, some code illustration of those concepts:
The first approcach that turns to me out when designing the state machine was this:
this doesn't match very well with the maxim "Each state in the finite-machine-state is related to a page." because we have an "orphan state" here. You see that? Yes, it's the error state. This is because the state-machine can be simplified. Error state is no more than a part of secure_wait_after_login state. This way, we simplified the state machine by making an observation in another layer of the architecture.