├── README.md ├── application-structure-and-ngModules.md ├── components.md ├── data-services.md ├── directives.md ├── lifecycle-hooks.md ├── naming.md ├── services └── single-responsibility.md /README.md: -------------------------------------------------------------------------------- 1 | ### Tradução livre do Style Guide do Angular 2 | 3 | https://angular.io/guide/styleguide 4 | 5 | - [Single responsibility](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/single-responsibility.md) 6 | - [Naming](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/naming.md) 7 | - [Application structure and NgModules](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/application-structure-and-ngModules.md) 8 | - [Components](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/components.md) 9 | - [Directives](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/directives.md) 10 | - [Services](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/services) 11 | - [Data Services](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/data-services.md) 12 | - [Lifecycle hooks](https://github.com/AlexandreWeber/angular.io-styleguide-PT-BR/blob/master/lifecycle-hooks.md) 13 | 14 | ### Para contribuir na tradução, acesse a aba Issues e assuma uma delas :) Para facilitar a busca ordene pelas Issues mais antigas. 15 | -------------------------------------------------------------------------------- /application-structure-and-ngModules.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AlexandreWeber/angular.io-styleguide-PT-BR/83a0d36879719d3628b83535a04c59171880e198/application-structure-and-ngModules.md -------------------------------------------------------------------------------- /components.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AlexandreWeber/angular.io-styleguide-PT-BR/83a0d36879719d3628b83535a04c59171880e198/components.md -------------------------------------------------------------------------------- /data-services.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AlexandreWeber/angular.io-styleguide-PT-BR/83a0d36879719d3628b83535a04c59171880e198/data-services.md -------------------------------------------------------------------------------- /directives.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AlexandreWeber/angular.io-styleguide-PT-BR/83a0d36879719d3628b83535a04c59171880e198/directives.md -------------------------------------------------------------------------------- /lifecycle-hooks.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AlexandreWeber/angular.io-styleguide-PT-BR/83a0d36879719d3628b83535a04c59171880e198/lifecycle-hooks.md -------------------------------------------------------------------------------- /naming.md: -------------------------------------------------------------------------------- 1 | ### Nomeação 2 | 3 | O padrão de nomeação de arquivos é extremamente importante para a manutenibilidade e legibilidade do projeto. Esse guia recomenda convenções de nomenclatura para nomes de arquivos e palavras-chave. 4 | 5 | ### Diretirezes gerais de nomeação 6 | 7 | **Faça:** Utilize nomes consistentes para todos as palavras-chave 8 | 9 | **Faça:** Siga um padrão que descreva a funcionalidade e o seu tipo. O padrão recomendado é *feature.type.ts.* 10 | 11 | **Por que?** Convenções de nomenclatura fornecem um forma consistente para encontrar conteúdos rapidamente. Consistência dentro de um projeto é vital. Consistência com um time é importante. Consistência através de toda a empresa fornece uma eficiência tremenda. 12 | 13 | **Por que?** As convenções de nomenclatura devem simplesmente ajudar a encontrar o código desejado mais rapidamente e facilitar a compreensão. 14 | 15 | **Por que?** Nomes de pastas e arquivos devem transmitir claramente sua intenção. Por exemplo, *app/heroes/hero-list.component.ts* deve conter um componente que gerencia uma lista de heróis. 16 | 17 | ### Separando nomes de arquivos com pontos e traços 18 | 19 | **Faça:** Use traços para separar palavras na descrição do nome. 20 | 21 | **Faça:** Use pontos para separar a descrição do nome do tipo do arquivo. 22 | 23 | **Faça:** Use nomes consistentes de tipos, por exemplo: *service, .component, .pipe, .module,* e *.directive*. Invente tipos adicionais se você precisar mas tome cuidade para não criar muitos. 24 | 25 | **Por que?** Os nomes dos tipos fornecem uma forma consistente para rapidamente identificar o que tem dentro daquele arquivo. 26 | 27 | **Por que?** Os nomes dos tipos facilitam a procurar de um arquivo especifico utilizando um editor através da pesquisa. 28 | 29 | **Por que?** Os nomes dos tipos não abreviados são descritivos e não ambiguo. Abreviações como *.srv, .svc,* e* .serv* podem ser confusos. 30 | 31 | **Por que?** Os nomes dos tipos fornecem uma correspondência de padrão para qualquer ferramente automatizada. 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /services: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/AlexandreWeber/angular.io-styleguide-PT-BR/83a0d36879719d3628b83535a04c59171880e198/services -------------------------------------------------------------------------------- /single-responsibility.md: -------------------------------------------------------------------------------- 1 | ### Responsabilidade Única 2 | 3 | Aplique o princípio de responsabilidade única [SRP](https://en.wikipedia.org/wiki/Single_responsibility_principle) para todos os componentes, serviços, pipes, diretivas e outros arquivos do projeto. Isso ajuda a manter a aplicação mais limpa, fácil de ler e manutenir, e mais fácil para testar. 4 | 5 | **Faça:** Defina apenas uma coisa, como um serviço ou componente, por arquivo. 6 | 7 | **Importante:** Considere limitar o arquivo a 400 linhas de código. 8 | 9 | **Por que?** Um componente por arquivo é muito mais fácil para ler, manter e evitar problemas na comparação de fontes quando utilizado um controlador de versão (git). 10 | 11 | **Por que?** Um componente por aquivo evita "bugs escondidos" que podem ocorrer com a combinação de um ou mais componentes em um mesmo arquivo onde eles podem compartilhar variáveis, criar closures inesperadas ou acoplamentos indesejados com dependências. 12 | 13 | **Por que?** Um componente único por aquivo pode ser a exportação padrão para aquele arquivo, o que facilita o lazy loading. 14 | 15 | O ponto principal é tornar código reutilizave, fácil de ler, e menos propenso a erros. 16 | 17 | O exemplo negativo abaixo define o AppComponent, inicializa a aplicação, define o modelo *Hero* e realiza uma requisição no servidor, tudo isso no mesmo arquivo. *Não faça isso.* 18 | 19 | **app/heroes/hero.component.ts** 20 | ``` 21 | /* avoid */ 22 | import { Component, NgModule, OnInit } from '@angular/core'; 23 | import { BrowserModule } from '@angular/platform-browser'; 24 | import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; 25 | 26 | class Hero { 27 | id: number; 28 | name: string; 29 | } 30 | 31 | @Component({ 32 | selector: 'app-root', 33 | template: ` 34 |

{{title}}

35 | 
{{heroes | json}}
36 | `, 37 | styleUrls: ['app/app.component.css'] 38 | }) 39 | class AppComponent implements OnInit { 40 | title = 'Tour of Heroes'; 41 | 42 | heroes: Hero[] = []; 43 | 44 | ngOnInit() { 45 | getHeroes().then(heroes => (this.heroes = heroes)); 46 | } 47 | } 48 | 49 | @NgModule({ 50 | imports: [BrowserModule], 51 | declarations: [AppComponent], 52 | exports: [AppComponent], 53 | bootstrap: [AppComponent] 54 | }) 55 | export class AppModule {} 56 | 57 | platformBrowserDynamic().bootstrapModule(AppModule); 58 | 59 | const HEROES: Hero[] = [ 60 | { id: 1, name: 'Bombasto' }, 61 | { id: 2, name: 'Tornado' }, 62 | { id: 3, name: 'Magneta' } 63 | ]; 64 | 65 | function getHeroes(): Promise { 66 | return Promise.resolve(HEROES); // TODO: get hero data from the server; 67 | } 68 | ``` 69 | É uma melhor prática distribuir o componente e suas classes suportadas em arquivos separados, cada um com a sua responsabilidade. 70 | 71 | **main.ts** 72 | ``` 73 | import { platformBrowserDynamic } from '@angular/platform-browser-dynamic'; 74 | 75 | import { AppModule } from './app/app.module'; 76 | 77 | platformBrowserDynamic().bootstrapModule(AppModule); 78 | ``` 79 | **app/app.module.ts** 80 | ``` 81 | import { NgModule } from '@angular/core'; 82 | import { BrowserModule } from '@angular/platform-browser'; 83 | import { RouterModule } from '@angular/router'; 84 | 85 | import { AppComponent } from './app.component'; 86 | import { HeroesComponent } from './heroes/heroes.component'; 87 | 88 | @NgModule({ 89 | imports: [ 90 | BrowserModule, 91 | ], 92 | declarations: [ 93 | AppComponent, 94 | HeroesComponent 95 | ], 96 | exports: [ AppComponent ], 97 | bootstrap: [ AppComponent ] 98 | }) 99 | export class AppModule { } 100 | ``` 101 | **app/app.component.ts** 102 | ``` 103 | import { Component } from '@angular/core'; 104 | 105 | import { HeroService } from './heroes'; 106 | 107 | @Component({ 108 | selector: 'toh-app', 109 | template: ` 110 | 111 | `, 112 | styleUrls: ['./app.component.css'], 113 | providers: [HeroService] 114 | }) 115 | export class AppComponent {} 116 | ``` 117 | **app/heroes/heroes.component.ts** 118 | ``` 119 | import { Component, OnInit } from '@angular/core'; 120 | 121 | import { Hero, HeroService } from './shared'; 122 | 123 | @Component({ 124 | selector: 'toh-heroes', 125 | template: ` 126 | 
{{heroes | json}}
127 | ` 128 | }) 129 | export class HeroesComponent implements OnInit { 130 | heroes: Hero[] = []; 131 | 132 | constructor(private heroService: HeroService) {} 133 | 134 | ngOnInit() { 135 | this.heroService.getHeroes() 136 | .then(heroes => this.heroes = heroes); 137 | } 138 | } 139 | ``` 140 | **app/heroes/shared/hero.service.ts** 141 | ``` 142 | import { Injectable } from '@angular/core'; 143 | 144 | import { HEROES } from './mock-heroes'; 145 | 146 | @Injectable() 147 | export class HeroService { 148 | getHeroes() { 149 | return Promise.resolve(HEROES); 150 | } 151 | } 152 | ``` 153 | **app/heroes/shared/hero.model.ts** 154 | ``` 155 | export class Hero { 156 | id: number; 157 | name: string; 158 | } 159 | ``` 160 | **app/heroes/shared/mock-heroes.ts** 161 | ``` 162 | import { Hero } from './hero.model'; 163 | 164 | export const HEROES: Hero[] = [ 165 | { id: 1, name: 'Bombasto' }, 166 | { id: 2, name: 'Tornado' }, 167 | { id: 3, name: 'Magneta' } 168 | ]; 169 | ``` 170 | Na medida que a aplicação cresce, essa regra se torna ainda mais importante. 171 | 172 | 173 | 174 | 175 | --------------------------------------------------------------------------------