Não conhecia esse ElementType, ele parece ser mto útil. Uma dica, quando estender as props de um componente, tem um type helper do React chamado ComponentProps. Dá pra extender tantos elementos HTML quanto componentes customizados. Ficaria assim: interface NotificationActionProps extends ComponentProps {} E para custom components: interface SomeComponentProps extends ComponentProps
mt massa que qnd vejo as aula dele parece tudo mt facil, ai qnd coloco em pratica passo hrs quebrando a cabeca kkkkkkkkkkkkkkkkkkkkkkk faz parte do processo!
As bibliotecas UI acabam até mesclando essa abordagem com outras patterns, como por exemplo component composition q é passar um componente como props para outro componente
Esse pattern é lindo demais. O radix e muitas outras libs usam demais! Outro ponto, a utilização desse pattern, de certa forma, não deixa de utilizar o Single Responsability pattern do SOLID, olha só que massa.
Cara que sensacional! Como sempre Diego salvando por aqui kkkk, apliquei esse conceito de pattern no meu trabalho do estágio e foi sucesso, confesso que deu um trabalho pois estou trabalhando com Astro (e ainda estou estudando sobre) mas o princípio é o mesmo, salvou muito!! É esse tipo de vídeo que merece um sub kkkk
Pra quem tiver interesse em se aprofundar mais, existe um padrão de design no front-end que se chama Atomic Design, é a mesma teoria (em quebrar o componente em componentes menores) mas utilizando padrões de arquitetura mais recomendados no designer atomico (atomos, moleculas, templates, etc...). É mais recomendado quando se tem um design system pronto para o projeto, fica muito mais detalhado na hora de documentar em um storybook por exemplo.
isso somado a Context API faz você entregar projetos num outro nível! Ótima aula !!!! É nessas horas que você entende o porque existem Padrões de projeto e se você acha que no front-end não da para implementar coisas do tipo você estava enganado. Muito show ver mais conteúdo com patterns no frontend 🚀
voltando aqui pra dizer que esse video, em portugues, é muito melhor que muitos e muitos videos sobre o tema no youtube, em portugues ou ingles. Baita video foda.
Esse é um bom pattern, com certeza! Mas no caso de actions ali, pra respeitar o Open-Closed eu costumo receber um vetor como props e renderizar sob demanda, deixando a responsabilidade de definir a ação pro componente que chama o componente filho. Por exemplo: type Actions = Array void }>
Outro ponto legal desse pattern é que podemos definir os possíveis tipos de children desses componentes e garantir que nada vai quebrar, seja em implementação ou estilo. No caso a sempre aceitaria um ou mais componentes do tipo Notification.Action.
Comecei o ano apenas sabendo muita coisa sobre conceitos de programação, principalmente no que tange backend. Eu estou quase terminando meu curso de SI (é, quase nada de front é ensinado em SI, apesar de ser meu foco). E agora, depois de muito estudar a junção de Tailwind, tsx, react, Next e um tanto de mongodb, estou conseguindo ver esses vídeos sem uma dúvida sequer. Agregou mt! Vlw!
A era disso que vc tava reclamando no Insta outro dia, que estava ficando complexo montar um botão kkk.. Mas de fato, a primeira vez talvez dê mais um pouco de trabalho, mas quando vi isso nos painéis de diálogo do headlessui, deu para notar o quanto simplifica para montar os componentes do front "depois de prontos".
Cara, muito interessante, com toda certeza vou fazer algum projeto e implementar esse Pattern. Diego, você é uma inspiração para eu continuar evoluindo.
incrivel!! eu tinha feito ontem sobre esse projeto so em tailwing e logo hoje ja sair esse video so me da mais motivo para estudo sobre o assunto, valeeeu Rocketseat!
Muito boa essa pattern. Estou criando uma biblioteca de componentes no projeto que trabalho atualmente, porém, não estamos utilizando tailwind e sim styled-components. Nesse caso, como cada composição vai precisar da sua estilização, basta criar uma pasta para cada um onde vamos ter pra cada pasta(composição ) os arquivos .types, .styles e o index? Obrigado pela aula, Diego!!
Cara, acho incrivel. O que eu fico incredulo é como eu vou saber que eu precisaria de outra biblioteca para fazer um tal de merge nas classes, como ele chega a essa conclusão e sabe da existencia de uma biblioteca pra isso? é esse nivel que eu quero chegar.
É simples, você não vai saber, a não ser que já saiba, é claro kkk Isso é coisa de você experimentar um problema e pesquisar soluções na internet, imaginando que outras pessoas já passaram pelo mesmo e até criaram uma solução, acabar ouvindo por outros assim como você ouviu do Diego nessa aula e agora sabe da existência dessa biblioteca, ou até de você mesmo criar a solução caso seja capaz e divulgá-la na internet. Não existe nenhuma magia ou ação do sobrenatural aqui, como é algo que depende da exposição e da ciência da existência de tais coisas, é algo que você simplesmente desenvolve quanto mais você está em contato com a área.
Acho uma boa a Rocketseat trazer mais conteúdos relacionados ao NextJS. Por exemplo, depois dos Server Components, há uma nova forma de trabalhar com contextos? E qual a melhor forma de proteger rotas de uma aplicação? Seria utilizando o middleware ou tem algo melhor?
Esse padrão é muito bom, mas nesse caso específico ai poderia ser resolvido com um array de elementos, então poderiar ser enviados varios components customizados independente da quantidade sem precisar de uma prop chamada hasActions.
Pra ficar ainda melhor e menos verboso, você pode criar variações para cada componente filho que compõem o pai e passar de forma obrigatória ou opcional ou fazendo na mão (como eu gosto ou utilizando Tailwind variants por ex...) e restringir ainda mais a identidade visual de cada filho com todas as suas variações. Similar ao que libs fazem quando ao utilizar o componente filho por exemplo de ícone você declara via pros: size=sm color=purple icon=(já pode vir as opções de dentro e você só diz se é ícone y ou z) e tudo fica sempre concentrado dentro de cada filho não afetando o código final do pai, mantendo clean code, menos verbosidade e se utilizar técnicas como a do storybook por exemplo, cada componente seu pode ter um readme ensinando a usá-lo, descrevendo etc... e também, a tipagem do componente pode ser externa, os hooks e etc... sem falar em testcases já deixando o componente com diferentes useCases testados e aprovados... as possibilidades são infinitas e quanto mais você se aprofundar e entende isto, mais organizado e direto fica a leitura pra qualquer um que bater o olho já entender o que tá rolando... e pra fazer refactory, mudanças ou manutenções, fica delícia! 🤘🏻
19:58 Quando eu coloco className ali no meu caso não funciona. No meu caso tive que criar uma propriedade e enviar o codigo do tailwind para o componente
cara muito bom criar varios videos usando o mesmo projeto.. parece quase um "minicurso" distribuido por varios assuntos que podem ser mostrados não necessariamente relacionados em serie pq cada video funciona sozinho, mas que o exemplo mostrado encaixe em outros videos. por exemplo fazer um prox video focado em formatar datas com alguma lib e usar esse proj pra atualizar só o texto q ta no conteúdo q mostra a data da notificação. pra quem for ver, nao importa o projeto em si. pq é só um exemplo. mas quem ve o "grupo" dos videos desse projeto encaixa e da oturas perspectivas.
outro video que seria muito bom nesse sentido seria um focado em variants de botões com o tailwind pra na hora de colocar o action button ali passar apenas a cor e não as classes em si
Teu teclado tão barulhento que me desconcentrou 😂 Edit: terminei o vídeo agr. 😅 muito poderoso esse pattern. Já tinha visto e usado antes mas tu executou muito bem no vídeo, muito legal ver o resultado!
Caso eu queira adicionar uma imagem da pasta assets ('./asstes/imagem.png'), como eu declararia o type do src no componente, pois se eu declaro o type como string, o typescript indica como se houvesse erro, e não gostaria de utilizar o type any, para não dar margem para erros
Conteúdo muuuito bom, Diegão!! Não conhecia esse pattern de composição mas já vou levar pro time que trabalho para aplicarmos isso nos nossos projetos.
Dahora, tenho aprendido muito com você e esse pattern de composição muito interessante, vou por em prática eu não sei trabalhar ainda com tailwind css mas pretendo estudar também. Sem o tailwind você acha que minha barrera será muito maior em relação a estilização dos componentes?
show de bola Diegão .. vídeo top ... fora que esse partern está mto presente agt na forma de compor as UIs no next13 com a app router, considerando ter aquela diretiva 'use client' a se considerar e tals ... vlwwwww
Dá pra ver pelo exemplo da documentação deles que não é assim que funciona. O twMerge lida com classes conflitantes. Geralmente quando classes tem estilos que conflitam, a que está escrita no arquivo css por último que prevalece, mas o "compilador" do tailwind não garante nenhuma ordenação na definição das classes, então essa função twMerge que retira as classes conflitantes
@@artistry7919 Com certeza há muitoo mais lógica por tras no twMerge , mas para grande maioria dos casos é puro overengineering, com certeza essa função que mencionei vai abranger a maior parte dos casos. Há classes conflitantes? Cuide pra não enviar elas.
@@gustavoleite7569 você poderia tentar tomar esse cuidado, mas isso é limitante e já não funciona no exemplo desse vídeo, por ex... E é beem comum querer um background ou outro estilo padrão e permitir sobrescrita pra quem tá chamando o componente, então é bem comum que essa função não seja over engineering
@@artistry7919 bem, a função resolve um problema que o próprio Tailwind criou, então creio que sim, é um matar uma mosta com um canhão. Utilizo com sass & CSS e até agora, nunca precisei mais que essa função. Mas como eu disse, grande maioria não vai precisar do twMerge pra apenas juntar 2 classes.
To começando a utilizar o Tailwind pra fazer estilizações nos meus apps, qual a melhor forma de indentação pra que não fique com essas linhas enormes e facilite a leitura?
A biblioteca shadcn ui, tem a mesma abordagem na forma de construção de componentes. Vou fazer alguns experimentos com esse pattern para ver se em termos de DX e tempo de execução, ele viável. Gostei muito do conteúdo.
Muito bom. Agora surgiu uma dúvida: será que, assim como o Next, apesar de adicionar um pouco mais de complexidade ao projeto, vale a pena já começar usando esse pattern, já que a mudança do "padrão" para o composition pattern não é assim tão simples.
Era exatamente o que eu procurava a muito tempo! Me surgiu uma dúvida, caso eu queira fazer o componente semelhante a estrutura do React Bootstrap, como seria? Por exemplo: , sem que eu precise criar um Card.Root.
Alguem tem alguma sugestao de artigo que ajudasse a ver como aplicar essas dicas do video, pra criar formularios? Pq um formulario que cada form tem seus campos de validacao específicos, teria alguma forma de nao precisar ficar replicando eles, por exemplo pra não precisar criar um formLogin, um formRegister e por ai vai. Ou não tem jeito de evitar.
Diego, mais uma vez um excelente conteudo. Uma curiosidade, Você ve alguma vantagem em utilizar o children declarando direto nas props como ReactNode ao invés de utilizar o PropsWithChildren? Ou é mais costume?
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Não conhecia esse ElementType, ele parece ser mto útil. Uma dica, quando estender as props de um componente, tem um type helper do React chamado ComponentProps. Dá pra extender tantos elementos HTML quanto componentes customizados.
Ficaria assim:
interface NotificationActionProps extends ComponentProps {}
E para custom components:
interface SomeComponentProps extends ComponentProps
Top dms, não sabia dessa
Dica ótima mano!
Boa partilha!!🎉 Sempre fiquei curiosa na differença de HTML… com ComponentProps. Muito bem explicado.
eu uso o JSX.IntrinsicElements["button"] 😆
passei a vida toda usando "interface CustomElementProps extends React.OriginalElementHTMLAttributes {...}"
mt massa que qnd vejo as aula dele parece tudo mt facil, ai qnd coloco em pratica passo hrs quebrando a cabeca kkkkkkkkkkkkkkkkkkkkkkk
faz parte do processo!
To me sentindo assim neste exato momento uhjaeuhaeuhae muitas dúvidas.
@@kleinpapai Você ja tem uma base no react, front end etc?
às vezes é falta de uma base no desenvolvimento front end, mas pode vir a melhorar com o tempo
@@pandasgirltsx eu estava aprendendo na epoca, hoje ja to na area kkkk
Ja havia visto essa abordagem em uma biblioteca, nunca fui afundo. Muito interessante. Obrigado por compartilhar Rockeseat 🎉.
As bibliotecas UI acabam até mesclando essa abordagem com outras patterns, como por exemplo component composition q é passar um componente como props para outro componente
Esse pattern é lindo demais. O radix e muitas outras libs usam demais!
Outro ponto, a utilização desse pattern, de certa forma, não deixa de utilizar o Single Responsability pattern do SOLID, olha só que massa.
Cara que sensacional! Como sempre Diego salvando por aqui kkkk, apliquei esse conceito de pattern no meu trabalho do estágio e foi sucesso, confesso que deu um trabalho pois estou trabalhando com Astro (e ainda estou estudando sobre) mas o princípio é o mesmo, salvou muito!! É esse tipo de vídeo que merece um sub kkkk
Pra quem tiver interesse em se aprofundar mais, existe um padrão de design no front-end que se chama Atomic Design, é a mesma teoria (em quebrar o componente em componentes menores) mas utilizando padrões de arquitetura mais recomendados no designer atomico (atomos, moleculas, templates, etc...). É mais recomendado quando se tem um design system pronto para o projeto, fica muito mais detalhado na hora de documentar em um storybook por exemplo.
isso somado a Context API faz você entregar projetos num outro nível! Ótima aula !!!! É nessas horas que você entende o porque existem Padrões de projeto e se você acha que no front-end não da para implementar coisas do tipo você estava enganado.
Muito show ver mais conteúdo com patterns no frontend 🚀
Trás mais disso que o pessoal aqui de produto ama ❤
Muito bom, Diego é muito ligeiro e preciso isso é muito bom para quem já tem experiência em programação e não precisa ir tão devagar!
voltando aqui pra dizer que esse video, em portugues, é muito melhor que muitos e muitos videos sobre o tema no youtube, em portugues ou ingles. Baita video foda.
Esse é um bom pattern, com certeza!
Mas no caso de actions ali, pra respeitar o Open-Closed eu costumo receber um vetor como props e renderizar sob demanda, deixando a responsabilidade de definir a ação pro componente que chama o componente filho.
Por exemplo:
type Actions = Array void }>
Diego, você é o cara mais foda que eu não conheço!
Outro ponto legal desse pattern é que podemos definir os possíveis tipos de children desses componentes e garantir que nada vai quebrar, seja em implementação ou estilo.
No caso a sempre aceitaria um ou mais componentes do tipo Notification.Action.
Hum interessante, entaoo tipo children inves de ser reactnode seria um array de notification.action nem ?
Teria um exemplo disso?
Comecei o ano apenas sabendo muita coisa sobre conceitos de programação, principalmente no que tange backend. Eu estou quase terminando meu curso de SI (é, quase nada de front é ensinado em SI, apesar de ser meu foco). E agora, depois de muito estudar a junção de Tailwind, tsx, react, Next e um tanto de mongodb, estou conseguindo ver esses vídeos sem uma dúvida sequer.
Agregou mt! Vlw!
Nossa. Gostei demais e já abriu horizontes para outros tipos de componentes. Inputs, formulários, tabelas... Show de bola!
Explica um pouquinho sobre esse ...rest em algum vídeo! Obrigado pela ótima aula!
A era disso que vc tava reclamando no Insta outro dia, que estava ficando complexo montar um botão kkk..
Mas de fato, a primeira vez talvez dê mais um pouco de trabalho, mas quando vi isso nos painéis de diálogo do headlessui, deu para notar o quanto simplifica para montar os componentes do front "depois de prontos".
Legal pra caramba, eu ainda não tinha visto esse tipo de abordagem em componetização, vou começar a utilizar, estava fazendo tudo via props😂
sofrimento ne
Muito bom, tava digitando o comentário e ia falar q o radix utiliza bastante ai você começou a falar, muito massa
esse video ficou perfeito, com ótimo exemplo prático, parabéns.
Da até vontade de codar mais com essa didática incrível! 🚀
Cara, muito interessante, com toda certeza vou fazer algum projeto e implementar esse Pattern. Diego, você é uma inspiração para eu continuar evoluindo.
incrivel!! eu tinha feito ontem sobre esse projeto so em tailwing e logo hoje ja sair esse video so me da mais motivo para estudo sobre o assunto, valeeeu Rocketseat!
Vlw pelos dica no final, eu tava mesmo procurando algo como o Radix
Muito foda Diegão, conteúdo solícito e claro.
Conteúdo top demais, criando componentes dessa forma traz mais flexibilidade e facilita a manutenção. Será que vou usar isso pra tudo ? rsss
muito bom esse pattern, excelente vídeo Diego
Muito boa essa pattern. Estou criando uma biblioteca de componentes no projeto que trabalho atualmente, porém, não estamos utilizando tailwind e sim styled-components.
Nesse caso, como cada composição vai precisar da sua estilização, basta criar uma pasta para cada um onde vamos ter pra cada pasta(composição ) os arquivos .types, .styles e o index?
Obrigado pela aula, Diego!!
Cara, acho incrivel. O que eu fico incredulo é como eu vou saber que eu precisaria de outra biblioteca para fazer um tal de merge nas classes, como ele chega a essa conclusão e sabe da existencia de uma biblioteca pra isso? é esse nivel que eu quero chegar.
É simples, você não vai saber, a não ser que já saiba, é claro kkk Isso é coisa de você experimentar um problema e pesquisar soluções na internet, imaginando que outras pessoas já passaram pelo mesmo e até criaram uma solução, acabar ouvindo por outros assim como você ouviu do Diego nessa aula e agora sabe da existência dessa biblioteca, ou até de você mesmo criar a solução caso seja capaz e divulgá-la na internet.
Não existe nenhuma magia ou ação do sobrenatural aqui, como é algo que depende da exposição e da ciência da existência de tais coisas, é algo que você simplesmente desenvolve quanto mais você está em contato com a área.
Diego sempre mandando muito bem, o cara é foda
Acho uma boa a Rocketseat trazer mais conteúdos relacionados ao NextJS. Por exemplo, depois dos Server Components, há uma nova forma de trabalhar com contextos? E qual a melhor forma de proteger rotas de uma aplicação? Seria utilizando o middleware ou tem algo melhor?
Nossa... todo dia é dia de escola, ótimo essa dica. Vou testar em algum projeto com certeza! Thanks
o bom dos vídeos do Diego é que eu acelero no máximo pra 1.25x, ele já fala no modo 2x hahahha sem falar na qualidade do conteúdo (:
tenho apenas duas palavras pra esse design pattern: DO CARALHO.
Como eu estava esperando por um esse conteúdo diegão, top demais
Esse padrão é muito bom, mas nesse caso específico ai poderia ser resolvido com um array de elementos, então poderiar ser enviados varios components customizados independente da quantidade sem precisar de uma prop chamada hasActions.
Mano que conteúdo sensacional, adorei essas dicas vou pesquisar um pouco mais sobre esse Pattern.
Muito bom, pretendo utilizar esse pattern em muitos dos meus projetos
Pra ficar ainda melhor e menos verboso, você pode criar variações para cada componente filho que compõem o pai e passar de forma obrigatória ou opcional ou fazendo na mão (como eu gosto ou utilizando Tailwind variants por ex...) e restringir ainda mais a identidade visual de cada filho com todas as suas variações. Similar ao que libs fazem quando ao utilizar o componente filho por exemplo de ícone você declara via pros: size=sm color=purple icon=(já pode vir as opções de dentro e você só diz se é ícone y ou z) e tudo fica sempre concentrado dentro de cada filho não afetando o código final do pai, mantendo clean code, menos verbosidade e se utilizar técnicas como a do storybook por exemplo, cada componente seu pode ter um readme ensinando a usá-lo, descrevendo etc... e também, a tipagem do componente pode ser externa, os hooks e etc... sem falar em testcases já deixando o componente com diferentes useCases testados e aprovados... as possibilidades são infinitas e quanto mais você se aprofundar e entende isto, mais organizado e direto fica a leitura pra qualquer um que bater o olho já entender o que tá rolando... e pra fazer refactory, mudanças ou manutenções, fica delícia! 🤘🏻
muito da hora diego, parabéns pelo conteúdo 👏
muito bom....vou imlementar nos projetos agora muito massa...
19:58 Quando eu coloco className ali no meu caso não funciona. No meu caso tive que criar uma propriedade e enviar o codigo do tailwind para o componente
cara muito bom criar varios videos usando o mesmo projeto.. parece quase um "minicurso" distribuido por varios assuntos que podem ser mostrados não necessariamente relacionados em serie pq cada video funciona sozinho, mas que o exemplo mostrado encaixe em outros videos. por exemplo fazer um prox video focado em formatar datas com alguma lib e usar esse proj pra atualizar só o texto q ta no conteúdo q mostra a data da notificação. pra quem for ver, nao importa o projeto em si. pq é só um exemplo. mas quem ve o "grupo" dos videos desse projeto encaixa e da oturas perspectivas.
outro video que seria muito bom nesse sentido seria um focado em variants de botões com o tailwind pra na hora de colocar o action button ali passar apenas a cor e não as classes em si
Muito bom, esse pattern salva vidas !!!
Teu teclado tão barulhento que me desconcentrou 😂
Edit: terminei o vídeo agr. 😅 muito poderoso esse pattern. Já tinha visto e usado antes mas tu executou muito bem no vídeo, muito legal ver o resultado!
Caso eu queira adicionar uma imagem da pasta assets ('./asstes/imagem.png'), como eu declararia o type do src no componente, pois se eu declaro o type como string, o typescript indica como se houvesse erro, e não gostaria de utilizar o type any, para não dar margem para erros
Excelente conteúdo, como sempre. Já vai entrar pras minhas boas práticas.
surreal de bom. esse pattern facilita muito como eu não sabia disso?
Sensacional Diego! 🚀
Show diegao, conteúdo top, o pattern de composição nos ajuda bastante tanto na manutenção quanto a escabilidade dos componentes.
Conteúdo muuuito bom, Diegão!! Não conhecia esse pattern de composição mas já vou levar pro time que trabalho para aplicarmos isso nos nossos projetos.
Boa dica! Obrigado pelo compartilhamento
Conteudo muito foda mano. Obrigado.
Sensacional Diego 🚀
Muito top Diegão!
Genial!! Que aula magnífica...
que vídeo satisfatório! 😌
Pattern sensacional. Muito obrigado por partilhar!
Muito top cara, Obrigado por compartilhar
Você é foda Diego 💜
Dahora, tenho aprendido muito com você e esse pattern de composição muito interessante, vou por em prática eu não sei trabalhar ainda com tailwind css mas pretendo estudar também.
Sem o tailwind você acha que minha barrera será muito maior em relação a estilização dos componentes?
Muito interessante essa forma de criar componentes!!!
Boa tarde, qual extensão do VS Code que você utiliza que importa automaticamente os componentes ao salvar
@Diego tudo bem, da moral primereact e muito completo uso em todas apps e faz vídeo dele.
Melhor thumbnail da Rocket
show de bola Diegão .. vídeo top ... fora que esse partern está mto presente agt na forma de compor as UIs no next13 com a app router, considerando ter aquela diretiva 'use client' a se considerar e tals ... vlwwwww
Cara, baita conteúdo!
até o min 8:21: Eu utilizaria os próprios metodos onNomeDaAcao pra saber se aquele component tem ou não aquela ação, não um hasAction ou actionType
Gosto muito de usar o design atoms por conta disso também Diegao
Que conteúdo delicioso de ser consumido!
Ótimo conteúdo Diego! Seria muito bom ter mais desse conteúdo sobre design patterns para projetos FE.
Muito boa explicação. Valeu!
Muito obrigado por trazer conteúdos de extrema qualidade como este. Tem me ajudado muito nos estudos
Ver essa aula é saber/descobrir que o MaterialUI trabalha com outro pattern: o prop hell kkkkkkkkkkkkkkk
min 20:21
tailwind-merge === função abaixo
function classGroupe (...args: any[]) {
return args.join(' ')
}
function MyComponent ({ className }) {
return (
// your code
)
}
Dá pra ver pelo exemplo da documentação deles que não é assim que funciona.
O twMerge lida com classes conflitantes. Geralmente quando classes tem estilos que conflitam, a que está escrita no arquivo css por último que prevalece, mas o "compilador" do tailwind não garante nenhuma ordenação na definição das classes, então essa função twMerge que retira as classes conflitantes
@@artistry7919 Com certeza há muitoo mais lógica por tras no twMerge , mas para grande maioria dos casos é puro overengineering, com certeza essa função que mencionei vai abranger a maior parte dos casos.
Há classes conflitantes? Cuide pra não enviar elas.
@@gustavoleite7569 você poderia tentar tomar esse cuidado, mas isso é limitante e já não funciona no exemplo desse vídeo, por ex...
E é beem comum querer um background ou outro estilo padrão e permitir sobrescrita pra quem tá chamando o componente, então é bem comum que essa função não seja over engineering
@@artistry7919 bem, a função resolve um problema que o próprio Tailwind criou, então creio que sim, é um matar uma mosta com um canhão. Utilizo com sass & CSS e até agora, nunca precisei mais que essa função. Mas como eu disse, grande maioria não vai precisar do twMerge pra apenas juntar 2 classes.
foda man, me salvou muito
To começando a utilizar o Tailwind pra fazer estilizações nos meus apps, qual a melhor forma de indentação pra que não fique com essas linhas enormes e facilite a leitura?
Top o conteúdo Diegão. Gostaria de conteúdo sobre chamadas de vídeo e áudio com react native.
Muito bom! Isso vai ajudar muito.
Toppp xará, vou aplicar nos meus projetos 👊🏼
A biblioteca shadcn ui, tem a mesma abordagem na forma de construção de componentes. Vou fazer alguns experimentos com esse pattern para ver se em termos de DX e tempo de execução, ele viável.
Gostei muito do conteúdo.
shadcn usa o radix
Senti um ppuco de falta de um html mais semântico, fira isso otima demonstração do design pattern
Faz um vídeo sobre os métodos de array mais importantes e os usos deles no React.
Vai no canal da Origamid, ele tem uma playlist que é: JavaScript antes do framework, vai te ajudar
ruclips.net/video/37SwqREHRGI/видео.html
O Diego tem uns vídeos que mostra alguns conteúdos javascript que você pode estudar antes de partir pro React e lá mostra alguns métodos de Array
mt legal esse componente elementtype
Como configura o vscode para importar automaticamente?
Muito bom. Agora surgiu uma dúvida: será que, assim como o Next, apesar de adicionar um pouco mais de complexidade ao projeto, vale a pena já começar usando esse pattern, já que a mudança do "padrão" para o composition pattern não é assim tão simples.
Acredito que sim, conforme o projeto escale irá facilitar a manutenção.
Era exatamente o que eu procurava a muito tempo! Me surgiu uma dúvida, caso eu queira fazer o componente semelhante a estrutura do React Bootstrap, como seria? Por exemplo: , sem que eu precise criar um Card.Root.
MUUUUUITO BOOM!!
Alguem tem alguma sugestao de artigo que ajudasse a ver como aplicar essas dicas do video, pra criar formularios? Pq um formulario que cada form tem seus campos de validacao específicos, teria alguma forma de nao precisar ficar replicando eles, por exemplo pra não precisar criar um formLogin, um formRegister e por ai vai. Ou não tem jeito de evitar.
muito bom, vou testar.
18:25 interessante, o linter do airbnb briga comigo seu espalhar as props no botão
Diego, mais uma vez um excelente conteudo.
Uma curiosidade,
Você ve alguma vantagem em utilizar o children declarando direto nas props como ReactNode ao invés de utilizar o PropsWithChildren?
Ou é mais costume?
akgyen sabe qual o nome da extensao desses icons (arquivos etc) ?
Alguém sabe qual é essa extensão para quando salvar o arquivo, importar as coisas já?
Recomendo também a boa e velha clsx library para merge de css classes
Typescrit + Next + Tailwind faz o front parecer um mundo incrivel, pena que o resto é um saco kkkk
Fantastico. Eu nao tinha visto essa parte desse jeito. Eu normalmente usaria uma factory com React.createElement
Atomic design tem essa pegada, vc coda mais, mas o resultado final é muito "libertador" em relação a criação de componentes.
Grato!
Qual o tema, do vscode e dos icones/materials?