In artidoc, features are split in different "composables" objects and stores.

The problem with this architecture is that:

- The composables are becoming god objects (does not comply with SRP)

- The composables are sometimes heavily dependant of another composables or stores.

- Some composables are basically proxies for another composable (feature envy code smell)

- All the layers of the app are merged into them. They handles actions, execute API calls, transform payloads, store information, update the UI (loading/saving/refresh/error states) etc.

Initially, the composables were introduced to avoid passing properties to the components. Paradoxically, it is the contrary that happens, because the components actually are receiving a ton of properties (often extracted from said composables).

The current architecture makes it hard to keep on developing new features, such as the nesting of sections.

The proposition is the following:

1. Make the SectionsStore a SectionCollection and inject it into the application.

2. Extract all the actions implemented in the SectionStore into dedicated class-like objects.

3. Split the composables step by step into different class-like objects?