#02 Estrutura avançada de um projeto Angular - O guia completo | [Série] Criando um SaaS do ZERO

E aí, meus amigos, tudo bem com vocês? Samuel Rizon Pro aqui e hoje a gente vai dar mais um passo na nossa série de como criar um SaaS do zero com Angular e Supabase. E hoje a gente vai falar sobre como organizar um projeto em Angular, como estruturar e definir as pastas, os arquivos, as nomenclaturas. Isso é algo muito importante a se pensar antes de iniciar um projeto, coisa que muita gente não pensa e acaba no final, no meio do projeto, já não tem como mais organizar. Então A gente vai deixar isso muito bem definido, como que a gente vai seguir aqui no nosso SaaS. E antes de começar, eu tenho que primeiramente agradecer a cada um de vocês que curtiram, compartilharam, comentaram no vídeo, deram ideias. A gente vai falar sobre isso aqui, mas obrigado, gente, obrigado mesmo pelo apoio. E se você ainda não se inscreveu no canal, se inscreve, ativa o sininho, dá o like e compartilha, porque esse é um conteúdo que eu nunca encontrei sobre Angular na internet. Então eu vou fazer um conteúdo de verdade aqui para vocês hoje. Vou mostrar a vocês como que eu estruturo um projeto em Angular completamente escalável. E se você perdeu o vídeo passado, a gente vai falar um pouco sobre os comentários dele agora. Se você perdeu, assiste lá no canal depois desse aqui. Lá eu ensinei como que configura o projeto, como que cria um projeto do zero, expliquei a ideia desse SaaS, tá bom? Então não se esqueça de ir lá depois e assistir, fechou? Vamos falar dos comentários então do vídeo passado. Começando por esse aqui do Gleison, que ele discordou daí do commit que ela fez. Olha que legal, ela fez um commit de CI para atualizar, né, o pre-releasement, todas as configurações, mas ele falou que deveria ser shore e ele tá completamente certo. Aí a veia achou aqui, eu não percebi na hora, passou despercebido gravando vídeo aqui, a gente acaba pensando em várias coisas ao mesmo tempo. Então vamos corrigir isso agora, tá? Aqui o projeto ele tá da mesma forma que tava quando eu terminei o vídeo. A gente tem alguns commits aqui, existem várias formas da gente editar um commit no Git, tá bom? Aqui eu vou fazer da forma mais fácil, que é pela interface do Visual Studio Code, mas existem outras formas, a gente pode falar isso num vídeo só sobre Git, tá bom? Mas primeiro eu vou desfazer o último commit aqui, eu acho que o último, exato, o último commit não é o commit que a Yaya fez, então o que que eu faço? Ele tá no staged aqui, eu vou só passar ele para change. Vou copiar isso aqui, tá bom? Vou deixar aqui salvo esse commit. E agora eu vou desfazer de novo porque eu acho que é esse aqui que é o CI. Perfeito, esse é o commit que o Gleison falou que a gente deveria ter colocado short. Concordo. Então a gente vai vir aqui na nossa ferramenta, na nossa extensão que eu mostrei no vídeo passado. Eu vou vir aqui em short, vou copiar essa parte aqui, colar na descrição, salvar. O commit está atualizado. Eu vou comitar, fechar aqui, copiar esse commit, colar e comitar novamente. Pronto, fechou, corrigimos esse problema, tá bom, Gleison? Agora é um show. E outro que o Funciondev comentou: é muito bom, dava para entregar, integrar com o pagamento Stripe, aí seria um SaaS completo. E cara, eu me esqueci realmente de colocar isso nas nossas etapas. Então eu vou vir aqui no projeto E sim, a gente vai configurar Stripe, a gente vai configurar pagamento. Eu creio que a gente vai fazer isso aqui depois que a gente fizer autenticação. Então eu falar sobre o Supabase, depois eu vou falar, fazer a tela de cadastro, autenticação. E eu acho que a próxima etapa seria já a gente entrar com um pagamento. Então, configuração do Stripe, tração do Stripe. Depois a gente pode adicionar mais alguns detalhes aqui. Mas a gente vai ter que configurar um Stripe, criar conta, né, criar conta no Stripe, fazer a configuração do Stripe e integrar, integrar Supabase Stripe com o Supabase e o projeto. Perfeito, vou colocar aqui 567. Então, pessoal, vamos falar sobre pagamento também. O SaaS que não tem pagamento é não é um SaaS, a gente tem que ter pagamento e a gente espera receber pelo nosso trabalho. Então esses foram os comentários do vídeo passado. E o que que a gente vai fazer hoje? Então eu já alterei o último commit, tá bom? A gente vai publicar esse projeto no GitHub e a gente vai falar sobre organização do projeto, pastas, arquivos, nomenclaturas, etc. E já de início eu já vou fazer essa organização criando o módulo de autenticação aqui dentro do sistema. Combinado? Então vamos lá, já alteramos o último commit e a gente vai publicar esse projeto no GitHub pelo VS Code aqui mesmo. Clicou aqui, mybarbershop, eu vou publicar em um repositório privado e tá lá no GitHub, tá publicando aqui, tá no GitHub, fechou? Tá publicado o projeto no GitHub para a gente deixar salvo. Agora ele não tá só mais na minha máquina, Mas vamos falar sobre estrutura de pastas e arquivos então. Quando a gente abre aqui o nosso projeto, eu já dei um zoom aqui para ficar fácil de enxergar, mas quando a gente abre um projeto do Angular, quando a gente cria ele, normalmente ele vem aqui com todos esses arquivos. Esse aqui é um welcome do NX, tá bom? Então a gente já vai começando tirando isso aqui daqui, eu não preciso disso aqui, tá? A gente tem um app routes São as rotas principais da nossa aplicação. Web.config, que agora com standalone ele tá sendo bastante utilizado. E a gente tem esse AppComponent aqui, ó. Esse AppComponent a gente não vai utilizar, a gente não vai criar nada dentro dele. Então a gente pode já remover isso aqui, já remover esse next welcome aqui. A gente vai pegar essa parte aqui, a gente também não precisa do ng-zone. Na verdade, a gente vai excluir Todos esses arquivos, então vou excluir esse aqui, eu vou excluir esse aqui, eu vou excluir esse arquivo de teste aqui também, que é não, que não é necessário. Aqui eu vou ter um template e aqui eu vou colocar o router outlet. Aqui eu fecho e tá feito, salvei, pronto. Nosso app component, ele não precisa de muita coisa, ele só precisa de um router outlet porque ele vai direcionar as coisas baseado nas nossas rotas aqui do Angular, tá bom? Aqui ele não faz nada, a única coisa que ele faz é mostrar as coisas das páginas. Beleza, como que a gente estrutura um projeto? Como que eu faço normalmente? Eu vou ter aqui a pasta core, vou criar uma nova pasta chamada domain, e vou explicar cada uma delas para vocês. E eu tenho uma pasta shared e por último a pasta widget. Falando de estrutura de pastas, o que que eu vou ter aqui no meu domain? Eu vou ter uma pasta chamada auth, de autenticação. O domínio nada mais é do que os módulos. Hoje a gente não tem módulos mais, a gente aqui no arquivo.module, o Angular a gente tinha isso antes, mas com o Standardized a gente não tem. Mas são basicamente os módulos que a gente vai ter dentro do sistema. Então aqui provavelmente a gente vai ter um módulo de autenticação com as rotas de autenticação. A gente vai ter um módulo de admin para parte do barbeiro, né, gerenciar toda a parte da barbearia dele. E a gente vai ter um módulo público, que é o módulo dos usuários, que eles vão acessar a parte do sistema e as rotas que os usuários finais vão acessar o sistema, tá bom? Mas por enquanto a gente vai criar só esse auth aqui. Depois, no shared, o que que a gente vai ter? No shared a gente vai ter códigos que são compartilhados entre os módulos. Depois, no widget, a gente tem componentes, pipes e diretivas. Eu já vou criar essas pastas aqui, então: components, pipes, directives. Gente, sempre tudo em inglês, tá bom? Falando sobre a nomenclatura, sempre em inglês, nada de código em português, nomes em português. Faça tudo, tudo o seu código, já falei isso no vídeo sobre commits código sempre todo em inglês, tá bom? Então widget, isso aqui é uma nomenclatura que a própria documentação do Angular recomenda. Antes a gente criava isso aqui para criar os módulos separados para cada componente, mas hoje com o standalone a gente só vai criar os componentes aqui. E eu gosto dessa nomenclatura, eu gosto de ter esses componentes, pipes e diretivas separados aqui, tá bom? Na pasta core a gente vai ter componentes, páginas diretivas e outros arquivos relacionados à parte, a parte que vão ser utilizados em todo o sistema. Então aqui no core a gente vai ter, por exemplo, uma pasta de componentes, e aqui provavelmente a gente vai ter o header da nossa aplicação. Então a gente vai ter um componente de header aqui, tá bom? Dentro do domain, como que eu normalmente organizo as pastas e os arquivos aqui? Eu vou ter uma pasta chamada APIs, eu vou ter uma pasta chamada Constants, eu vou ter uma pasta chamada Enums, eu vou ter uma pasta chamada Interface. Se for necessário, eu crio também Dialogues. Eu vou ter uma pasta chamada Pages. Aqui eu também vou ter pasta chamada Components. Se for necessário, provavelmente eu vou ter uma chamada Services. Então eu separo muito bem em pastas toda a estrutura, e cada módulo aqui dentro do meu sistema eu vou ter essa mesma estrutura: APIs, components, constantes, dialogs, enums, interfaces, páginas e serviços. Então eu separo cada um deles dessa forma, tá bom? As páginas são páginas finais para o usuário, os componentes são componentes que a gente vai utilizar dentro das páginas. Então esses componentes estão aqui. Se eu precisar criar um componente que eu vou usar em outro módulo, a gente vai criar aqui no widgets, tá bom? Vou criar um componente aqui, vou mostrar para vocês daqui a pouquinho. Agora talvez você esteja se perguntando o que que essa pasta APIs faz e o que que essa pasta services faz. Eu gosto de separar em nomenclaturas, a nomenclatura do nome do arquivo os arquivos, a parte do código que vai fazer requisições ao backend e a parte do código que vai criar serviços e ter códigos mais complexos. Então eu não gosto de chamar tudo de service. Hoje a gente costuma criar um service para fazer a requisição para o backend e criar um service também para, por exemplo, gerenciar o loading da aplicação. Então eu não gosto de fazer isso, eu gosto de separar exatamente entre APIs e services. E aqui quando eu crio uma API, por exemplo, eu vou criar uma API para fazer no banco de dados, vou chamar auth.api.ts. E aqui quando eu criar um service, eu vou chamar ele de auth.api. Por quê? Porque dessa forma eu tenho, isso aqui vai ser um serviço, tá bom? Ele é um serviço que vai, só que ele é somente responsável por fazer requisições à minha API. No, aqui a gente vai utilizar o Supabase, mas se for um projeto normal, fazer requisições ao back-end, ele vai botar o HTTP client aqui, vai fazer as requisições no back-end. Mas eu posso ter um serviço também que eu vou chamar de auth.service. Esse auth.service, ng-service, auth.service, esse cara vai ser o meu serviço principal de autenticação. É aqui que eu vou salvar o meu usuário na aplicação. É aqui que eu vou gerenciar o estado desse usuário na aplicação inteira. Eu vou acessar esse usuário pelo, por esse serviço de autenticação. Vocês conseguem entender a diferença entre eu colocar uma chamada e uma requisição no backend aqui dentro desse serviço e uma chamada e uma requisição aqui? Dá para entender que são funcionalidades diferentes? Eu tenho um serviço para gerenciar o meu usuário, a autenticação do meu sistema, e Eu tenho um serviço só para fazer requisições backend, então eu gosto de fazer isso, tá bom? Constantes, cara, arquivos de constante eu uso bastante. Sempre que eu preciso colocar um texto fixo no sistema, eu vou utilizar uma constante. Então é sempre que eu precisar criar uma constante, eu vou criar constante, por exemplo, user.constant.ts, sempre com a mesma nomenclatura. O nome do arquivo tem o nome de onde ele faz parte, da pasta dele. Dialogues é a mesma coisa, eu vou criar um componente, mas não vai ser.component, vai ser.dialogues. Enums, a mesma coisa. Se eu precisar criar um enum, por exemplo, userStatus.enum.ts. E aí aqui falando sobre enums e falando sobre nomenclaturas, isso aqui é uma coisa muito legal. Eu gosto de criar enums sempre com prefixo E. Então eu vou criar um export enum EUserStatus. E aí aqui a gente vai sempre ter algo relacionado a isso. Enums sempre maiúsculos, tá bom? Aqui o texto eu gosto de deixar minúsculo, ele vai ficar maiúsculo só a parte onde eu vou utilizar o enum, tá? Salvei. Eu sempre uso essa nomenclatura de E aqui. E a mesma coisa eu uso para interface. Então, por exemplo, quando eu tiver meu User.interface aqui, export interface User, e aí aqui eu vou criar a interface do meu usuário. Eu sempre gosto de colocar isso aqui, só que eu aprendi com o Blaise, aquele cara que comentou no vídeo passado. Ele, eu lembro dele utilizando isso, ele me mostrou e eu achei fantástico. E desde que eu aprendi, eu utilizo em todos os meus projetos, tá bom? Isso aqui é muito simples, é muito fácil. Por que que é simples e é fácil? Porque quando eu preciso usar um enum, imagina um sistema que tem, meus fatores tem vários enums, então eu tenho vários enums, 10, 20, 30 enums. Quando eu preciso usar um enum, eu coloco o e aqui e eu vou digitar, por exemplo, e use status. Quando eu der um e aqui, ele já mostra, ele já vai me listar todos os meus enums, porque eu tenho meu prefixo 'e' aqui, entendeu? Então aqui, ó, só digitei 'e', ele já apareceu, e user status já importou e já tá salvo. Simples, prático e rápido, não é mesmo? E a interface é a mesma coisa. Se eu preciso usar uma interface, eu coloco user, eu aperto 'i', e aí que ele já me dá o user aqui. Então, gente, é muito mais simples, é muito mais fácil. Eu recomendo vocês a utilizarem esse tipo de nomenclatura aqui também, tá bom? Deixa eu desfazer esse código aqui. Beleza, vamos fechar aqui tudo. E agora a gente vai falar sobre as páginas. Aqui a gente vai ter uma página de login, uma página de cadastro e uma página de esqueci minha senha, fechou? Para criar componentes em Angular, eu costumo usar uma extensão do NX. Então se eu vier aqui nas minhas extensões Eu tenho no NX aqui o NX Console. Essa extensão vai me deixar fazer isso aqui, ó. Quando eu venho aqui, NX Generate, eu escrevo schematics component. Então eu vou usar o schematic do próprio Angular para criar um componente. E aqui eu vou criar um componente de login. O estilo eu vou usar o CSS e eu vou descer tudo aqui e criar, em vez de ser um componente, ele vai ser uma página. Eu venho aqui em cima, clica em Generate. Pronto, página tá criada. Vou fechar aqui. Quando eu entro na página, eu vou dar um Enter e salvar aqui para ele formatar. Ele vai dar esse erro aqui, ó. Ele tá falando que a classe, né, ela deve ter o sufixo component por causa desse, dessa regra do S-Lint. Que que a gente vai ter que fazer? A gente vai ter que editar essa regra do S-Lint. Então a gente vai vir aqui no nosso S-Lint, a gente vai vir nas regras aqui do nosso, da parte do Angular, né? E vou dar um enter aqui, já tá trabalhando aqui para gente, ele já mostrar erro. Só que aqui a gente vai usar component, a gente vai usar page, e provavelmente a gente também vai ter dialog. Então esses são os que utiliza, a gente precisa adicionar mais, a gente adiciona. Mas assim que eu salvo, o Svelte já entendeu que eu posso criar componentes com o sufixo de page. Então criamos a parte de login, eu vou criar também a parte de cadastro. Então schematics component, seleciona aqui Sync App, que vai ser a parte de cadastro, SCSS, page, generate. Aqui ele já tá gerando com standalone, tá bem tranquilo. Beleza, por enquanto vamos deixar só essas duas aqui. Aqui eu vou ter as minhas páginas. Então eu provavelmente vou precisar também da parte de layout. Vou ter— eu costumo nas minhas aplicações separar os layouts. Então tem um layout de autenticação e eu tenho um layout do meu dashboard, da página principal da aplicação, e eu separo esses layouts aqui em core. Então eu vou criar layout, uma pasta chamada layout. Eu vou vir aqui criar um novo componente, schematic component, e aí eu vou chamar ele de alfa, só alfa. Por quê? Porque ele vai ser o alfa.layout. Show! Então eu tenho um alfa.layout, vou gerar ele aqui. E beleza, então agora eu tenho um layout chamado auth. Ele vai dar o erro, vai dar o erro, aquele mesmo erro, tá? Então eu venho aqui no S-Link, toda vez que eu precisar disso eu venho aqui e digito layout aqui, ele vai deixar eu criar um layout. Porque o que que esse auth layout vai fazer? Ele vai ser o esqueleto, né, das minhas páginas de autenticação, que a gente vai criar uma página de autenticação Deixa eu desenhar isso aqui para vocês, para ficar mais fácil. Então eu tenho minha página principal. O que que a gente vai fazer? A gente vai fazer uma página de autenticação simples. A gente vai ter um quadrado aqui centralizado na página com o texto de login, login, e o formulário de cadastro de login. Então eu vou ter aqui o e-mail e eu vou ter a minha senha. Então deixa eu— então eu tenho meu e-mail Copy e colo, eu tenho minha senha e depois eu tenho um botão aqui para fazer. E aí o Alf Layout ele vai cuidar dessa parte aqui por fora para não ter que ficar centralizando tudo. Então a minha página de login, a minha página de cadastro, eu vou cuidar dessa parte aqui de dentro. A parte do Alf Layout ele vai cuidar da parte aqui de fora para deixar tudo centralizado tanto no desktop quanto no mobile. Show, fácil de entender, né? Deixa eu criar aqui também com vocês e aproveitar e mostrar para vocês um serviço que eu normalmente utilizo em todas as minhas aplicações. Vou criar aqui service, que é o serviço de loading. Então eu vou vir aqui em Generate, isso que é Magic Service, e eu vou criar um loading. Loading, eu acho que eu não vou precisar fazer nenhuma outra opção. Eu costumo de marcar o flat porque eu gosto que ele cria a pasta. Então criei aqui o meu service de loading, então eu já tenho a pasta de loading E eu tenho meu loading service e o spec. Que que esse loading service vai fazer? Ele vai ser responsável por quando eu der um start nele, eu tenho um estado de loading na aplicação e eu consegui mostrar páginas de carregamento ou outras coisas desse tipo. O que que a gente vai fazer aqui? O Copano já tá falando para mim fazer dessa forma, não vou fazer, eu já vou fazer usando o Signal. Então eu vou ter uma variável chamada loading que vai receber um Signal false. Perfeito. E depois eu vou ter um start, não é emit, no Signal a gente vai usar set, e o stop, set false. Simples. Aqui eu já tenho meu componente de loading service e eu vou conseguir trabalhar nele toda vez que eu precisar fazer um load na minha aplicação. Importo ele na minha aplicação, dou um start e dou um stop quando precisa parar, tá bom? Então esse eu deixo aqui em shared porque eu vou usar ele na minha aplicação inteira. E aí outra coisa que eu tenho também, outra pasta que eu normalmente crio em shared, é uma pasta chamada utils. Aqui eu vou criar utilitários simples que eu vou utilizar no meu código, tá bom? E eu normalmente vou criar, por exemplo, vamos criar um text.util.date, date.util. Esse eu uso bastante. .ts. Como normalmente eu crio, eu dou um export class DateUtil, eu abro aqui, e aí que eu vou criar uma classe estática, getFormattedDate. Vamos só dar um exemplo aqui para vocês. É assim que eu crio as minhas classes de utilitários, porque quando eu precisar, por exemplo, fazer alguma coisa de útil utilizar esse serviço, eu vou vir aqui em Services, eu vou vir aqui na minha página de login e, por exemplo, no meu construtor, se eu precisar usar const DateUtil, vou informar aqui.getDate() e eu consigo já usar esse DateUtil. E aí, depois de importar isso aqui, vocês perceberam que a gente recebeu um erro, né? O que que tá falando aqui? É uma regra do ESLint para ele forçar a gente não utilizar o caminho exato aqui, ó, apps.mybarbershop, src/app e etc. O ideal é que a gente usa aqui um path e a gente consegue configurar isso tranquilamente aqui no nosso tsconfig. Show! A gente vai vir aqui em compiler options, eu vou dar um espaço aqui, paths. E como que eu costumo fazer? Eu costumo criar dessa forma aqui. Então eu vou usar o shared, e aí que eu vou vir aqui, eu vou utilizar esse My Barber Shop src/app/shared. Salvei, beleza. Aqui eu vou remover a importação e vou importar de novo. Quando eu fizer isso, olha que legal, ele já me deu aqui @shared. Então dessa forma a gente consegue importar de uma forma mais simples. Eu vou fazer isso aqui para as minhas outras pastas. A gente tem um core shared, a gente vai ter também o widget, widget, e a gente tem um domain também. Então vamos vir aqui, domain, feito. Então aqui tá feito, sempre que eu precisar importar alguma coisa, o TypeScript já vai entender que eu vou importar por isso aqui e a gente não tem aquele erro do anexo. Show? Então deu para entender essa parte de data? Eu vou fechar aqui também, vou fechar, e vamos dar uma olhada como que ficou a nossa estrutura aqui do nosso projeto. Recapitulando, a gente tem a pasta core que tem componentes, layouts, a gente vai ter constantes aqui também, várias outras coisas, muito do que a gente tem aqui no domain. O domain a gente vai ter pastas relacionadas aos módulos do nosso sistema. Esse é o módulo de autenticação, então eu vou ter as minhas APIs, componentes, constantes, dialogs, enums, interface, páginas, services e o que for preciso que está relacionado a esse módulo. Depois, na shared, eu também vou ter uma estrutura bem parecida, mas isso aqui vai ser compartilhado com outros módulos. E por último, eu tenho meus widgets, que são componentes, diretivas e pipes que eu vou utilizar na minha aplicação inteira. É só para me separar aqui do shared, para ficar bem mais separadinho essa parte aqui. E aí por último vamos só fazer uma última configuração aqui das nossas rotas, porque como eu já criei as minhas páginas de login, eu preciso criar as minhas rotas, certo? Então eu vou vir aqui e criar um auth.routes.ts. Show! Vai ser a mesma configuração dessa parte de rotas aqui, mas eu vou deixar isso de maiúsculo, auth.routes. E aí aqui dentro desse array a gente vai criar um path chamado login, que vai ser a nossa rota de login. A gente vai carregar um componente, não é children, é component. E aqui a gente vai carregar o /pages/login/loginPage. Perfeito. A gente também vai fazer a mesma coisa para parte de cadastro, então path sync up E vamos carregar o Sing App aqui. Depois que eu fiz isso, eu preciso importar essa parte de auth dentro da minha rota principal. Então aqui na minha parte principal, na minha rota principal, eu vou criar um path chamado auth. Load component, eu vou importar, só que eu não vou importar daqui, eu vou importar do meu core layout Auth. Por quê? Porque aqui eu vou ter o meu AuthLayout, eu vou ter um children, e aí agora vou importar um children. E aqui eu vou ter um loadPath vazio e um loadChildren que vão ser as minhas rotas de autenticação. Então eu vou ter o domain Auth, AuthRoles, e tá feito. Então vamos subir o projeto, nxs-my-barbershop. Show! A gente vai subir o projeto aqui, eu vou abrir aqui localhost:4200. Beleza, então aqui a gente tem o AlfWorks. Por que que isso aqui tá sendo mostrado? Porque exatamente o que tem, a gente tem aqui no AlfLayout. Então como que a gente faz para mostrar as minhas rotas de login? Aqui eu vou ter que importar o router module e aqui embaixo eu vou colocar router outlet. Eu já vou fechar aqui nas nossas versões do Angular, a gente já consegue fechar esse componente aqui. E aí quando a gente volta, ele ainda não tá mostrando. Por quê? Porque aqui no meu auth route eu preciso passar /login. Para eu não precisar passar /login, se eu entrar em auth, eu for direto para o login, eu posso só remover aqui e quando ele atualizar eu tenho o auth e eu tenho o meu login. Se eu vier aqui e alterar para Singapur, ele vai ir para minha página de cadastro. Show! Tá tudo funcionando, parte de configuração do nosso projeto. Já tá ok, a parte de estrutura já tá pronta também. E é isso, meus amigos, curtiram? Gostaram dessa parte de estruturar um projeto em Angular? Eu acho que, cara, isso é uma das coisas mais importantes que a gente tem que fazer. Eu tenho certeza que se você aplicar isso aqui nos seus projetos, vai ficar muito mais fácil de dar manutenção, muito mais fácil de criar coisas novas, porque aqui a gente tem um padrão bem definido. E se você ficou com alguma dúvida ou tem alguma sugestão ou faz alguma coisa diferente, cara, comenta aqui embaixo, quero saber como que vocês normalmente gerenciam, né, e criam toda essa estrutura de um projeto Angular. E se você não viu o vídeo anterior, corre lá para ver e fica ligado, porque no próximo vídeo a gente vai falar sobre o Transloco, que é uma forma da gente trabalhar no Angular com múltiplos idiomas. A gente vai deixar o nosso sistema pronto para isso e a gente vai usar o Transloco. Vocês vão ver como que é fácil, como que é simples trabalhar com Transloco e ter um aplicativo multi-idiomas. Então, para não perder, primeiro deixa o seu like, se inscreve no canal e ative o sininho e compartilha com um amigo que tá aprendendo o Anglo também. Você sabe aquela pessoa que tá começando no Anglo, tá querendo desenvolver e melhorar cada vez mais no Anglo? Compartilha essa série com ela, porque vocês me ajudam muito compartilhando esse vídeo com seus amigos. Fechou? Muito obrigado, até a próxima, valeu!