# Style Guide
# File structure conventions
├── .vuesion // vuesion configuration ├── cypress // e2e tests ├── i18n // language files used by vue-i18n ├── logs // express logs └── src ├── app // main app code │ ├── app // app module - contains main component │ ├── config // app config to pass data from the server environment to the client │ ├── shared // shared code │ ├── ... // new modules will be added on this directory level │ ├── app.ts // app setup │ ├── router.ts // global routing information │ ├── state.ts // global app state │ └── store.ts // vuex store ├── client │ ├── index.ts // entry point for client application │ └── sw.ts // service worker ├── index.template.html // template, needed for SSR and webpack ├── server │ ├── server.ts // express app │ ├── index.ts // entry point for server application │ ├── isomorphic.ts // entry point for server-side rendering │ ├── middlewares // express middlewares │ ├── routes // express routes │ └── utils // utils for SSR └── static // static files mapped to /
# What is a Module?
A module is an encapsulated piece of domain logic in your application, this could be for example:
# Use-cases for a module
Dynamic page: consists of a lot of view logic, at least one route and state management
Static page: has no state management but a route e.g.
Domain logic with shared view components: e.g. authentication state, actions, mutations plus login/signup forms but no routes
Domain logic: just plain logic with state management but no routes and no components
A module usually has routing information, state management or both.
You can easily create modules with
npm run generate
# What is a Connected Component?
A connected component is a Single File Component with VueX-mappings and it has to live inside a module.
(these components are different compared to normal components because it is required to set up a VueX mock store for testing)
# What is a Component?
This is a simple Single File Component without bindings, it just takes props and emits events - this is called a "stupid" component.
A Component can be placed everywhere. Usually, they live in the first level of a module, but it can also be inside other component folders.
You should try to have as many "stupid" components as possible. They are much easier to test because you can just pass test objects, values, stubs and mocks as a property. And they are much better to reuse!
If you want to know how to archive this, have a look at Container Components (in our vocabulary "Connected Components").
# Naming Conventions
Naming is one of the hardest things in software development. We cannot support you with perfect names because we don't know your domain but we can help you to be consistent in naming files, modules, CSS classes, etc.
Let's consider you create a new page (module) with state management, routes and a component named
FooBar. What would be the different variations for different contexts?
- connected component
- css class
fooBar// we decided against the hyphen notation because you have to use lower camel-case anyway to reference it with
- state interface
- default state
If you want to save some time and keep the style guide consistent, we recommended using the included Generator CLI to generate new code.