Como resolver problemas com SOLID? E o principal Anti-Pattern no ReactJS

[@devjunioralves]

👉Se liga nessas dicas: Estruturas de dados e algoritmos com JavaScript amzn.to/3hM0L1u Lógica de Programação e Algoritmos com JavaScript: amzn.to/48Cj65Z JavaScript: O Guia Definitivo: amzn.to/48jh9vp Como ser um programador melhor amzn.to/3POQ5fq Arquitetura Limpa (Clean Arch) amzn.to/3Viqw7v Clean Code amzn.to/3hHXVKY --- ✅ Segue lá no Instagram: instagram.com/devjunioralves/ ✅ Nossa comunidade no Discord: discord.com/invite/bVxW4Dhgrf

[@alexnascimento8435]

Os princípios existem para sabermos quando não usá-los também. Em componentes pequenos como esse sem complexidade lógica é um over engineering desgraçado fazer isso. Parabéns pelo vídeo.

[@CarlosSilva-hy8xt]

Não fica tão complexo, basicamente vc invoca funções, e de qualquer forma os componentes vão escalar junto com o sistema.

[@marcelo55850]

concordo

[@ryancosta989]

Muito bom o vídeo, obrigado!

[@CarlosSilva-hy8xt]

ótimo video, como sempre trazendo conteúdo de ótima qualidade , aliás se puder trás mais conteúdo sobre testes.

[@devjunioralves]

Show que curtiu Carlos! Quero trazer sim, é um conteúdo muito importante.

[@junior777100]

Valeu!

[@devjunioralves]

Opa meu amigo, muito obrigado!!! 👊

[@danielvalmeida91]

Parabéns por mais esse vídeo Junior. Migrei recentemente para área e seus vídeos tem me ajudado muito !!!

[@devjunioralves]

Opa, que show Daniel, fico feliz demais em saber disso! E que legal que você esta na área de desenvolvimento agora, qualquer dúvida que eu puder ajudar, só dizer.

[@fernandazecchin1144]

Sempre com conteúdos que ninguém passa!!! Muito obrigada, seus conteúdos me ajudam mto a entender muitos conceitos que são difíceis de encontrar por ai. Melhor conteúdo, SEMPRE!!! Parabéns

[@renoinformatica4311]

Poderia trazer um vídeo sobre arquitetura micro front-end no Next.js?

[@devjunioralves]

Quero trazer, mas leva um tempo, pois é um conteúdo mais complexo.

[@CarlosSilva-hy8xt]

cara, DIP, Factory Method e Composition mudaram meu código da água pro vinho.

[@devjunioralves]

Exatamente, tenho a mesmo percepção, existe o antes e o depois no código.

[@ricardobonin6717]

Mais uma vez ficou topp! parabéns!

[@devjunioralves]

Valeu Ricardo!!!

[@claytonjatoba]

Fala Júnior, parabéns pelo conteúdo fenomenal como sempre. Uma sugestão de conteúdo que quero deixar, que é algo que tenho dificuldade de encontrar, é sobre a utilização de orientação a objetos no React, se é uma boa prática criar por exemplo abstrações para chamadas utilizando classes ou se é um problema olhando a tendência do React em seguir em uma estrutura mais voltada para hooks e na linha funcional, e quais seriam os pontos positivos e negativos das abordagens.

[@gabrieldutra8155]

Muito bom o video! Agora, gostaría muito de ver mais um episódio da saga formulários avançados. Onde seria usando o select e input radio. Mas usando o shadUI. Se puder fazer, agradeceria muito!!!

[@devjunioralves]

Opa, que massa Gabriel! Posso fazer sim, essa lib de componentes é sensacional.

[@gabrieldutra8155]

@@devjunioralves Animei em ! Eu disse o input, mas é o radioGroup. Aguardarei ansioso!!

[@NoSb0r100]

Excelente!!!! Mas com relação ao use de muitos componentes separados não acaba ficando meio poluído a árvore de arquivos? Digo se eu tenho vários componentes muito pequenos mesmo assim tenho que separados em arquivos menores? Com 3 linhas? E outra esses componentes que acabam ficando muito específicos para o header é válido colocar eles em componentes dentro da própria pasta do header? Mesmo que eu utilize ele uma vez em outro lugar? Show! Vlw DevJunior

[@robindark]

Show

[@devjunioralves]

Valeuuu!

[@GCoder-sl1sq]

O caso de Single responsability casa perfeitamente com o segundo caso que tu mostrou, no primeiro caso eu achei meio Over engineering tipo voce ainda manter a responsabilidade das props no componente. Componentizar foi a melhor opção ao meu ver.

[@devjunioralves]

Sim, o SRP é mais sobre motivos de mudança do que ter um único componente no arquivo.

[@rodrigoadachi]

Legal, gosto de por em uma pasta com o nome do componente, e por um Index com os esportes de todos subcomponentes, daí utilizo

[@devjunioralves]

Perfeito, curto muito essa estratégia também, sempre ter um index.ts para exportar o que for necessário.

[@MarcosPaulo-zj7mh]

obrigado por isso

[@JonasFrancoDev]

Cara muito bom, parabéns. Espero aprender mais coisas vindo do seu canal. Eu uso children para usar como provider mas não para usar dessa maneira sem um contexto. Isso é muito bacana porque normalmente o valores url deveria passa pelo props do Header mas em vez disso passou direto. Quanto ao SOLID só tinha ouvido falar.

[@devjunioralves]

Que show Jonas, muito bom saber disso!

[@JonasFrancoDev]

@@devjunioralves Fiquei meio com duvidas como funciona a props.children e fiz uma pesquisa achei um blog falando a respeito. No caso as props.children elas normalmente são usadas para inserir tags html ou texto passadas entre a instancia do componente. Também serve para passa funções. Depois você poderia fazer um vídeo falando mais a respeito desse assunto.

[@rafaelfachinelli]

Primeiramente, obrigado pelo vídeio Junior! Pergunta, se eu tiver diversas páginas na aplicação na qual terei o Header com o Avatar e o Profile, e apenas algumas não tendo um ou o outro, o que acha de criar um componente por exemplo chamado HeaderWithAvatarAndProfile por exemplo, assim eu não teria que ficar importando 3 componentes e repassando nas páginas essas propriedades, e ainda poderia colocar a chamada da API por exemplo, dentro desse componente novo. Tem alguma sugestão pra isso?

[@maykonsousa84]

Video top mano. Agora uma dúvida. Se no exemplo, em vez de eu obter o User no App, eu tivesse obtido no Header, manteria a responsabilidade única sem a necessidade de usar um composition?

[@ryancosta989]

Dúvida: Pelo que me lembro das vezes que trabalhei com Prisma, ele faz uma "importação" da tabela do banco onde traz o retorno por exemplo de dados de usuários que contém o avatarUrl e profileName. Mas com prisma acho que nós conseguimos trazer queries mais detalhadas, onde eu quero dentro de um requisição de dados da tabela de usuários apenas o valor do avatarUrl e profileName separadamente. Dito isso, é possível passar essa lógica de requisição individualmente para cada componente e assim não dependendo mais de algum componente pai como por exemplo o App que tem a requisição nele e ele repassa para os filhos?

[@TheWutachi]

Salve @devjunioralves, obrigado pelo video mano. Me tira uma duvida por favor. Se o header recebesse 2 reactNode... seria problemático? Tipo type headerProps= {avatar:React.ReactNode; title:React.ReactNode} Valeu amigo, sucesso!

[@devjunioralves]

Valeu mano! Sobre a sua pergunta, não seria um problema, porém, o "problema" do ReactNode é que ele aceita "qualquer coisa", um componente, uma string e etc. Eu cuidaria em relação à isso somente. Vou até fazer um vídeo sobre esse assunto.

[@dev-isaac-gomes]

SOLID no Front-end foi meu post de uns dias atrás seguimos em sintonia

[@devjunioralves]

Hehe Sim, com certeza! SOLID é assunto importante, é legal sempre exercitar a forma como aplicá-lo.

[@henriquezolini]

Acredito que sua apresentação remete mais a ATOMIC DESIGN do que SOLID. Isso porque a partir do momento que você criou o componente "App" você englobou o "Header", "Avatar" e o "Profile" em um único componente, "ferindo" assim o Principio de Responsabilidade única. Mas com relação a isso, não tem solução, você está montando a página, então está correto tudo que você disse, mas SOLID é um conceito MUITO UTILIZADO para backend, você pode pegar alguns insights mas ele não é 100% aplicável ao frontend. Volto a dizer, isso tem mais a ver com atomic design do que propriamente solid.

[@evertontomazi]

Cara tenho uma duvida. Como proteger o id corretamente. Pq se eu uso o id em uma url e o cara mudar manualmente o id na URL isso pode causar problemas. Como faço isso de forma segura?

[@RafaelGomes01]

Muito bom!!

[@devjunioralves]

Valeu Rafael!!!

[@Jhean_Perdido]

Valeu 🎉🎉🎉🎉

[@devjunioralves]

Valeu!

[@cristianoseixas2417]

Excelente

[@devjunioralves]

Muito obrigado Cristiano!

[@AdeilsonTube]

Muito bom, mas gostaria de evoluir no assunto e ver algo com os hooks e alguma regra de negócio para ver como isso tudo ficaria!

[@viniciuscarvalho3271]

ótimo vídeo, mas me tira uma dúvida, a forma exibida caso for utilizado em um projeto real não irá facilitar no entendimento no código quando se trata de um projeto grande. A implementação do SOLID no Front é bem relativa, visto que todo o conceito foi pensado para OO. Se eu tiver um page e isolar todos states, funções e requests em um hook por exemplo também estaria aplicando o SRP, pois dessa forma isolando em um HOOK, garante que o "componente" principal fique mais claro.

[@devjunioralves]

Valeu Vinicius! Excelente ponto, o fato de isolar a lógica do componente em um custom hook é uma boa prática, mas não necessariamente quer dizer que está aplicando o SRP. Pq? Pq o SRP diz que uma classe/função deve ter somente um único motivo pra mudança, se dentro do hook, tiver várias regras de negócio diferente, por mais que seja esteja isolando a lógica do componente, ainda estar ferindo o SRP.

[@wellingtonjesus1340]

Amigo, não conseguir absolver seu ponto de vista... no final vc ainda continuo passando dentre do Header, os componentes Avatar e Profile. Entendi que o principio seria o componente renderizar somente em função de uma variável ou de um único estado próprio, mas no final ficou a mesma coisa do inicio com mais linhas de código na minha opinião kkkk. Poderia explicar a vantagens e desvantagens? Assistir o vídeo duas vezes e não conseguir enxergar seu ponto de vista. Fora isso conteúdo top, parabéns!!!

[@devlucasfernando]

Não ficou a mesma coisa não mano, antes os componentes estavam diretos dentro do Header, existia um acoplamento, ao passar por children isso foi abstraido!

[@dev-isaac-gomes]

bora que eu to com fome

[@devjunioralves]

Boraaa man!