👉 Livros sobre o assunto: Padrões de Arquitetura de Aplicações Corporativas: amzn.to/4bdMD7x Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos: amzn.to/4deMJNL Use a cabeça! Padrões de projetos (Design Patterns): amzn.to/3JzUGje Arquitetura Limpa (Clean Arch) amzn.to/3Viqw7v Clean Code amzn.to/3hHXVKY Estruturas de dados e algoritmos com JavaScript amzn.to/49FOzFd --- ✅ Segue lá no Instagram: instagram.com/devjunioralves/ ✅ Nossa comunidade no Discord: discord.com/invite/bVxW4Dhgrf
Se existisse conteúdos tão simplificados de temas tão falado mas pouco compreendido no início que comecei a estudar sobre isso o meu caminho seria menos doloroso, parabéns pelos conteúdos, estão irados!
Podia fazer um vídeo sobre strategy pattern, tipo usando uma strategy com http client autenticado pra acessar apis protegidas e outra sem pra acessar apis públicas
vc tem vários videos falando sobre adapter e gateway, só ta faltando um bom padrão pra injetar dependência, como por contexto ou por container como o inversify
Estou construindo uma biblioteca para React Native, ela tem um storage, uma external store e abstrai tudo isso em hooks. Eu uso apenas factory e inversão de dependência lá.
Que massa Yuri! 👊 Existem 2 tipos de Factory (do livro Design Patterns, link no comentário fixado) esse que mostrei no vídeo não é nenhum dos 2, é apenas uma Factory simples.
Devo criar adapters para todos ou a maioria dos packages que utilizo na minha aplicação? outra coisa voce consegue disponibilizar esse repositorio que foi usado no video?
Conteúdo de alta qualidade mano!! Parabéns!! Teria como nos próximos vídeos estruturar esse cenário como um caso de uso. Estou estudando clean arch afinco e estou com muitas dúvidas sobre como estruturar pastas, organizar arquivos para seguir da melhor forma a arquitetura limpa.
Bacana meu mano, sugiro só usar um pouco de material visual de apoio (diagramas, abstrações etc). Foi um negócio que percebi que faz total diferença na didática. Mas é isso, tá de parabéns!
Como sempre, um excelente vídeo. Mas quero colocar em pauta uma situação bastante comum. Supondo que você precisa lançar no mercado um produto para avaliar a retenção do público. Geralmente fazem um MVP pra isso e sei que poderia começar com inversão de dependência, addapters, factories etc. Mas o PM precisa de algo rápido pra ver se tem aceitação do público. Quais patterns adotar nessa situação para que possa ser flexível a adição desses design patters mais robustos posteriormente ? PS: já vi situações onde usam WordPress, Bubble para esse tipo de situação e depois investem no desenvolvimento de algo mais robusto. Mas supondo o cenário onde você já precise iniciar o projeto com uma estrutura aceitável para que possa ser flexível de alterações posteriores.
Excelente pergunta Mateus. Cara, aí é o famoso "depende". Mas vou tentar mostrar o porque. Se você e seu time tiverem conhecimento dos patterns, não vai adicionar tempo extra para implementar o MVP, desde o inicio com eles. Agora se não ainda não tiverem essa familiaridade, de fato para a rapidez necessária, não faria sentido. Agora, se é algo pequeno e que não vai crescer (ou vai ser substituído depois como você disse) também pode não fazer sentido aplicar esses padrões. Tudo depende do time, tempo e custo.
Brother, parabéns demais por sua contribuição ao mundo DEV. Excelente conteúdos: didáticos e profissionais. Tenho a seguinte dúvida: no padrão factory poderia ter um array de adapters?
@@devjunioralves legal, dessa forma pode deixar vários adapters já prontos e utilizar de acordo com a necessidade e contexto sem necessidade de criar um Factory para cada adapter... Bom creio que seja isso... Valeu mesmo...
que tal tornamos isso um pouco mais interessante que tal o próximo ser sobre desacoplamento com TDD então alem de projetarmos a inversão e padrões trazer testes para isso garantindo um funcionamento completo é um assunto bem legal de se aprender
Ola Junior, tenho gostado bastante do seus conteudos de react, estou aprendendo bastante, porém oque me frustou um pouco foi ver que tudo que eu aprendi na rocketseat, no ignite especialmente, voce implementa totalmente diferente kkkk, voce ja teve a experiencia de aprender por la, sabe porque dessa diferença? devo usar dessa forma do video, ou continua com as funcionais
Ainda sim, concorda que você ainda vai precisar ter essa parte em algum lugar no código? Em algum ponto vai precisar fazer essa requisição. Independente de onde seja, você vai precisar dessa inversão de dependencias.
gera muita complexidade a toa, faz no adapter uma instancia sem retornar o erro e faz a logica no service com useQuery ja pegando o erro ou o que for e aquela abraço , na instancia pega o erro de toda aplicação pelo axios com intercpetor
Sim, existem várias forma de fazer. O importante é entender seu contexto pra ver qual a melhor solução, talvez pra você seja muita complexidade, mas em outros projetos com escopos maiores, pode ser super válido.
Show!! Ao invés de passar LoadUserList como prop, seria interessante passar diretamente um UserService? Com todos os métodos ali inclusos, getUserById, getUsers, etc...
Poderia sim criar um UserService, eu particularmente não utilizo assim, mas não vejo problema nenhum. Só alterar a interface que o componente espera e ta tudo certo.
👉 Livros sobre o assunto:
Padrões de Arquitetura de Aplicações Corporativas:
amzn.to/4bdMD7x
Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos:
amzn.to/4deMJNL
Use a cabeça! Padrões de projetos (Design Patterns):
amzn.to/3JzUGje
Arquitetura Limpa (Clean Arch)
amzn.to/3Viqw7v
Clean Code
amzn.to/3hHXVKY
Estruturas de dados e algoritmos com JavaScript
amzn.to/49FOzFd
---
✅ Segue lá no Instagram:
instagram.com/devjunioralves/
✅ Nossa comunidade no Discord:
discord.com/invite/bVxW4Dhgrf
Se existisse conteúdos tão simplificados de temas tão falado mas pouco compreendido no início que comecei a estudar sobre isso o meu caminho seria menos doloroso, parabéns pelos conteúdos, estão irados!
Podia fazer um vídeo sobre strategy pattern, tipo usando uma strategy com http client autenticado pra acessar apis protegidas e outra sem pra acessar apis públicas
vc tem vários videos falando sobre adapter e gateway, só ta faltando um bom padrão pra injetar dependência, como por contexto ou por container como o inversify
Boa man, excelente sugestão!
Estou construindo uma biblioteca para React Native, ela tem um storage, uma external store e abstrai tudo isso em hooks.
Eu uso apenas factory e inversão de dependência lá.
Parabéns pelo conteúdo! 👏🏼👏🏼
Estou me aprofundando no react e seus vídeos são sensacionais.
Ótimo conteúdo! Espero que continue trazendo assuntos mais aprofundados assim!
Parabéns, muito bom. Extremamente semelhante ao que eu faço no vuejs. Até mesmo as nomenclaturas...
Ótimo vídeo!! 👏👏
Vc falou de Factory nos comentários e eu tinha ficado meio confuso em como aplicar, mas agr sanou minha dúvidas!
Que massa Yuri! 👊
Existem 2 tipos de Factory (do livro Design Patterns, link no comentário fixado) esse que mostrei no vídeo não é nenhum dos 2, é apenas uma Factory simples.
@@devjunioralves Ah, legal! Vou pesquisar mais sobre, então. Valeu!
Mano, seu canal é mt daora, tá me ajudando mt nos estudos, mt obrigado e continue
Devo criar adapters para todos ou a maioria dos packages que utilizo na minha aplicação? outra coisa voce consegue disponibilizar esse repositorio que foi usado no video?
Muito boa a explicação. Se puder traz um dia de Next Auth e JWT.
ja chego dando like, conteudo ta vindo mt bom!!! 👏👏
Valeu demais Mateus!!!
Muito bom, seria maneiro você trazer uma aplicação simples aplicando todos esses conceitos.
Quero trazer, só preciso de tempo pra elaborar um material massa hehe
eu apoio
Conteúdo de alta qualidade mano!! Parabéns!! Teria como nos próximos vídeos estruturar esse cenário como um caso de uso. Estou estudando clean arch afinco e estou com muitas dúvidas sobre como estruturar pastas, organizar arquivos para seguir da melhor forma a arquitetura limpa.
Muito massa o vídeo mano. Tu poderia fazer uma playlist explicando os principais design patterns em javascript, igual tu fez com o solid.
Bacana meu mano, sugiro só usar um pouco de material visual de apoio (diagramas, abstrações etc). Foi um negócio que percebi que faz total diferença na didática. Mas é isso, tá de parabéns!
Conteúdo sensacional
Muito obrigado Marcos! 👊
Como sempre, um excelente vídeo.
Mas quero colocar em pauta uma situação bastante comum.
Supondo que você precisa lançar no mercado um produto para avaliar a retenção do público. Geralmente fazem um MVP pra isso e sei que poderia começar com inversão de dependência, addapters, factories etc. Mas o PM precisa de algo rápido pra ver se tem aceitação do público.
Quais patterns adotar nessa situação para que possa ser flexível a adição desses design patters mais robustos posteriormente ?
PS: já vi situações onde usam WordPress, Bubble para esse tipo de situação e depois investem no desenvolvimento de algo mais robusto. Mas supondo o cenário onde você já precise iniciar o projeto com uma estrutura aceitável para que possa ser flexível de alterações posteriores.
Excelente pergunta Mateus.
Cara, aí é o famoso "depende". Mas vou tentar mostrar o porque.
Se você e seu time tiverem conhecimento dos patterns, não vai adicionar tempo extra para implementar o MVP, desde o inicio com eles.
Agora se não ainda não tiverem essa familiaridade, de fato para a rapidez necessária, não faria sentido.
Agora, se é algo pequeno e que não vai crescer (ou vai ser substituído depois como você disse) também pode não fazer sentido aplicar esses padrões.
Tudo depende do time, tempo e custo.
Muito bom man, manda muito!
Brother, parabéns demais por sua contribuição ao mundo DEV. Excelente conteúdos: didáticos e profissionais. Tenho a seguinte dúvida: no padrão factory poderia ter um array de adapters?
Nesse caso como é uma simple Factory, sim, não vejo problemas.
Valeu demais, de verdade! 👊
@@devjunioralves legal, dessa forma pode deixar vários adapters já prontos e utilizar de acordo com a necessidade e contexto sem necessidade de criar um Factory para cada adapter... Bom creio que seja isso... Valeu mesmo...
que tal tornamos isso um pouco mais interessante
que tal o próximo ser sobre desacoplamento com TDD
então alem de projetarmos a inversão e padrões
trazer testes para isso
garantindo um funcionamento completo
é um assunto bem legal de se aprender
Excelente sugestão mano, já tem uns vídeos assim, mas vou trazer mais, ainda mais com sua sugestão!
Cara vc sabe se ainda da para usar o chakra ui com o next 14 ? pq eu fiz um projeto aqui pela propria doc do next e deu erro
Ola Junior, tenho gostado bastante do seus conteudos de react, estou aprendendo bastante, porém oque me frustou um pouco foi ver que tudo que eu aprendi na rocketseat, no ignite especialmente, voce implementa totalmente diferente kkkk, voce ja teve a experiencia de aprender por la, sabe porque dessa diferença? devo usar dessa forma do video, ou continua com as funcionais
Traga mais
Peguei o bonde andando e custei a entender.
Top demais!
Nao era mais facil essa userList só receber um array de user e pronto?
Ainda sim, concorda que você ainda vai precisar ter essa parte em algum lugar no código? Em algum ponto vai precisar fazer essa requisição. Independente de onde seja, você vai precisar dessa inversão de dependencias.
@@devjunioralves muito obrigado pela resposta, assisto teu conteúdo sempre!
bora que eu to com fome
Boraaaa mano!!! 🚀
gera muita complexidade a toa, faz no adapter uma instancia sem retornar o erro e faz a logica no service com useQuery ja pegando o erro ou o que for e aquela abraço , na instancia pega o erro de toda aplicação pelo axios com intercpetor
Sim, existem várias forma de fazer. O importante é entender seu contexto pra ver qual a melhor solução, talvez pra você seja muita complexidade, mas em outros projetos com escopos maiores, pode ser super válido.
Show!! Ao invés de passar LoadUserList como prop, seria interessante passar diretamente um UserService? Com todos os métodos ali inclusos, getUserById, getUsers, etc...
Poderia sim criar um UserService, eu particularmente não utilizo assim, mas não vejo problema nenhum. Só alterar a interface que o componente espera e ta tudo certo.
Great
Thanks!