Code style and application structure

Vue code style.md

Application structure

General

1. Application has tree structure with folders for each "feature"
2. Feature folders are named with lowerCamelCase → myComponentDashboard
3. Feature can contain any number of components and nested features
4. Components are named using UpperCamelCase → MyWidgetComponent.vue
5. Component can have translation .yml file named correspondingly → MyWidgetComponent.yml
6. If component requires more than 2 files: .vue and .yml file - folder is created with the same name → MyWidgetComponent
7. Shared components/classes/etc can be placed under common folder
8. Shared common folder is located near the topmost component that uses this commons

Assets

1. If there is only one asset used in component it is stored as is near the component file
2. If there are more than one asset - asset folder is created for them
3. If more than one component uses the same asset - asset folder is created even if there's only one asset
4. Shared asset folder is located near the topmost component that uses this asset

Code style

Naming conventions

1. TypeScript classes are named using UpperCamelCase → MyTypeScriptClass
2. TypeScript class files are named the same as the class → MyTypeScriptClass.ts
3. Interfaces are named using UpperCamelCase with I prefix → IMyInterface
4. Single interface files are named the same as interface → IMyInterface.ts
5. TypeScript files that are not classes, e.g. constants or multiple interfaces are named with lowerCamelCase → myInterfacesAndConstants.ts
6. Unit tests are named the same as the class or component with .test.ts extension → MyWidgetComponent.test.ts
7. Vue filters are named with .filter.ts extension → myDateTime.filter.ts

Vuex store

Structure

1. There can be component "local" stores (if only one component and its children uses store) and "global" stores (used in different components)
   • Global store is split into modules by "feature" via folders
   • Local component store is named either as "feature" or just "store"
2. Store modules/folders are named named with lowerCamelCase → myStoreModule
3. Store module can contain one or more store files
4. Store can be single file if it is relatively simple/short → index.ts
5. If store has a lot of actions, mutations or getters they are extracted to separate files:
   • actions → actions.ts
   • mutations → mutations.ts
   • getters → getters.ts
6. Every action, mutation and getter name is extracted as a constant in separate file:
   • actions → action-types.ts
   • mutations → mutation-types.ts
   • getters → getter-types.ts
7. No other files should be present in the store folder

Conventions

1. Constants are named using UPPER_CASE → MY_STORE_ACTION
2. Getters are used only if they are reused more than one time → otherwise create local computed property, use mapState
3. Any state modification can happen only in mutation
4. Actions are used for async operations and to compose multiple mutations, if you only need to do one mutation → commit locally, use mapMutations
5. For all simple actions, mutations, getters and state access → use mapState, mapGetters, mapMutations and mapActions
6. For complex operations with custom logic → use local computed properties and methods
7. Don't name computed properties and getters with get prefix

Can you share some examples for feature/componenet names. How do you distinguish what is feature or component?

@mrself - the feature is basically just a "group" of components, so it's practically just a folder without real component for it.
E.g. folder/feature "dashboard" with two components: "Graph" and "Table"