rubenspgcavalcante
commented
6 years ago So, we basically need a styleguide for:
Define the project architecture on structure level:
- How the directories and files are disposed under the project. How to treat and organise specific code, "maybe" reusable and "for sure" reusable code;
- How much should I modularise the code, breaking components, actions and reducers without raising too much the granularity but keeping the single responsibilities and KISS;
- Breaking the app into features and built the submodules thinking in a way to match this;
- How deep submodules can go;
- Directory, file and extension name conventions;
- Definition of module (what it is and what it have, how to use it and how it works).
Define the project architecture on code level:
- Code standards: linter and prettifier rules
- React good practices: PureComponents, avoiding legacy context, avoiding old lifecycles, etc;
- Redux good practices: Creating actions and reducers, and organising them in a simple and understandable way;
- Tests good practices: Unit tests for dumb components, browser tests for page components, creating mocks and spies for it, etc;
- Breaking into Page main components connected by containers and proxying the state to dumb components or other ways;
- Routing conventions;
- Querying on Firebase.
Define the project architecture on app/feature level:
- How to use the generic CRUD (future) API;
- Creating collections on firebase;
- Notes on Material-UI guidelines
- Logging system (what should I log, what I shouldn't).
Of course some of stuff can be added later, others can be a single line of description, but there's some important stuff that we need everyone trying to follow to maintain the simplicity and quality of the app. Reminding that a well organised project is ultra friendly for outsider maintainers: easy to find, easy to create and easy to debug. Other thing I've said before, the code is the best documentation, so by just following the styleguide, we make easy to other contributors to just follow what was already done and create new features without the necessity of reading the entire guideline.
Some full stack frameworks as Angular already have a default styleguide and other specific ones (as I did for using with AMD) . As we're working with micro frameworks (e.g. React) and we're creating our own stack, we have this necessity to create a more specific guideline.
Any comments about it guys?
HaGuesto
We will create a style guide containing:
@rubenspgcavalcante feel free to correct this as much as you want!