Preciso muito do seu feedback aqui nos comentários 👇 Livros que eu recomendo: Rápido e devagar amzn.to/3PLrYhq Como ser um programador melhor amzn.to/3POQ5fq Código Limpo amzn.to/3hHXVKY Arquitetura Limpa amzn.to/3Viqw7v Estruturas de dados e algoritmos com JavaScript amzn.to/3hM0L1u Entendendo Algoritmos: Um guia ilustrado para programadores e outros curiosos amzn.to/3BWsaEO 14 hábitos de desenvolvedores altamente produtivos amzn.to/3uZqsyy Hábitos Atômicos amzn.to/3FGllIM Aprendendo a Aprender amzn.to/3WxM0hG A vida dos Estoicos amzn.to/3vaQIGl Meditações de Marco Aurélio amzn.to/3joFYS1
Caraca, como eu amo esse canal. Ja passei diversas vezes por essas dificuldades com props. Tanto que várias vezes eu criava dois ou 3 componentes similares so para separar essas props melhor. E mesmo assim, ainda ficava confuso de entender . Isso vai me ajudar muito
Tem algo que me incomoda no composition pattern, que é a possibilidade de colocar os componentes children fora da ordem e grande. Por exemplo, temos o componente RootComponent: function RootComponent() { return Root Content; } function HeaderComponent() { return Header Content; } function ContentComponent() { return Main Content; } function FooterComponent() { return Footer Content; }
Concordo. Hoje para evitar aquele problema que ele está tentando resolver com composition, eu faço assim: recebo props como: "onSubmit", "onEdit" e crio o componente assim: onSubmit && Submit onEdit&& Edit Ou seja, com uma única prop, defino se mostro ou não o action. Vantagens: - O handle do click fica do lado de fora e pode ser diferente para cada lugar; - O componente tem partes opcionais que só aparecem se houver o handle; - Evita estruturar o código errado como você citou acima; - Evita ter que escrever 5-9 linhas de código toda vez que for usar o componente. Eu adoraria evoluir essa discussão para descobrir se essa minha abordagem é boa mesmo ou ela está pecando em algum ponto que eu desconheço.
Você pode fazer um loop nos children e verificar o id de cada um e no fim colocar corretamente posição desejada. Mas ai já tem vários pontos negativos. Eu prefiro usar tbm Slot Pattern que, além de ficar fácil de ler, tbm melhora bastante a performance e deixar de usar react.memo como band aid.
Na maioria dos projetos, o modal acaba seguindo um modelo e design fixo, então a abordagem das props ainda fazem sentido, somente em casos de projetos grandes que exigem designs diferentes para o mesmo modal, essa abordagem que você mostrou no vídeo faz sentido.
esse tipo de pensamento é totalmente errôneo; "vai seguir sempre o mesmo padrão, então não importa", você sempre tem que estar preparado para o "mas... e se eventualmente não?"
@@isseihyoudou5522 acho que não tem certo e errado, quando você está desenvolvendo é você quem escolhe quais ferramentas vai usar, você criar uma estrutura dessa pra todo componente de um projeto de 5 páginas o problema é seu, agora apartir do momento que vai criar um projeto grande de várias funcionalidades que vai ser adicionado várias melhorias daí faz sentido.
Não é só questão de design @jionarranbrunhago1254, é questão de organização dos componentes. Por que, pensa comigo, se tiver muitas variações do mesmo componente, você vai precisar criar, no mínimo, uma prop pra cada delas, e em pouco tempo, o componente estará super inchado e cada vez mais difícil de testar. Sobre projetos pequenos, claro, precisamos levar em contato isso e o fator tempo.
Na minha experiência, considero que começar um projeto colocando muita complexidade em cada componente é um tipo de over-engineering. No final, menos da metade dos componentes vão precisar esse nível de complexidade. Prefiro começar com componentes simples e refatorá-los quando precisar (geralmente quando aparecer uma terceira variante). A fim de contas, um bom desenho e cobertura de testes automatizados simplificam a refatoração e dão segurança no processo. Mas isso é só meu ponto de vista. Na programação não existe certo ou errado. Existem múltiplas formas de obter o mesmo resultado e elas são melhores ou piores dependendo do estilo e experiência do desenvolvedor, de convênios da equipe e até do contexto de desenvolvimento do aplicativo (tempo, recursos, impacto, objetivo, etc.)
Pow cara, terminei um projeto que fiquei muito feliz, varios modais, e realmente sofri com varias props, mas tentei deixar o mais organizado possivel, mas não conhecia esse metodo. Vou estudar isso, cara.. vc tem que colocar essas coisas no github pra facilitar nossa vida.
Que show Will! Pega esse pattern e pratica, tu vai curtir muito. E sim, ta no github, o link ta de descrição do vídeo, só escolher a branch do vídeo lá hehe
nested components n afeta praticamente nada em performance, recomendo vc ver a quantidade de funções que o react roda por baixo dos panos, alguns componentes a mais n faz nem cócegas com composition vc n tem problemas de conflito na hr de dar commit se 2 pessoas personalizarem o mesmo componente composition é o modelo mental do react, ele é feito pra ser assim, essa é uma premissa do core team do react
Por um lado isso é bom, mas gosto da idéia de misturar herança com composição. Por exemplo, eu tenho um modal que contém todos os micro-componentes separados como vc mostra no vídeo, porém a importação padrão do modal é ele montado, completo e caso eu queira fazer alguma mudança a nível de componente eu faço por propa. Por exemplo tudo q está relacionado ao header eu controla assim caso eu não queira a amostra padrão: HeaderComponentText={component} HeaderComponentAction={component} HeaderHidden E assim segue. Eu tô começando a construir meus componentes assim, pq por vezes o modal pode se repetir muito em várias telas tendo o mesmo padrão, há excessões aqui ou alí e vale a pena controlá-las via props. Gosto de considerar assim, uma mistura de composição e herança. Pois tb terei a opção tanto de um quanto do outro caso eu TB não queira definir componentes por props quando preciso for.
Exato Rodrigo! Você pode utilizar as duas abordagens juntas. Tu pode criar os componentes menores e genéricos e criar os componentes mais especializados utilizando esses menores, ou seja, compondo utilizando os "pedaços" menores.
Fala Junior, blz! Parabéns por mais esse vídeo, ajudou demais na minha evolução. O que você acha do Vitest? Não lembro se vi algum vídeo seu falando sobre ele.
Opa, fico feliz em saber disso Emanoel! Sobre o Vitest, eu curto ele mas usei pouco. Preciso brincar mais, daí posso fazer um vídeo sobre minhas impressões. Tu utiliza ele no dia a dia?
Muito bacana, mas para a criação do modal eu utilizaria o createPortal do React para gantir sempre que ele estija relativo a janela, pois se o pai do componente estive com relative pode quebrar o modal...
Qual é o repositório que esta esse seu exemplo? Outra coisa, no ModalAction voce tem o children no parametro da funcao ModalAction, mas eu nao vi ele no se type ModalContentProps. como explica esta bruxaria?
parabéns pelo video, muito bom seu trabalho aqui no youtube, me diz uma coisa, como que ficaria o teste da Page? vc iria fazer um 'stub' para os components já testados do Modal?
Top, uma dúvida, se eu tivesse por exemplo um carroussel, e tivesse a opção de exibir a legenda em baixo da imagem ou por cima da imagem, teria que mexer com posicionamento. Daria pra escrever o código nesse pattern? Já que um elemento depende do estado de outro pra aplicar estilização
Fala Junior blz ?? Esotu com um problema nos testes com next13. NEXT_RSC_ERR_CLIENT_METADA_EXPORT: metadata Saberia qual o caminho para resolver essa zica ?? abraços
Supondo que eu tenha um Button e algumas variações dele, por exemplo, Outlined e Animated. No caso, o Button seria com um bg red, o outlined bg transparent com borda e animated que diminui o tamanho no click Eu poderia ter 3 componentes separados e usar como Button Button.Outlined Button.Animated Mas como eu faço se eu quiser que o Outlined possa ser tambem Animated? Eu criaria um 4o componente? Ou passaria o "outlined" via prop e trataria o estilo dentro do button base? Ou esse tipo de abstração não faz sentido?
A forma que eu crio meus modais isso não faz tanto sentido, eu faço um modal só o fundo e envio um children pra ele com o conteúdo os botões e com as funções separadas em cada modal, header eu fixo o botão de fechar e só envio um titulo ou não, mas essa forma de organizar é bem massa, com certeza vou tentar usar.
No meu ponto de vista parece que trocamos 6 por meia dúzia. Criar componentes dessa é tão ruim quanto apenas passar as props. A única vantagem que vejo é que o component não vira um mega arquivo
Parabéns por mais um ótimo vídeo, sugestão, se for possível cria um github com cada "aula" com as coisas que você fez, fica mais fácil ler também o que foi feito sem precisar pausar a explicação, escrever e depois continuar, assim no meu caso por exemplo já deixo o vídeo de um lado e o código do outro, e consigo acompanhar melhor, mas claro isso é chatinho e trabalhoso de fazer, então é só sugestão mesmo rsrs
Estou vivendo isso. Peguei um projeto desgraçado cheio de gambiarra em React no meu primeiro emprego como Dev Jr. Uma verdadeira merda pra dá manutenção.
@@devjunioralves eu comentei antes de terminar o vídeo kkkkk Vou assistir essa playlist inteira... Tô desenvolvendo uma aplicação em Next, já está em produção, mas como sou o único programador fica foda...
Caraca, como eu amo esse canal. Ja passei diversas vezes por essas dificuldades com props. Tanto que várias vezes eu criava dois ou 3 componentes similares so para separar essas props melhor. E mesmo assim, ainda ficava confuso de entender. Isso vai me ajudar muito
Preciso muito do seu feedback aqui nos comentários 👇
Livros que eu recomendo:
Rápido e devagar
amzn.to/3PLrYhq
Como ser um programador melhor
amzn.to/3POQ5fq
Código Limpo
amzn.to/3hHXVKY
Arquitetura Limpa
amzn.to/3Viqw7v
Estruturas de dados e algoritmos com JavaScript
amzn.to/3hM0L1u
Entendendo Algoritmos: Um guia ilustrado para programadores e outros curiosos
amzn.to/3BWsaEO
14 hábitos de desenvolvedores altamente produtivos
amzn.to/3uZqsyy
Hábitos Atômicos
amzn.to/3FGllIM
Aprendendo a Aprender
amzn.to/3WxM0hG
A vida dos Estoicos
amzn.to/3vaQIGl
Meditações de Marco Aurélio
amzn.to/3joFYS1
Muito bom, são conceitos que não se vê muito por aí, mas são extremamente necessários no dia a dia.
Parabéns por mais um conteúdo fenomenal, realmente é um pattern que auxilia muito na manutenção e legibilidade do código!
Muito obrigado Clayton!!!
Caraca, como eu amo esse canal. Ja passei diversas vezes por essas dificuldades com props. Tanto que várias vezes eu criava dois ou 3 componentes similares so para separar essas props melhor. E mesmo assim, ainda ficava confuso de entender . Isso vai me ajudar muito
Valeu Gustavo!!!
Vou aplicar esse conhecimento agora para refatorar alguns componentes de onde trabalho.
Perfeito, será um excelente exercício, Matheus!
Tem algo que me incomoda no composition pattern, que é a possibilidade de colocar os componentes children fora da ordem e grande. Por exemplo, temos o componente RootComponent:
function RootComponent() {
return Root Content;
}
function HeaderComponent() {
return Header Content;
}
function ContentComponent() {
return Main Content;
}
function FooterComponent() {
return Footer Content;
}
Nada impete e me proibe de fazer assim:
Concordo.
Hoje para evitar aquele problema que ele está tentando resolver com composition, eu faço assim:
recebo props como: "onSubmit", "onEdit"
e crio o componente assim:
onSubmit && Submit
onEdit&& Edit
Ou seja, com uma única prop, defino se mostro ou não o action.
Vantagens:
- O handle do click fica do lado de fora e pode ser diferente para cada lugar;
- O componente tem partes opcionais que só aparecem se houver o handle;
- Evita estruturar o código errado como você citou acima;
- Evita ter que escrever 5-9 linhas de código toda vez que for usar o componente.
Eu adoraria evoluir essa discussão para descobrir se essa minha abordagem é boa mesmo ou ela está pecando em algum ponto que eu desconheço.
Você pode fazer um loop nos children e verificar o id de cada um e no fim colocar corretamente posição desejada. Mas ai já tem vários pontos negativos. Eu prefiro usar tbm Slot Pattern que, além de ficar fácil de ler, tbm melhora bastante a performance e deixar de usar react.memo como band aid.
@@AlesaGillespie vou pesquisar sobre. Obrigado pela dica!
Gostei muito da sua didática
Ja me inscrevi, curti e favoritei algumas das suas playlists
Que show! Fico feliz que tenha gostado e seja muito bem-vindo!!!
Conheci seu canal agora, muito conteúdo de react, parabéns, vou explorar mais as partes de teste unitários
Seja bem vindo man! Show, tem muito conteúdo sobre testes aqui no canal.
Nossa, vou começar usar essas técnicas para deixar meu código mais legível, obrigado professor!
Tmj Marcus! 👊
Parabéns, ótima dica! Vou começar a fazer assim a partir de agora
Boa Giovanne, depois deixa aqui seu feedback. Quero saber o que tu achou da abordagem na pratica.
Gostei muito desse Pattern de composição e já venho utilizando ele nos meus projetos
Boa man! Esse pattern é muito bom, principalmente no React.
Muito bom Junior! Didática impecável...
Valeu demais Thiago!
Só o suprassumo das melhores práticas aqui nesse canal.
Radix UI é um dos que usam 'Composition Pattern'.
Show, Junior!
Exatamente, o Radix utiliza muito esse pattern.
Valeu demais man 👊
eu conheci esse padrão lá em 2019, junto com o atomic design
a junção desses dois caras casa muito bem
Exatamente Maurice!
Adorei sua didática cara. Não para nunca! +1inscrito
Que show! Seja muito bem vindo!
nunca tinha visto uma aula de testes tao boa
Na maioria dos projetos, o modal acaba seguindo um modelo e design fixo, então a abordagem das props ainda fazem sentido, somente em casos de projetos grandes que exigem designs diferentes para o mesmo modal, essa abordagem que você mostrou no vídeo faz sentido.
esse tipo de pensamento é totalmente errôneo; "vai seguir sempre o mesmo padrão, então não importa", você sempre tem que estar preparado para o "mas... e se eventualmente não?"
@@isseihyoudou5522 acho que não tem certo e errado, quando você está desenvolvendo é você quem escolhe quais ferramentas vai usar, você criar uma estrutura dessa pra todo componente de um projeto de 5 páginas o problema é seu, agora apartir do momento que vai criar um projeto grande de várias funcionalidades que vai ser adicionado várias melhorias daí faz sentido.
@@isseihyoudou5522 concordo quando o projeto é grande, a estrutura inicial beneficia muito ao longo prazo o projeto
Não é só questão de design @jionarranbrunhago1254, é questão de organização dos componentes. Por que, pensa comigo, se tiver muitas variações do mesmo componente, você vai precisar criar, no mínimo, uma prop pra cada delas, e em pouco tempo, o componente estará super inchado e cada vez mais difícil de testar.
Sobre projetos pequenos, claro, precisamos levar em contato isso e o fator tempo.
Na minha experiência, considero que começar um projeto colocando muita complexidade em cada componente é um tipo de over-engineering. No final, menos da metade dos componentes vão precisar esse nível de complexidade. Prefiro começar com componentes simples e refatorá-los quando precisar (geralmente quando aparecer uma terceira variante). A fim de contas, um bom desenho e cobertura de testes automatizados simplificam a refatoração e dão segurança no processo. Mas isso é só meu ponto de vista. Na programação não existe certo ou errado. Existem múltiplas formas de obter o mesmo resultado e elas são melhores ou piores dependendo do estilo e experiência do desenvolvedor, de convênios da equipe e até do contexto de desenvolvimento do aplicativo (tempo, recursos, impacto, objetivo, etc.)
Pow cara, terminei um projeto que fiquei muito feliz, varios modais, e realmente sofri com varias props, mas tentei deixar o mais organizado possivel, mas não conhecia esse metodo. Vou estudar isso, cara.. vc tem que colocar essas coisas no github pra facilitar nossa vida.
Que show Will! Pega esse pattern e pratica, tu vai curtir muito.
E sim, ta no github, o link ta de descrição do vídeo, só escolher a branch do vídeo lá hehe
@@devjunioralves vou tentar, é que os que fiz tem forms, então são vários forms diferentes, mas essa abordagem é muito boa.
Achei legal mas acho que aumentou demais a complexidade do componentes sem contar que deve afetar a performace por ter muitos nested components.
🤨
nested components n afeta praticamente nada em performance, recomendo vc ver a quantidade de funções que o react roda por baixo dos panos, alguns componentes a mais n faz nem cócegas
com composition vc n tem problemas de conflito na hr de dar commit se 2 pessoas personalizarem o mesmo componente
composition é o modelo mental do react, ele é feito pra ser assim, essa é uma premissa do core team do react
Por um lado isso é bom, mas gosto da idéia de misturar herança com composição. Por exemplo, eu tenho um modal que contém todos os micro-componentes separados como vc mostra no vídeo, porém a importação padrão do modal é ele montado, completo e caso eu queira fazer alguma mudança a nível de componente eu faço por propa.
Por exemplo tudo q está relacionado ao header eu controla assim caso eu não queira a amostra padrão:
HeaderComponentText={component}
HeaderComponentAction={component}
HeaderHidden
E assim segue. Eu tô começando a construir meus componentes assim, pq por vezes o modal pode se repetir muito em várias telas tendo o mesmo padrão, há excessões aqui ou alí e vale a pena controlá-las via props.
Gosto de considerar assim, uma mistura de composição e herança. Pois tb terei a opção tanto de um quanto do outro caso eu TB não queira definir componentes por props quando preciso for.
Exato Rodrigo! Você pode utilizar as duas abordagens juntas. Tu pode criar os componentes menores e genéricos e criar os componentes mais especializados utilizando esses menores, ou seja, compondo utilizando os "pedaços" menores.
show, parabéns pelo conteúdo
Valeu Gilson!
Ótimo conteúdo mano!
Eu uso esse pattern mto no svelte, que tem as slots q ajuda ainda mais na leitura
Isso é muito interessante, os fundamentos são válidos independente da ferramenta.
Cara, primeiramente parabéns pelo vídeo, muito bomm
Mas agora a dúvida que muitos já devem ter perguntado: cara q navegador eh esse? MT top 🎉
Fala Junior, blz! Parabéns por mais esse vídeo, ajudou demais na minha evolução. O que você acha do Vitest? Não lembro se vi algum vídeo seu falando sobre ele.
Opa, fico feliz em saber disso Emanoel!
Sobre o Vitest, eu curto ele mas usei pouco. Preciso brincar mais, daí posso fazer um vídeo sobre minhas impressões. Tu utiliza ele no dia a dia?
Muito bacana, mas para a criação do modal eu utilizaria o createPortal do React para gantir sempre que ele estija relativo a janela, pois se o pai do componente estive com relative pode quebrar o modal...
Perfeito Eduardo, você está correto. Creio que muita gente não conhece o createPortal.
Sensacional 👊
Valeu Ricardo!!!
Faz vídeos sobre o Nextjs 13 por favor, heheheh
Tem duas playlists sobre Next.js hehe
Ahh Eu comentei de material ui, no outro comentário, se puder trazer conteúdo dela...usando react, next..junto com material Ui, seria toop!
Tem um vídeo aqui sobre MUI, mas quero trazer mais sim!
@@devjunioralves shoooooow...gosto muito do material Ui, mas sempre acho conteudo legal sobre, só nos canais lá de fora.
Toop Manoo! Dá para fazer isso usando o Material Ui tb?
Sim, da sim Daniel! Em vários componentes, a MUI utiliza essa abordagem.
Esse video ficaria 100% se o modal abrisse com parallel routes + intercepting routes. Especialmente pq não teria a necessidade do isOpen
Opa, excelente sugestão Thiago!!!
Qual é o repositório que esta esse seu exemplo?
Outra coisa, no ModalAction voce tem o children no parametro da funcao ModalAction, mas eu nao vi ele no se type ModalContentProps. como explica esta bruxaria?
parabéns pelo video, muito bom seu trabalho aqui no youtube, me diz uma coisa, como que ficaria o teste da Page? vc iria fazer um 'stub' para os components já testados do Modal?
??
Top, uma dúvida, se eu tivesse por exemplo um carroussel, e tivesse a opção de exibir a legenda em baixo da imagem ou por cima da imagem, teria que mexer com posicionamento. Daria pra escrever o código nesse pattern? Já que um elemento depende do estado de outro pra aplicar estilização
Eu consigo hospedar uma aplicação em nextjs em qualquer um desses sites como hostinger, hostgator, locaweb e etc?
Amigo as aulas do seu curso de Nextjs teve inicio quando?
No dia 10 de julho.
Fala Junior blz ?? Esotu com um problema nos testes com next13.
NEXT_RSC_ERR_CLIENT_METADA_EXPORT: metadata
Saberia qual o caminho para resolver essa zica ??
abraços
Que plugin é esse que formata o className?
Supondo que eu tenha um Button e algumas variações dele, por exemplo, Outlined e Animated.
No caso, o Button seria com um bg red, o outlined bg transparent com borda e animated que diminui o tamanho no click
Eu poderia ter 3 componentes separados e usar como
Button
Button.Outlined
Button.Animated
Mas como eu faço se eu quiser que o Outlined possa ser tambem Animated?
Eu criaria um 4o componente? Ou passaria o "outlined" via prop e trataria o estilo dentro do button base? Ou esse tipo de abstração não faz sentido?
A forma que eu crio meus modais isso não faz tanto sentido, eu faço um modal só o fundo e envio um children pra ele com o conteúdo os botões e com as funções separadas em cada modal, header eu fixo o botão de fechar e só envio um titulo ou não, mas essa forma de organizar é bem massa, com certeza vou tentar usar.
No meu ponto de vista parece que trocamos 6 por meia dúzia. Criar componentes dessa é tão ruim quanto apenas passar as props. A única vantagem que vejo é que o component não vira um mega arquivo
Nesses casos, qual seria sua alternativa, Luiz?
Parabéns por mais um ótimo vídeo, sugestão, se for possível cria um github com cada "aula" com as coisas que você fez, fica mais fácil ler também o que foi feito sem precisar pausar a explicação, escrever e depois continuar, assim no meu caso por exemplo já deixo o vídeo de um lado e o código do outro, e consigo acompanhar melhor, mas claro isso é chatinho e trabalhoso de fazer, então é só sugestão mesmo rsrs
Excelente! Na verdade, já tem, eu que esqueço de colocar kkk
Ta na descrição do vídeo o repositório com as aulas recentes.
@@devjunioralves show, e obrigado pelo feedback :)
@@rudinhok Eu que agradeço!
conteúdo top demais
Estou vivendo isso. Peguei um projeto desgraçado cheio de gambiarra em React no meu primeiro emprego como Dev Jr. Uma verdadeira merda pra dá manutenção.
Top! Man, que navegador é esse? Kk
Valeu man! Chama Brave hehe
AULAS
tem video sobre testes? gostaria de dar uma aprofundada em testes
Tem uma playlist inteira sobre testes hehe
@@devjunioralves eu comentei antes de terminar o vídeo kkkkk
Vou assistir essa playlist inteira... Tô desenvolvendo uma aplicação em Next, já está em produção, mas como sou o único programador fica foda...
estou no min 9:30 parece que basicamnete quebrou o compoente em várias partes
Exatamente, a idéia é quebrar os componentes em pedaços menores.
Brabo
Valeu Jhean!
Qual o nome desse pattern?
Chama composition.
Tem alguma forma de fazer o merge sem usar uma biblioteca?
Sim, tu pode concatenar as classes, pois são string. Porém, o que essa lib faz vai além disso, ela entende as prioridades das classes.
Toop vlw
Valeu Eduardo!
que browser é esse que você usa?
Esse é o Brave.
@@devjunioralves Digo o que estava com o tildraw e youtube aberto
@@_filipe.miranda Ahh sim, era o Safari.
Caraca, como eu amo esse canal. Ja passei diversas vezes por essas dificuldades com props. Tanto que várias vezes eu criava dois ou 3 componentes similares so para separar essas props melhor. E mesmo assim, ainda ficava confuso de entender. Isso vai me ajudar muito
Perfeito Gustavo! Isso ajuda demais a organizar os componentes de uma forma melhor.
Valeu demais! 👊