With all the prereqs installed:
cd into it and run yarn install. This will install all the node dependencies we need for development.yarn start to start the react dev server in specified environment.Vuyit is ecommerce website built in React. eature list are as follow:
yarn unit-test to run the unit testsWe have come up with some rules to keep code consistent accross the application. These rules are enforced by TSLint where possible, but if you are unsure please refer to the evolving list below:
async/await instead of Promisesroot folder)console.info for logging useful runtime information. Using console.log is preferred for some debugging cases and will produce a TSLint warning reminding you to clean up your old debugging logsWhen writing helper functions with more than two params, especially optional params, consider having one config param which is an object that is destructured instead. This will prevent cases where we call a function with undefined params:
helper(undefined, undefined, paramWeWantToPass)and make code more readable
helper({ param: paramWeWantToPass })When you encounter a function with a too many params in the codebase, refactor it to the preferred pattern in your PR.
(Many of these rules have been liberally repurposed from here)
Apply the single responsibility principle (SRP) to all components, functions, and other symbols. 'Gather together those things that change for the same reason, and separate those things that change for different reasons.' This helps make the app cleaner, easier to read and maintain, and more testable.
Do define one thing, such as a service or component, per file.
Consider limiting files to 400 lines of code.
Why? One component per file makes it far easier to read, maintain, and avoid collisions with teams in source control.
Why? One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies.
The key is to make the code more reusable, easier to read, and less mistake prone.
As the app grows, this rule becomes even more important.
Do define small functions
Consider limiting to no more than 75 lines.
Why? Small functions are easier to test, especially when they do one thing and serve one purpose.
Why? Small functions promote reuse.
Why? Small functions are easier to read.
Why? Small functions are easier to maintain.
Why? Small functions help avoid hidden bugs that come with large functions that share variables with external scope, create unwanted closures, or unwanted coupling with dependencies.
Do structure the app such that you can Locate code quickly, Identify the code at a glance, keep the Flattest structure you can, and Try to be DRY.
Do define the structure to follow these four basic guidelines, listed in order of importance.
Why? LIFT provides a consistent structure that scales well, is modular, and makes it easier to increase developer efficiency by finding code quickly. To confirm your intuition about a particular structure, ask: can I quickly open and start work in all of the related files for this feature?
Do make locating code intuitive, simple, and fast.
Why? To work efficiently you must be able to find files quickly, especially when you do not know (or do not remember) the file names. Keeping related files near each other in an intuitive location saves time. A descriptive folder structure makes a world of difference to you and the people who come after you.
Do name the file such that you instantly know what it contains and represents.
Do be descriptive with file names and keep the contents of the file to exactly one component.
Avoid files with multiple components, multiple services, or a mixture.
Why? Spend less time hunting and pecking for code, and become more efficient. Longer file names are far better than short-but-obscure abbreviated names.
It may be advantageous to deviate from the one-thing-per-file rule when you have a set of small, closely-related features that are better discovered and understood in a single file than as multiple files. Be wary of this loophole.
Do keep a flat folder structure as long as possible.
Consider creating sub-folders when a folder reaches seven or more files.
Why? No one wants to search for a file through seven levels of folders. A flat structure is easy to scan.
On the other hand, psychologists believe that humans start to struggle when the number of adjacent interesting things exceeds nine. So when a folder has ten or more files, it may be time to create subfolders.
Base your decision on your comfort level. Use a flatter structure until there is an obvious value to creating a new folder.
Do be DRY (Don't Repeat Yourself).
Avoid being so DRY that you sacrifice readability.
Why? Being DRY is important, but not crucial if it sacrifices the other elements of LIFT. That's why it's called T-DRY. But if something is not obvious or departs from a convention, then spell it out.
Do create folders named for the feature area they represent. Treat these folders as separate modules, and think about what is exposed from them
Why? A developer can locate the code and identify what each file represents at a glance. The structure is as flat as it can be and there are no repetitive or redundant names.
Why? The LIFT guidelines are all covered.
Why? Helps reduce the app from becoming cluttered through organizing the content and keeping them aligned with the LIFT guidelines.
Why? When there are a lot of files, for example 10+, locating them is easier with a consistent folder structure and more difficult in a flat structure.
Do think about what's exported from each feature area. This is the api to that module.
Do keep files that work on the same feature / part of the domain, located closely together.