This project was bootstrapped with Create React App.
It's recommended to test from the user's point of view, hiding implementation details. More details.
Recommended documentation for test implementation.
Test phases:
Arrange: a series of input data is created to be able to run the tests.
Act: tests are run with the input data.
Assert: the result obtained is analyzed to see if it matches what is expected.
Pre-commit hook is used in local development (husky+link-staged). More details.
There's no QA team, so each development must be tested. Also, if a new development is not tested, coverage decreases. If the coverage is below the accepted limit, the merge will not be possible. More details.
Components: This is located in the src/components path. Each should be located in a separate folders and must contain:
component implementation
tests
styles
images
Also, the component is organized internally in the following order:
hooks are located at the top
constants and states together
functions.
Outside the component the variables or functions that do not depend on some props. See slack conversation thread for more details.
Hooks: This located in src/hooks path. Each should be located in a separate folders and must contain:
hook implementation
tests
Services: This is located in the src/services path. Each should be located in a separate folder and must contain:
service implementation
tests
service double
Translations: This is located in src/i18n path. There are two files: en.js and es.js. If the translation is common, it's added within the common property, otherwise, it's added in the property that contains the translations of the corresponding module.
Gif/Images: The reused gif/images are located in the src/img path. The particular images are located in the folder of the component that uses them. Example: a gif for the contact policy promotional page.
Use const instead of let and var. Example:
// Not recommended
let result;
if(someCondition) {
result = calculationA();
} else {
result = calculationB();
}
// Better
const result = someCondition ? calculationA() : calculationB();
Use High Order Functions when it’s possible. Examples:
// Not recommended
for(let i=0; i < cities.length; i++) {
const city = cities[i];
// to do something with city
}
// Better
cities.forEach((city) => {
// to do something with city
});
// Not recommended
for(let i=0; i < myArray.length; i++) {
myArray.key = “a value”;
myArray.otherKey = “a value”;
}
// Better
const newArray = myArray.map((item) => ({
...item,
key: “a value”,
otherKey: “a value”,
}));
Use composition instead of inheritance to reuse code between components. More details.
Use named imports instead of default imports. More details.
Use pronounceable and expressive names for variables, always prioritizing the camelcase style. Avoid using names that refer to the data type.
Use the useTimeout hook on components instead of setTimeout. More details.
Use a maximum number of 2 parameters for functions. If the number is exceeded, use an object.
Use the optional chaining operator. Example:
// Not recommended
if(obj.first && obj.first.second) {
// ...to do something
}
// Better
if(obj?.first?.second) {
// ...to do something
}
We use semantic release to generate each tag for automatic versioning, that's why it's important to have each commit formatted correctly, this tool uses Angular commit message format by default that uses conventional commits.
The format is the following:
<type>(<scope>): <short summary>
The types we most use are:
Some examples:
fix(login): fix a typo in main title
feat(reports): add new GDPR report
chore: update component version
⚠️ With every merge, the code is deployed into production, whenever we have a fix or feat commit, that's why we test in each PR before merge.
Each time a PR is made CI is run, to see a full detail check DockerFile.
What is run in CI?
As a result of running CI, a temporal version of the code is published into CDN marked with a build number.
To check the build number in the second check marked in each PR, while hovering in details the version is as marked in the image below.
Then a build code link with build number 2962 can be formatted as follows for all enviroments:
Production: https://cdn.fromdoppler.com/doppler-webapp/build2962/#/login
Integration: https://cdn.fromdoppler.com/doppler-webapp/int-build2962/#/login
QA: https://cdn.fromdoppler.com/doppler-webapp/qa-build2962/#/login
Demo: https://cdn.fromdoppler.com/doppler-webapp/demo-build2962/#/login Demo is like a local copy hosted into CDN (it uses doubles and no real data).
Development: https://cdn.fromdoppler.com/doppler-webapp/demo-build2962/#/login Development is code that points to local Doppler (It is needed to have local Doppler copy running for this to work).
In this project we have include PR size, as a way to measure how much is small. Right now we tend to make size M or L PRs and that's our size for small.
We try to use vertical slicing or partial functionalities to keep our PRs small enough to be easily understood.
To make our PRs small sometimes is useful to upload hidden functionality. This can be done by using the dopplerExperimental component.
const PermissionExpandableRow = ({ dependencies: { experimentalFeatures } }) => {
...
const isPermissionHistoryEnabled =
experimentalFeatures && experimentalFeatures.getFeature('PermissionHistory');
...
return (
<>
<tr>
<td>
<span className="dp-name-text">
{isPermissionHistoryEnabled && (
<button>
...
To make use of this feature by console it can be enabled like this:
localStorage.setItem('dopplerExperimental', JSON.stringify({PermissionHistory: true}));
In the project directory, you can run:
yarn install
In the project directory, you can run:
yarn start or yarn
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
yarn test
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
yarn build
Builds the app for production to the build
folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
yarn eject
Note: this is a one-way operation. Once you eject
, you can’t go back!
If you aren’t satisfied with the build tool and configuration choices, you can eject
at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject
will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.
You don’t have to ever use eject
. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.
You can learn more in the Create React App documentation.
To learn React, check out the React documentation.