{"id":13553995,"url":"https://github.com/juntossomosmais/frontend-guideline","last_synced_at":"2025-04-08T10:31:44.435Z","repository":{"id":37006759,"uuid":"402189545","full_name":"juntossomosmais/frontend-guideline","owner":"juntossomosmais","description":"📝 Front-end Guideline by Juntos Somos Mais","archived":false,"fork":false,"pushed_at":"2024-07-15T18:45:50.000Z","size":524,"stargazers_count":1145,"open_issues_count":1,"forks_count":51,"subscribers_count":43,"default_branch":"main","last_synced_at":"2025-04-01T09:22:34.038Z","etag":null,"topics":["code-style","coding-style","css","frontend","frontend-guide","frontend-guidelines","good-practices","hacktoberfest","html","javascript","patterns","patterns-design","react","typescript","vue"],"latest_commit_sha":null,"homepage":"https://juntossomosmais.github.io/frontend-guideline/","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/juntossomosmais.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-09-01T20:08:00.000Z","updated_at":"2025-03-16T02:57:09.000Z","dependencies_parsed_at":"2023-10-03T07:42:16.852Z","dependency_job_id":"d604ffdd-fc92-488a-93d1-3a5ea4e5a3c1","html_url":"https://github.com/juntossomosmais/frontend-guideline","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/juntossomosmais%2Ffrontend-guideline","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/juntossomosmais%2Ffrontend-guideline/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/juntossomosmais%2Ffrontend-guideline/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/juntossomosmais%2Ffrontend-guideline/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/juntossomosmais","download_url":"https://codeload.github.com/juntossomosmais/frontend-guideline/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247823658,"owners_count":21002117,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["code-style","coding-style","css","frontend","frontend-guide","frontend-guidelines","good-practices","hacktoberfest","html","javascript","patterns","patterns-design","react","typescript","vue"],"created_at":"2024-08-01T12:02:37.637Z","updated_at":"2025-04-08T10:31:44.421Z","avatar_url":"https://github.com/juntossomosmais.png","language":null,"funding_links":[],"categories":["Others"],"sub_categories":[],"readme":"![juntos-somos-devs](https://user-images.githubusercontent.com/3603793/131751022-fda4146c-9ada-4ad0-82fc-d8f0a73acd3f.png)\n\n# Front-end - Guideline\n\n\u003ca href=\"https://juntossomosmais.github.io/frontend-guideline/\" target=\"_blank\"\u003eGuideline Webpage\u003c/a\u003e\n\n[![GitHub contributors](https://img.shields.io/badge/ghpages-online-brightgreen.svg)](https://juntossomosmais.github.io/frontend-guideline/)\n[![GitHub contributors](https://img.shields.io/github/contributors/juntossomosmais/frontend-guideline.svg)](https://github.com/juntossomosmais/frontend-guideline/graphs/contributors)\n\n\u003e \"Every line of code should appear to be written by a single person, no matter the number of contributors.\" - Chinese Proverb.\n\nThe following document describes generic rules of writing in development languages that we use on our Front-end projects, that HTML, CSS, JavaScript, React, and Vue\n\nThe idea of this repository is not to be a complete guideline, the target is just to help developers who participate in our projects to be able to inform the coding standards used.\n\nAs this is a live document, some rules may not have been applied in old projects and changes can occur at any time.\n\n## We are hiring! 🔥\n\nIf you are looking opportunities as Front-end Developer we are hiring!\n\nYou can [check all our job opportunities](https://www.linkedin.com/company/juntos-somos-mais/jobs/) and apply if you like it 😁\n\nThis is our [Front-end Challenge](https://github.com/juntossomosmais/frontend-challenge)\n\n## 📖 Summary\n\n1. [General Code Patterns](#1-general-code-patterns)\n2. [Architecture](#2-architecture)\n3. [Git](#3-git)\n4. [HTML](#4-html)\n5. [CSS](#5-css)\n6. [JavaScript](#6-javascript)\n7. [React](#7-react)\n8. [Vue](#8-vue)\n9. [Storybook](#9-storybook)\n10. [Testing](#10-testing)\n11. [Typescript](#11-typescript)\n\n---\n\n## 1. General Code Patterns\n\n- 1.0 [Prettier](#10-prettier)\n- 1.1 [Code Syntax](#11-code-syntax)\n- 1.2 [Refactoring](#12-refactoring)\n- 1.3 [Imports](#13-imports)\n\n### 1.0 Prettier\n\nWe use [Prettier](https://prettier.io/) to format our code, and we have a [shared rule to validade this](https://github.com/juntossomosmais/time-out-market/tree/main/packages/linters#prettier)\n\n### 1.1 Code Syntax\n\nUse soft tabs with two spaces. You need to configure your editor for this.\n\n**✅ Good:**\n\n```js\nconst obj = {\n  prop: 'value',\n  prop2: 'value2',\n  prop3: 'value3',\n}\n```\n\n```css\n.foo {\n  color: red;\n}\n```\n\n```html\n\u003cdiv\u003e\n  \u003cp\u003eHello World\u003c/p\u003e\n\u003c/div\u003e\n```\n\n**❌ Bad:**\n\n```js\nconst obj = {\n    prop: 'value',\n    prop2: 'value2',\n    prop3: 'value3',\n}\n```\n\n```css\n.foo {\n    color: red;\n}\n```\n\n```html\n\u003cdiv\u003e\n    \u003cp\u003eHello World\u003c/p\u003e\n\u003c/div\u003e\n```\n\n### 1.2 Refactoring\n\nRefactoring makes part of JSMLover's way of being, doing it every day and task by task. We have good practices and conditions to do that, though.\n\n```js\nif(!isWholeCodeCoveraged) return\n```\n- We can only refactor codes that have tests (and that tests!), which means 100% coverage! This way, we can improve or code safely. \n\n- Keep the current tests and make them pass! \nOnce the current code is tested and can be refactored. We must make sure that the new changes will not break the current tests. \n\n### 1.3 Imports\n\nIf the data to be imported belongs to the **same module/scope**, use **relative path**.\n\n#### Relative Path Example\n\n`HeaderButton.js importing style from header/styles.css`\n\n```sh\n┣ 📂 src/components \\\n┣ ┣ 📂 header \\\n┣ ┃ ┣ 📂 components\n┣ ┃ ┣ ┣ 📂 Buttons\n┣ ┃ ┣ ┣ ┣ 📜 HeaderButton.js\n┣ ┃ ┣ ┣ ┣ 📜 RedirectButton.js\n┣ ┃ ┣ ┣ ┣ 📜 EspecificButton.js\n┣ ┃ ┣ ┣ 📂 Card \n┣ ┃ ┣ ┣ 📂 Modal \n┣ ┃ ┣ 📂 __tests__\n┣ ┃ 📜 index.js\n┣ ┃ 📜 styles.css\n┣ ┃ 📜 index.stories.mdx\n┣ ┃ 📜 index.spec.js\n```\n\nuse this:\n\n```js\nimport { HeaderButtonClass } from '../../../styles'\n```\n\nIf the data to be imported belongs to **another module/scope**, use an **absolute path**.\n\n#### Absolute Path Example\n\n`HeaderPopup.js` importing an enum from `src/enum/errors.js`\n\n```sh\n┣ 📂 src \\\n┣ ┣ 📂 components \\\n┣ ┃ ┣ 📂 header \\\n┣ ┃ ┃ ┣ 📂 components\n┣ ┃ ┃ ┃ ┣ 📂 Card \n┣ ┃ ┃ ┃ ┣ 📂 Popup\n┣ ┃ ┃ ┃ ┃ ┣ 📜 HeaderPopup.js\n┣ ┃ ┃ ┃ ┃ ┣ 📜 RedirectPopup.js\n┣ ┃ ┃ ┃ ┃ ┣ 📜 EspecificPopup.js\n┣ ┃ ┃ ┣ 📂 __tests__\n┣ ┃ ┣ 📜 index.js\n┣ ┃ ┣ 📜 styles.scss\n┣ ┃ ┣ 📜 index.stories.mdx\n┣ ┃ ┣ 📜 index.spec.js\n┣ ┃ 📂 enums \\\n┣ ┃ ┣ 📜 errors.js\n┣ ┃ ┣ 📜 pages.js\n┣ ┃ ┣ 📜 routes.js\n┣ ┃ ┣ 📜 environments.js\n┣ ┃ ┣ 📜 index.js\n```\n\nuse this:\n\n```js\nimport { UploadError } from '~/enums/errors.js'\n```\n\n## 2. Architecture\n\nThe proper architecture for projects, and how to create and name files and folders.\n\n- 2.1 [File Name](#21-file-name)\n- 2.2 [Folder Architecture](#22-folder-architecture)\n\n### 2.1 File Name\n\n**✅ Good:**\n\n- `UserProfile/UserProfile.vue`\n- `UserProfile/index.js`\n- `UserProfile/index.ts`\n- `UserProfile/styles.js`\n- `UserProfile/UserProfile.scss`\n- `UserProfile/UserProfile.stories.mdx`\n\n**❌ Bad:**\n\n- `UserProfile/component.vue`\n- `src/UserProfile.js`\n- `UserProfile/component.ts`\n- `UserProfile/style.scss`\n- `UserProfileStyles.js`\n- `UserProfile/UserProfile.mdx`\n\n\u003ca name=\"architecture-folder\"\u003e\u003c/a\u003e\n\n### 2.2 Folder Architecture\n\n#### Global Components/Helpers\n\nGlobal Components should only be components used in more than one place.\n\nFor example:\n\n```sh\n┣ 📂 src/components \\\n┣ ┣ 📂 component \\\n┣ ┃ ┣ 📜 index.js\n┣ ┃ ┣ 📜 styles.js\n┣ ┃ ┣ 📜 index.spec.js\n┣ ┃ ┣ 📜 index.stories.mdx\n```\n\n#### Scoped Components\n\nWe need to add inside `pages/**/components`, for example, all components that is need used just a context or scope, like a components that be used just a some place or specific page.\n\nIf we need to used the component again in another context or page it need to be moved to `src/components`.\n\nFor example:\n\n```sh\n┣ 📂 pages \\\n┣ ┣ 📂 Home \\\n┣ ┃ ┣ 📜 Home.js \\\n┣ ┃ ┣ 📜 Home.style.js \\\n┣ ┃ ┣ 📜 Home.spec.js \\\n┣ ┃ ┣ 📂 components \\\n┣ ┃ ┃ ┣ 📂 UserProfile \\\n┣ ┣ ┃ ┃ ┣ 📜 UserProfile.style.js \\\n┣ ┣ ┃ ┃ ┣ 📜 UserProfile.spec.js \\\n┣ ┣ ┃ ┃ ┣ 📜 UserProfile.stories.mdx \\\n```\n\n#### Scoped Files \n\nWe need to add inside `pages/**/{utils, helpers, context, hooks, etc...}` and use `camelCase` as **Naming Convention**.\n\nFor example:\n\n```sh\n┣ 📂 pages \\\n┣ ┣ 📂 Home \\\n┣ ┃ ┣ 📂 utils \\\n┣ ┃ ┣ ┣ 📜 someUtils.js\n┣ ┃ ┣ 📂 helpers \\\n┣ ┣ ┣ ┣ 📜 someHelper.js\n┣ ┃ ┣ 📂 hooks \\\n┣ ┣ ┣ ┣ 📜 useSomeHook.js\n```\n\nIf we need use these files again in another context or page it need to be moved to `src/{utils, helpers, context, hooks}`.\n\n```sh\n┣ 📂 src\n┣ ┣ 📂 utils \\\n┣ ┃ ┣ 📜 someUtils.js\n┣ ┣ 📂 helpers \\\n┣ ┃ ┣ 📜 someHelper.js\n┣ ┣ 📂 hooks \\\n┣ ┃ ┣ 📜 useSomeHook.js\n```\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n\u003ca name=\"git\"\u003e\u003c/a\u003e\n\n## 3. Git\n\n- 3.0 [Commitlint](#30-git-commitlint)\n- 3.1 [Commit Messages](#31-commit-messages)\n\n### 3.0 Git Commitlint\n\nWe use [Commitlint](https://commitlint.js.org/#/) to validate our commit messages, and we have a [shared rule to validade this](https://github.com/juntossomosmais/time-out-market/tree/main/packages/linters#commitlint)\n\n### 3.1 Commit Messages\n\nIn order to facilitate the contribution of anyone in a project, all commit messages must be in **English**.\n\nWe also use [conventional commit messages](https://www.conventionalcommits.org/en/v1.0.0/), that is, the commit message must be in the form of a sentence, with the first word being an action, and the rest of the sentence a describing text.\n\nWe must always commit in lower-case. We are using a [shared rule to validade this](https://github.com/juntossomosmais/time-out-market/blob/main/packages/linters/src/commitlint.config.js).   \n\n**✅ Good:**\n\n```powershell\ngit commit -m \"feat: allow provided config object to extend configs\"\ngit commit -m \"docs: correct spelling of CHANGELOG\"\ngit commit -m \"feat(lang): add the Portuguese language\"\n```\n\n**❌ Bad:**\n\n```powershell\ngit commit -m \"Add placeholder on input\"\n```\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n## 4. HTML\n\nWe main reference for HTML good patterns is [W3C](https://www.w3.org/TR/html/) and [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element), behind these docs we could learn a lot with semantic and another good practices.\n\n- 4.1 [HTML Component Scope](#41-html-component-scope)\n\n### 4.1 HTML Component Scope\n\nWe don't guest the scope of HTML components inside page, so when we start a new component, we should use a semantic tag, like `section` or `article` for example, to be able to starting to use the heading tags by context.\n\n**✅ Good:**\n\n```html\n\u003csection class=\"component\"\u003e\n  \u003ch1 class=\"title\"\u003eTitle\u003c/h1\u003e\n  \u003cp\u003eParagraph\u003c/p\u003e\n\u003c/section\u003e\n```\n\n**❌ Bad:**\n\n```html\n\u003cdiv class=\"component\"\u003e\n  \u003ch4 class=\"title\"\u003eTitle\u003c/h4\u003e\n  \u003cp\u003eParagraph\u003c/p\u003e\n\u003c/div\u003e\n```\n\n## 5. CSS\n\nThe tips above could be used in any CSS framework or preprocessor, like SCSS, Styled Components and etc\n\n- 5.0 [CSS Stylelint](#50-css-stylelint)\n- 5.1 [CSS Code Syntax](#51-css-syntax)\n- 5.2 [CSS Declaration Order](#52-css-declaration-order)\n- 5.3 [CSS Class Names](#53-css-class-names)\n- 5.4 [CSS Good Practices](#54-css-good-practices)\n- 5.5 [CSS Media Queries](#55-css-media-queries)\n- 5.6 [Spacing and size of image and components](#56-spacing-and-size-of-image-and-components)\n  - 5.6.1 [Dynamic values](#561-dynamic-values)\n  - 5.6.2 [Images and well defined components](#562-images-and-well-defined-components)\n- 5.7 [Avoid using shorthand properties](#57-avoid-using-shorthand-properties)\n\n\n### 5.0 CSS Stylelint\n\nWe use [Stylelint](https://stylelint.io/) to validate our code, and we have a [shared rule to validade this](https://github.com/juntossomosmais/time-out-market/tree/main/packages/linters#stylelint)\n\n### 5.1 CSS Syntax\n\nKeep one declaration per line.\n\n**✅ Good:**\n\n```scss\n.selector-1,\n.selector-2,\n.selector-3 {\n  ...\n}\n```\n\n**❌ Bad:**\n\n```scss\n.selector-1, .selector-2, .selector-3 {\n  ...\n}\n```\n\nSeparate each ruleset by a blank line.\n\n**✅ Good:**\n\n```scss\n.selector-1 {\n  ...\n}\n\n.selector-2 {\n  ...\n}\n```\n\n**❌ Bad:**\n\n```scss\n.selector-1 {\n  ...\n}\n.selector-2 {\n  ...\n}\n```\n\nUse lowercase and avoid specifying units is zero-values.\n\n**✅ Good:**\n\n```scss\n.selector-1 {\n  color: #aaa;\n  margin: 0;\n}\n```\n\n**❌ Bad:**\n\n```scss\n.selector-1 {\n  color: #aaaaaa;\n  margin: 0px;\n}\n```\n\n### 5.2 CSS Declaration Order\n\nThe declarations should be added in alphabetical order.\n\n**✅ Good:**\n\n```scss\n.selector {\n  background: #fff;\n  border: #333 solid 1px;\n  color: #333;\n  display: flex;\n  height: 200px;\n  margin: 5px;\n  padding: 5px;\n  width: 200px;\n}\n```\n\n**❌ Bad:**\n\n```scss\n.selector {\n  padding: 5px;\n  height: 200px;\n  background: #fff;\n  margin: 5px;\n  width: 200px;\n  color: #333;\n  border: #333 solid 1px;\n  display: flex;\n}\n```\n\n### 5.3 CSS Class Names\n\nKeep class lowercase and use dashes to separate the classname.\n\n**✅ Good:**\n\n```scss\n.page-header { ... }\n```\n\n**❌ Bad:**\n\n```scss\n.pageHeader { ... }\n.page_header { ... }\n```\n\nIs a good idea follows a [BEM naming convention](http://getbem.com/introduction/) to avoid conflicts with other components. If you are using CSS-in-JS like a Styled-Component, you can use BEM if you need to nesting elements inside parent.\n\nThe main pattern is use single dash to element name, double underline to element block and double dash to style modification.\n\n**✅ Good:**\n\n```scss\n/* Good */\n.page-header__title { ... }\n.page-header--active { ... }\n\n.button--active { ... }\n```\n\n**❌ Bad:**\n\n```scss\n.page-header-title { ... }\n.page-header-active { ... }\n\n.active { ... }\n.primary { ... }\n```\n\nDashes and underline serve as natural breaks in related class. Prefix class based on the closest parent or base class.\n\n**✅ Good:**\n\n```scss\n.nav { ... }\n.nav__item { ... }\n.nav__link { ... }\n```\n\n**❌ Bad:**\n\n```scss\n.item-nav { ... }\n.link-nav { ... }\n```\n\nAvoid giving too short names for class and always choose meaningful names that provide the class function.\n\n**✅ Good:**\n\n```scss\n/* Good */\n.button { ... }\n.page-header { ... }\n.progress-bar { ... }\n```\n\n**❌ Bad:**\n\n```scss\n.s { ... }\n.btn { ... }\n.ph { ... }\n.block { ... }\n```\n\n### 5.4 CSS Good Practices\n\nAvoid use values like colors, spacing and etc directly in the elements, use variables instead, and it can be CSS variables or some preprocessor variables, always check the context.\n\n**✅ Good:**\n\n```scss\n.button {\n  color: var(--color-primary);\n  padding: var(--space-sm);\n}\n```\n\n**❌ Bad:**\n\n```scss\n.button {\n  color: #333;\n  padding: 16px;\n}\n```\n\nNever use IDs to style elements, always use classes instead.\n\n**✅ Good:**\n\n```scss\n.header { ... }\n.section { ... }\n```\n\n**❌ Bad:**\n\n```scss\n#header { ... }\n#section { ... }\n```\n\nDo not style directly the elements, it will create a lot of conflicts, always use classes instead.\n\n**✅ Good:**\n\n```scss\n.form-control { ... }\n.header { ... }\n.section { ... }\n```\n\n**❌ Bad:**\n\n```scss\ninput[type=\"text\"] { ... }\nheader\nsection\n```\n\nAvoid nesting elements, because it decrease performance and increase the specificity of the CSS, always use classes instead.\n\n**✅ Good:**\n\n```scss\n.navbar { ... }\n.nav { ... }\n.nav__item { ... }\n.nav__link { ... }\n```\n\n**❌ Bad:**\n\n```scss\n.navbar ul { ... }\n.navbar ul li { ... }\n.navbar ul li a { ... }\n```\n\n### 5.5 CSS Media Queries\n\nStart the development with generic rules and add media queries inside scope using mobile first. Also is important\nkeep the media queries as close to their relevant rule sets whenever possible.\n\n**✅ Good:**\n\n```scss\n.navbar {\n  margin-bottom: var(--space);\n\n  @media (min-width: 480px) {\n    padding: 10px;\n  }\n\n  @media (min-width: 768px) {\n    position: absolute;\n    top: 0;\n    left: 0;\n  }\n\n  @media (min-width: 992px) {\n    position: fixed;\n  }\n}\n```\n\n**❌ Bad:**\n\n```scss\n.navbar {\n  position: fixed;\n  top: 0;\n  left: 0;\n\n  @media (max-width: 767px) {\n    position: static;\n    padding: var(--space-sm);\n  }\n}\n```\n\n### 5.6 Spacing and size of image and components\n\nIs a commom problem to use width and height or all dynamic or all hardcoded, but each one has it own purpose. We should avoid using magic numbers at all times.\n\n\u003e _\"Magic numbers are those numbers that appear in code without explanation, but that 'magically' make things work.\"_  Are numbers that dont have a why, but works.\n\n\n### 5.6.1 Dynamic values\nIf you are using padding, margin, gap should use our [Atomium tokens](https://juntossomosmais.github.io/atomium/?path=/docs/getting-started-tokens--docs). Any space that override it values must be validated once our Design System is well defined around these values and our UX Teams guide must follow it.\nIcons, width and height that are relative to our Design System or that have sizes based on calc upon our spacing variable must also use [Atomium tokens](https://juntossomosmais.github.io/atomium/?path=/docs/getting-started-tokens--docs) instead of magic numbers.\n\n**✅ Good:**\n\n```scss\n.logout__icon {\n  height: var(--spacing-xxlarge);\n  width: var(--spacing-xxlarge);\n}\n\n.icon__button {\n  min-width: var(--spacing-giant);\n} \n```\n\n**❌ Bad:**\n\n```scss\n.logout__icon {\n  height: 25px;\n  width: 25px;\n}\n\n.icon__button {\n  min-width: 34px;\n}\n```\n\n### 5.6.2 Images and well defined components\nIf you are using a image, or a component that has a design size and it sizes at maximum vary from desktop/mobile, use the value of it:\n\n**✅ Good:**\n\n```scss\n.shopfrom__banner {\n  height: 900px;\n  width: 480px;\n  \n  @media (min-width: 991px) {\n    height: 740px;\n    width: 240px;\n  }\n}\n```\n\n**❌ Bad:**\n\n```scss\n.shopfrom__banner {\n  height: calc(4 * var(--spaceing-xxxlarge);\n  width: calc(2 * var(--spacing-giant);\n}\n\n.shopfrom__banner {\n  height: 480px;\n  width: 170px;\n  \n  @media (max-width: 746px) {\n    height: 740px;\n    width: 240px;\n  }\n  \n  @media (max-width: 991px) {\n    height: 900px;\n    width: 320px;\n  }\n  \n  @media (max-width: 1024px) {\n    height: 980px;\n    width: 300px;\n  }\n}\n```\n\n## 5.7 Avoid using shorthand properties\n\nShorthand properties are great for reducing CSS, but they can also make the code harder to read and override. It's better to use longhand properties to make the code more readable and maintainable.\n\n**✅ Good:**\n\n```scss\n.element {\n  margin-left: auto;\n  margin-right: auto;\n}\n```\n\n**❌ Bad:**\n\n```scss\n.element {\n  margin: 0 auto;\n}\n```\n\nShorthands can be used when you want to apply the same value to multiple properties.\n\n\n**[⬆ back to summary](#-summary)**\n\n## 6. JavaScript\n\n- 6.0 [JavaScript Eslint](#60-javascript-eslint)\n- 6.1 [Javascript Code Syntax](#61-javascript-code-syntax)\n- 6.2 [Variables](#62-variables)\n- 6.3 [Descriptive validations (if)](#63-descriptive-validations-if)\n- 6.4 [Avoid multiple if's](#64-avoid-multiple-ifs)\n- 6.5 [Code Comments](#65-code-comments)\n- 6.6 [Avoid errors while destructuring](#66-avoid-errors-while-destructuring)\n- 6.7 [Prefer early return](#67-prefer-early-return)\n\n### 6.0 JavaScript Eslint\n\nWe use [ESLint](https://eslint.org/) to validate our code, and we have a [shared rule to validade this](https://github.com/juntossomosmais/time-out-market/tree/main/packages/linters#eslint)\n\n### 6.1 JavaScript Code Syntax\n\nNever use semicolons.\n\n**✅ Good:**\n\n```js\nconst foo = 'bar'\nconst baz = 'qux'\nconst func = () =\u003e {}\n```\n\n**❌ Bad:**\n\n```js\nconst foo = 'bar';\nconst baz = 'qux';\nconst func = () =\u003e {};\n```\n\nAlways use single quotes or template literals\n\n**✅ Good:**\n\n```js\nconst string = 'foo'\nconst template = `foo`\n```\n\n**❌ Bad:**\n\n```js\nconst string = \"foo\"\nconst template = \"foo\"\n```\n\n\u003ca name=\"variables\"\u003e\u003c/a\u003e\n\nFor strict equality checks `===` should be used in favor of `==`.\n\n**✅ Good:**\n\n```js\nif (foo === 'foo') {\n  statement\n}\n```\n\n**❌ Bad:**\n\n```js\nif (foo == 'foo') {\n  statement\n}\n```\n\nAdd empty lines between blocks of code.\n\n**✅ Good:**\n\n```js\nconst foo = () =\u003e {\n  // do something\n}\n\nconst bar = () =\u003e {\n  // do something\n}\n```\n\nAdd empty lines between blocks of `if` statements.\n\n**✅ Good:**\n\n```js\nif (foo) {\n  // do something\n}\n\nif (bar) {\n  // do something\n}\n```\n\n**❌ Bad:**\n\n```js\nif (foo) {\n  // do something\n}\nif (bar) {\n  // do something\n}\n```\n\nAdd empty lines between before return statements.\n\n**✅ Good:**\n\n```js\nconst foo = () =\u003e {\n  const bar = 'bar'\n\n  return bar\n}\n```\n\n**❌ Bad:**\n\n```js\nconst foo = () =\u003e {\n  const bar = 'bar'\n  return bar\n}\n```\n\n**❌ Bad:**\n\n```js\nconst foo = () =\u003e {\n  // do something\n}\nconst bar = () =\u003e {\n  // do something\n}\n```\n\nRemove empty lines between groups of `const`, `let` and `var` declarations, but use empty lines between the groups.\n\n**✅ Good:**\n\n```js\nconst foo = 'foo'\nconst bar = 'bar'\n\nlet qux = 'qux'\nlet quux = 'quux'\n```\n\n**❌ Bad:**\n\n```js\nconst foo = 'foo'\n\nconst bar = 'bar'\n\nlet qux = 'qux'\n\nlet quux = 'quux'\n```\n\n### 6.2 Variables\n\nUse meaningful, pronounceable, and in **English** variable names.\n\n**✅ Good:**\n\n```js\nconst currentDate = new Date().toLocaleDateString('pt-BR')\n```\n\n**❌ Bad:**\n\n```js\nconst xpto = new Date().toLocaleDateString('pt-BR')\n```\n\n\u003ca name=\"descriptive-validations\"\u003e\u003c/a\u003e\n\n### 6.3 Descriptive validations (if)\n\nCreating const to describe validations.\n\n**✅ Good:**\n\n```js\nconst hasFullUserName = user.firstName \u0026\u0026 user.lastname\n\nif (hasFullUserName) {\n  //do awesome something\n}\n```\n\n**❌ Bad:**\n\n```js\nif (user.firstName \u0026\u0026 user.lastname) {\n  //do something\n}\n```\n\n\u003ca name=\"avoid-multiple-ifs\"\u003e\u003c/a\u003e\n\n### 6.4 Avoid multiple if's\n\nUse an execution map instead a multiple if validations.\n\n**✅ Good:**\n\n```js\nconst messagingChannels = {\n  whatsapp: (message) =\u003e {\n    // send message to whatsapp\n  },\n  email: (message) =\u003e {\n    // send message to email\n  }\n}\n\nconst sendMessage = (message, channel) =\u003e {\n  const send = messagingChannels[channel];\n  return send \u0026\u0026 send(message);\n}\n```\n\n**❌ Bad:**\n\n```js\nconst sendWhatsapp = (message) =\u003e {\n  // send message to whatsapp\n}\n\nconst sendEmail = (message) =\u003e {\n  // send message to email\n}\n\nconst sendMessage = (message, channel) =\u003e {\n  if (channel === 'whatsapp') {\n    sendWhatsapp(message)\n  } else if (channel === 'email') {\n    sendEmail(message)\n  }\n}\n```\n\n### 6.5 Code Comments\n\nAvoid writing comments to explain the code. Use comments to answer “Why?” instead “How?”. Some cases you could write a code comment: warnings, complex expressions, or unusual decision clarification.\n\n**✅ Good:**\n\n```js\n  const TIME_IN_SECONDS = 60 * 40 // 40 minutes\n\n  // xxxx@xxxx.xxx\n  const regex = /^[a-z0-9.]+@[a-z0-9]+\\.[a-z]+\\.([a-z]+)?$/i\n\n  const calculateProductsPrice = () =\u003e {\n    // do something\n  }\n```\n\n**❌ Bad:**\n\n```js\n  // This coolFunction calculates the prices of the products\n  const coolFunction = () =\u003e {\n    // do something\n  }\n```\n\n\u003ca name=\"errors-destructuring\"\u003e\u003c/a\u003e\n### 6.6 Avoid errors while destructuring\n\nIts a common mistake destructuring while the object is null or undefined, the destructuring will throw an error.\n\n**✅ Good:**\n\n```js\n  const { age } = { ...null } // undefined\n  const { age } = null || {} // undefined\n\n  // other values won't throw an error\n  const { emptyString } = '';\n  const { nan } = NaN;\n  const { emptyObject } = {};\n\n  function foo(bar = {}) {\n    const { age } = bar;\n  }\n  \n  foo() // undefined\n  \n```\n\n**❌ Bad:**\n\n```js\n  const { age } = null // will throw an typeError\n  const { age } = undefined // will throw an typeError\n```\n\n\u003ca name=\"early-return\"\u003e\u003c/a\u003e\n### 6.7 Prefer early return\n\nPrefer early return over conditional wrapping to enhance code readability and reduce nesting.\n\n**✅ Good:**\n\n```js\nfunction foo() {\n  if (!someValidation) return // or throw error\n\n  // do something here\n\n  if (!anotherValidation) return\n\n  return 'bar'\n}\n```\n\n**❌ Bad:**\n\n```js\nfunction foo() {\n  if (someValidation) {\n    // do something here\n\n    if (anotherValidation) {\n      return 'bar'\n    }\n  }\n}\n```\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n## 7. React\n\n- 7.1 [Keys in lists](#71-keys-in-lists)\n- 7.2 [useState functional updates](#72-usestate-functional-updates)\n- 7.3 [useEffect dependencies array](#73-useeffect-dependencies-array)\n- 7.4 [Readable components](#74-readable-components)\n- 7.5 [Styled Component Naming Convention](#75-styled-component-naming-convention)\n- 7.6 [Using Styled Component in React Components](#76-using-styled-component-in-react-components)\n- 7.7 [Enums](#77-avoid-compare-directly-strings)\n- 7.8 [Using spread operator](#78-using-spread-operator)\n- 7.9 [Conditional Rendering](#79-conditional-rendering)\n  - 7.9.1 [Using short circuit](#791-using-short-circuit)\n  - 7.9.2 [Using ternary operator](#792-using-ternary-operator)\n- 7.10 [Enforce Boolean Attribute Notation in JSX](#710-enforce-boolean-attribute-notation-in-jsx)\n\n### 7.1 Keys in lists\n\nThe best way to pick a key is to use a string that uniquely identifies a list item among its siblings.\n\nIt is not recommended to use indexes for keys if the order of items can change. This can negatively affect performance and can cause problems with the component's state.\n\n**✅ Good:**\n\n```js\narray.map((item, index) =\u003e \u003cComponent key={item.id} {...item}\u003e)\n```\n\n**❌ Bad:**\n\n```js\narray.map((item, index) =\u003e \u003cComponent key={index} {...item}\u003e)\n```\n\n### 7.2 useState functional updates\n\nIf the new state is calculated using the previous state, you can pass a function to setState. Thus avoiding competition between states and preventing possible bugs.\n\n**✅ Good:**\n\n```js\nconst [number, setNumber] = useState(1)\n\nreturn (\n  \u003cdiv\u003e\n    \u003ch1\u003e{number}\u003c/h1\u003e\n    \u003cbutton onClick={() =\u003e setNumber((prevNumber) =\u003e prevNumber + 1)}\u003e\n      Increase\n    \u003c/button\u003e\n    \u003cbutton onClick={() =\u003e setNumber((prevNumber) =\u003e prevNumber - 1)}\u003e\n      Decrease\n    \u003c/button\u003e\n  \u003c/div\u003e\n)\n```\n\n**❌ Bad:**\n\n```js\nconst [number, setNumber] = useState(1)\n\nreturn (\n  \u003cdiv\u003e\n    \u003ch1\u003e{number}\u003c/h1\u003e\n    \u003cbutton onClick={() =\u003e setNumber(number + 1)}\u003eIncrease\u003c/button\u003e\n    \u003cbutton onClick={() =\u003e setNumber(number - 1}\u003eDecrease\u003c/button\u003e\n  \u003c/div\u003e\n)\n```\n\n### 7.3 useEffect dependencies array\n\nUse the useEffect dependency array to trigger side effects, and make your code cleaner.\n\n**✅ Good:**\n\n```js\nconst [page, setPage] = useState(1)\n\nuseEffect(() =\u003e {\n  requestListUser()\n  // calls useEffect when page state changes\n}, [page])\n\nreturn (\n  \u003cdiv\u003e\n    \u003cbutton onClick={() =\u003e setPage((prevState) =\u003e prevState + 1)}\u003e\n      Next Page\n    \u003c/button\u003e\n  \u003c/div\u003e\n)\n```\n\n**❌ Bad:**\n\n```js\nconst [page, setPage] = useState(1)\n\nuseEffect(() =\u003e {\n  requestListUser()\n}, [])\n\nconst requestListUser = () =\u003e {\n  setPage((prevState) =\u003e prevState + 1)\n  // ...\n  // any code to return user list\n}\n\nreturn (\n  \u003cdiv\u003e\n    \u003cbutton onClick={() =\u003e requestListUser()}\u003eNext Page\u003c/button\u003e\n  \u003c/div\u003e\n)\n```\n\n### 7.4 Readable components\n\nAvoid creating very large components.\nIf possible divided into sub-components, improving the understanding and reading of the code.\n\n**✅ Good:**\n\n```js\nconst Screen = () =\u003e (\n  \u003cContainer\u003e\n    \u003cHeader\u003e\n      \u003cTitle /\u003e\n      \u003cButton background=\"black\"\u003eFilter\u003c/Button\u003e\n    \u003c/Header\u003e\n\n    \u003cMain\u003e\n      \u003cList\u003e\n        {data.map((item) =\u003e (\n          \u003cCard key={item.id} name={item.name} /\u003e\n        ))}\n      \u003c/List\u003e\n    \u003c/Main\u003e\n  \u003c/Container\u003e\n)\n```\n\n**❌ Bad:**\n\n```js\nconst Screen = () =\u003e (\n  \u003cBox padding={1}\u003e\n    \u003cBox alignItems=\"center\"\u003e\n      \u003cText\u003eTitulo\u003c/Text\u003e\n      \u003cButton background=\"black\"\u003eFilter\u003c/Button\u003e\n    \u003c/Box\u003e\n    \u003cBox marginTop={5}\u003e\n      \u003cBox\u003e\n        {data.map((item) =\u003e (\n          \u003cBox key={item.id}\u003e\n            \u003cText color=\"red\"\u003e{item.name}\u003c/Text\u003e\n          \u003c/Box\u003e\n        ))}\n      \u003c/Box\u003e\n    \u003c/Box\u003e\n  \u003c/Box\u003e\n)\n```\n\n### 7.5 Styled Component Naming Convention\n\nUse PascalCase as a convention in styled-components\n\n**✅ Good:**\n\n```js\nexport const CustomText = styled.p`\n  color: 'red'\n`\n```\n\n**❌ Bad:**\n\n```js\nexport const customText = styled.p`\n  color: 'red'\n`\n```\n\n### 7.6 Using Styled Component in React Components\n\nImport Styled Component as `S`\n\n**✅ Good:**\n\n```tsx\nimport * as S from './styles'\n\nconst MyComponent = () =\u003e (\n  \u003cS.CustomText\u003e\n    text example\n  \u003c/S.CustomText\u003e\n)\n```\n\n**❌ Bad:**\n\n```tsx\nimport * as Style from './styles'\n\nconst MyComponent = () =\u003e (\n  \u003cStyle.CustomText\u003e\n    text example\n  \u003c/Style.CustomText\u003e\n)\n\n\nimport { CustomText } from './styles'\n\nconst MyComponent = () =\u003e (\n  \u003cCustomText\u003e\n    text example\n  \u003c/CustomText\u003e\n)\n```\n\n### 7.7 Avoid compare directly strings\n\nWhen know all possible values we can use enum to achieve better readability and control.\n\n**✅ Good:**\n\n```tsx\nconst FEEDBACK = {\n  CORRECT: 'correct',\n  INCORRECT: 'incorrect',\n}\n\nconst MyComponent = (type) =\u003e {\n  const text = type === FEEDBACK.CORRECT ? '😎' : '😢'\n  \n  return (\n    \u003cEmoji\u003e\n      {text}\n    \u003c/Emoji\u003e\n  )\n}\n```\n\n**❌ Bad:**\n\n```tsx\nconst MyComponent = (type) =\u003e {\n  const text = type === 'correct' ? '😎' : '😢'\n\n  return (\n    \u003cEmoji\u003e\n      {text}\n    \u003c/Emoji\u003e\n  )\n}\n```\n\n### 7.8 Using spread operator\n\nWhen creating a component wrapper we can spread the types from our original component. That way the wrapper extends all the props from the original component automatically. This is useful to avoid creating a custom interface for our wrapper with missing props from the original component.\n\n**✅ Good:**\n\n```tsx\nimport { MenuItem, TextField } from '@mui/material';\nimport { TextFieldProps } from '@mui/material';\n\nexport type SelectOption = { value: string; label: string, id: string, };\n\nexport type SelectProps = TextFieldProps \u0026 {\n  options: SelectOption[];\n};\n\nconst Select = ({ options, ...props }: SelectProps) =\u003e {\n  return (\n    \u003cTextField {...props}\u003e\n      {options.map((option) =\u003e (\n        \u003cMenuItem key={option.id} value={option.value}\u003e\n          {option.label}\n        \u003c/MenuItem\u003e\n      ))}\n    \u003c/TextField\u003e\n  );\n};\n```\n\n**❌ Bad:**\n\n```tsx\nimport { MenuItem, TextField } from '@mui/material';\n\nexport type SelectOption = { value: string; label: string, id: string, };\n\nexport type SelectProps = {\n  options: SelectOption[];\n  disabled: boolean;\n  onChange: () =\u003e void;\n  value: string;\n  onBlur: () =\u003e void;\n};\n\nconst Select = ({\n  options,\n  disabled,\n  onChange,\n  value,\n  onBlur,\n} : SelectProps) =\u003e {\n  return (\n    \u003cTextField\n      disabled={disabled}\n      onChange={handleOnChange}\n      value={value}\n      onBlur={handleOnBlur}\n    \u003e\n      {options.map((option) =\u003e (\n        \u003cMenuItem key={option.id} value={option.value}\u003e\n          {option.label}\n        \u003c/MenuItem\u003e\n      ))}\n    \u003c/TextField\u003e\n  );\n};\n```\n\n### 7.9 Conditional Rendering\n\n#### 7.9.1 Using short circuit\n\nwhen we only need to validate a logical case and return a component, we can directly use the short circuit\n\n**✅ Good:**\n\n```tsx\nimport { useState } from 'react'\nimport Welcome from '../components/Welcome'\n\nconst HomePage = () =\u003e {\n  const [showWelcome, setShowWelcome] = useState(true)\n  return showWelcome \u0026\u0026 \u003cWelcome /\u003e\n};\n```\n\n**❌ Bad:**\n\n```tsx\nimport { useState } from 'react'\nimport Welcome from '../components/Welcome'\n\nconst HomePage = () =\u003e {\n  const [showWelcome, setShowWelcome] = useState(true)\n  return showWelcome ? \u003cWelcome /\u003e : \u003c\u003e\u003c/\u003e\n};\n```\n\n#### 7.9.2 Using ternary operator\n\nwhen we need to validate two logical cases and return a component in both cases, we can use the ternary instead of the if...else\n\n**✅ Good:**\n\n```tsx\nimport { useState } from 'react'\nimport Welcome from '../components/Welcome'\nimport Dashboard from '../components/Dashboard'\n\nconst HomePage = () =\u003e {\n  const [showWelcome, setShowWelcome] = useState(false)\n  return showWelcome ? \u003cWelcome /\u003e : \u003cDashboard /\u003e\n};\n```\n\n**❌ Bad:**\n\n```tsx\nimport { useState } from \"react\"\nimport Welcome from \"../components/Welcome\"\nimport Dashboard from \"../components/Dashboard\"\n\nconst HomePage = () =\u003e {\n  const [showWelcome, setShowWelcome] = useState(false)\n\n  if (!showWelcome) {\n    return \u003cDashboard /\u003e\n  }\n\n  return \u003cWelcome /\u003e\n};\n```\n\n### 7.10 Enforce Boolean Attribute Notation in JSX\n\nConsistently pass the value for boolean attributes in JSX to ensure clarity and readability.\n\n**✅ Good:**\n\n```tsx\n\u003cInput type=\"text\" disabled={true} /\u003e\n```\n\n**❌ Bad:**\n\n```tsx\n\u003cInput type=\"text\" disabled /\u003e\n```\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n## 8. Vue\n\n- 8.1 [Keys in lists](#81-keys-in-lists)\n- 8.2 [Use Computed for real time updates](#82-use-computed-for-real-time-updates)\n- 8.3 [Multi-word component names](#83-multi-word-component-names)\n- 8.4 [Prop definitions](#84-prop-definitions)\n- 8.5 [Vue property decorator](#85-vue-property-decorator)\n\n### 8.1 Keys in lists\n\nThe best way to pick a key is to use a string that uniquely identifies a list item among its siblings.\n\nIt is not recommended to use indexes for keys if the order of items can change. This can negatively affect performance and can cause problems with the component's state.\n\n**✅ Good:**\n\n```html\n\u003ctemplate v-for=\"item in items\"\u003e\n   \u003cComponent :key=\"item.id\" v-bind=\"{...item}\"\u003e\n\u003c/template\u003e\n```\n\n**❌ Bad:**\n\n```html\n\u003ctemplate v-for=\"(item, index) in items\"\u003e\n   \u003cComponent :key=\"index\" v-bind=\"{...item}\"\u003e\n\u003c/template\u003e\n```\n\n### 8.2 Use Computed for real time updates\n\nIf you need listen changes at data use computeds instead of methods\n\n**✅ Good:**\n\n```js\ncomputed: {\n  fullName(){\n    return `${this.name} ${this.lastName}`\n  }\n}\n```\n\n**❌ Bad:**\n\n```js\nmethods: {\n  fullName() {\n    this.fullName = `${this.name} ${this.lastName}`\n  }\n}\n```\n\n### 8.3 Multi-word component names\n\nComponent names should always be multi-word, except for root App components, and built-in components provided by Vue.\n\nThis prevents conflicts with existing and future HTML elements, since all HTML elements are a single word.\n\n**✅ Good:**\n\n```js\nexport default {\n  name: 'TodoItem',\n  // ...\n}\n```\n\n**❌ Bad:**\n\n```js\nexport default {\n  name: 'Todo',\n  // ...\n}\n```\n\n### 8.4 Prop definitions\n\nIn committed code, prop definitions should always be as detailed as possible, specifying at least type(s).\n\n**✅ Good:**\n\n```js\nexport default {\n  status: {\n    type: String,\n    required: true\n  }\n  // ...\n}\n```\n\n**❌ Bad:**\n\n```js\nexport default {\n  props: ['status']\n  // ...\n}\n```\n\n### 8.5 Vue property decorator\n\nVue prop decorator should not be used, use Vue.extend instead\n\n**✅ Good:**\n\n```js\n\u003cscript lang=\"ts\"\u003e\nimport Vue from 'vue'\n\nexport default Vue.extend({\n  name: 'MyComponent',\n})\n\u003c/script\u003e\n```\n\n**❌ Bad:**\n\n```js\n\u003cscript lang=\"ts\"\u003e\nimport { Component, Vue } from 'vue-property-decorator'\n\n@Component({})\nexport default class MyComponent extends Vue {\n  name: 'MyComponent'\n}\n\u003c/script\u003e\n```\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n## 9. Storybook\n\n- 9.1 [Story file](#91-story-file)\n\n### 9.1 Story file\n\nCreate a file with the same name of your component, or index, and with the suffix `.stories.mdx`.\n\n**✅ Good:**\n\n- Button.stories.mdx\n- Dialog/index.stories.mdx\n\n**❌ Bad:**\n\n- Input.mdx\n- Dialog/index.mdx\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n## 10. Testing\n\n- 10.1 [Write tests with \"it\"](#101-write-tests-with-it)\n- 10.2 [Using test-id](#102-using-test-id)\n- 10.3 [Selecing component](#103-selecting-component)\n\n### 10.1 Write tests with \"it\"\n\nWrite tests with the alias \"it\" instead \"test\" method.\n\n**✅ Good:**\n\n```js\ndescribe('yourModule', () =\u003e {\n  it('should do this thing', () =\u003e {});\n});\n```\n\n**❌ Bad:**\n\n```js\ndescribe('yourModule', () =\u003e {\n  test('if it does this thing', () =\u003e {});\n});\n```\n\n### 10.2 Using test-id\n\nTo get components during tests we use `test-id` custom html attributes with unique id and our own convention deeply inpired by the css's BEM.\nTo define the `test-id` to a component use the follow structure: `[page-name||component-name]__[element-type]--[type]`\n\n**✅ Good:**\n\n- forgot-password__input--email\n- header__select--cnpjList\n- login__button--forgot-password\n\n**❌ Bad:**\n\n- forgot-email-input\n- header__cnpjList\n- button--forgot-password\n\n### 10.3 Selecting component\n\nTo select a component in order to test a behavior of to trigger any event we must use ou `test-id` attribute to select it.\n\n**✅ Good:**\n\n```js\ndescribe('yourModule', () =\u003e {\n  it('should do trigger click event', () =\u003e {\n    const button = wrapper.find('[data-testid=\"login__button--forgot-password\"]')\n  });\n});\n```\n\n**❌ Bad:**\n\n```js\ndescribe('yourModule', () =\u003e {\n  it('should do trigger click event', () =\u003e {\n    const button = wrapper.find('button.btn-primary')\n  });\n});\n```\n\n**[⬆ back to summary](#-summary)**\n\n---\n\n## 11. Typescript\n\n- 11.1 [Do not use any type](#111-do-not-use-any-type)\n- 11.2 [Naming convention](#112-naming-convention)\n  - 11.2.1 [PascalCase](#1121-pascalcase)\n  - 11.2.2 [Prefix for Type, Interface, and Enum](#1122-prefix-for-type-interface-and-enum)\n- 11.3 [Exporting types](#113-exporting-types)\n- 11.4 [Types within a file](#114-types-within-a-file)\n- 11.5 [Increase legible](#115-increase-legible)\n- 11.6 [Type or Interface](#116-type-or-interface)\n\n### 11.1 Do not use any type\n\nAvoid using `any` type. It's best to use the type that is more specific whenever possible. Prefer to use `unknown` when necessary.\n\n**✅ Good:**\n\n```ts\nfunction foo(x: unknown) {}\n\nfunction foo(): unknown {}\n```\n\n**❌ Bad:**\n\n```ts\nfunction foo(x: any) {}\n\nfunction foo(): any {}\n```\n\n### 11.2 Naming convention\n\n#### 11.2.1 PascalCase\n\nFor convention, use PascalCase for type names.\n\n**✅ Good:**\n\n```ts\ntype TMyBeautifulType = {\n  name: string\n  age: number\n}\n```\n\n**❌ Bad:**\n\n```ts\ntype myBeautifulType = {\n  name: string\n  age: number\n}\n```\n\nThe same applies to Enum keys.\n\n**✅ Good:**\n\n```ts\nenum EUserResponse {\n  NotSuccess = 0,\n  Success = 1,\n}\n```\n\n**❌ Bad:**\n\n```ts\nenum UserResponse {\n  NOT_SUCCESS = 0,\n  success = 1,\n}\n```\n\n#### 11.2.2 Prefix for Type, Interface, and Enum\n\nAll Type, Interface, and Enum names must include a prefix to improve readability and consistency:\n- **Type**: Prefix with `T`\n- **Interface**: Prefix with `I`\n- **Enum**: Prefix with `E`\n\n**✅ Good:**\n\n```ts\ntype TMyBeautifulType = {\n  name: string\n  age: number\n}\n\ninterface IOrderList {\n  orderNumber: number\n  seller: string\n}\n\nenum EUserResponse {\n  NotSuccess = 0,\n  Success = 1,\n}\n```\n\n**❌ Bad:**\n\n```ts\ntype MyBeautifulType = {\n  name: string\n  age: number\n}\n\ninterface OrderList {\n  orderNumber: number\n  seller: string\n}\n\nenum UserResponse {\n  NotSuccess = 0,\n  Success = 1,\n}\n```\n\n### 11.3 Exporting types\n\nDo not export types/functions unless you need to use it across multiple components.\n\n### 11.4 Types within a file\n\nWithin a file, type definitions should come first.\n\n**✅ Good:**\n\n```ts\n// imports...\n\ntype TMyBeautifulType = {\n  name: string\n  age: number\n}\n\n// rest of the file...\n```\n\n**❌ Bad:**\n\n```ts\n// imports...\n\n// part of the file...\n\ntype MyBeautifulType = {\n  name: string\n  age: number\n}\n\n// rest of the file...\n```\n\n### 11.5 Increase legible\n\nCreate a type for increase legible\n\n**✅ Good:**\n\n```ts\ntype TPersonType = {\n  name: string\n  age: number\n  birthDate: string\n};\n\nconst Person = ({ name, age, birthDate }: TPersonType) =\u003e {\n  // ...\n};\n```\n\n**❌ Bad:**\n\n```ts\nconst Person = ({\n  name,\n  age,\n  birthDate,\n}: {\n  name: string,\n  age: number,\n  birthDate: string,\n}) =\u003e {\n  // ...\n};\n```\n\n\n### 11.6 Type or Interface\nWe use `type` when its usage is inside the same file and `interface` when it is exported.\n\n**✅ Good:**\n\n```ts\ntype TProductType = {\n  name: string\n  code: number\n  value: string\n};\n\nexport interface IOrderList {\n orderNumber: number\n seller: string\n products: TProductType[]\n}\n```\n\n**❌ Bad:**\n\n```ts\ninterface ProductType {\n  name: string\n  code: number\n  value: string\n};\n\nexport type OrderList = {\n orderNumber: number\n seller: string\n products: ProductType[]\n}\n```\n\nWe follow the principle the official [TypeScript doc](https://www.typescriptlang.org/play#example/types-vs-interfaces):\n\u003e _For publicly exposed types, it's a better call to make them an interface._\n\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjuntossomosmais%2Ffrontend-guideline","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjuntossomosmais%2Ffrontend-guideline","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjuntossomosmais%2Ffrontend-guideline/lists"}