ฝัง
- เผยแพร่เมื่อ 29 พ.ย. 2024
- Já se perguntou qual é o objetivo de uma aplicação front-end? Nesse vídeo trago um artigo muito interessante sobre o papel do frontend no negócio. Mais interessante ainda é toda a reflexão em cima da separação de responsabilidades e design de aplicações web. Spoiler: É bem possível que você esteja fazendo isso da maneira errada!
✅ Profissional React Native:
▸ coffstack.com/...
✅ Comunidade Discord:
▸ / discord
✅ Artigo do Vídeo "UI as an afterthought":
michel.codes/b...
✅ VOCÊ TAMBÉM VAI GOSTAR DESSES VÍDEOS:
▸ • Minha Carreira do Zero...
▸ • Nível de Inglês Para T...
▸ • Clean Code na Prática ...
▸ • Teste técnico da minha...
▸ • CORRIGINDO BUG NA PRÁT...
✅ REDES SOCIAIS:
Instagram: @coffstack
/ coffstack
Instagram: @lucasgar6
/ lucasgar6
TikTok: @coffstack
/ coffstack
Twitter: @coffstack
/ coffstack
Blog/Artigos
blog.coffstack...
#frontend #reactjs #reactnative #javascript #programação
Music track: Real Estate by Aylex
Source: freetouse.com/...
Free No Copyright Music Download
Excelente vídeo, Lucas!
Valeu! Fico feliz que tenha gostado!
14:40 pq seu service ta no dominio?
seu dominio não deveria ser puro?
service não seria um caso de uso?
exemplo:
adapter do axios (infra/Http)
ListTask caso de (data/useCase/listTask)
ILiSTask interface de contrto do useCase (domain/useCase/listTask)
pq no fim a interface do useCase é pura e pertence ao dominio a ações
na API representam uma intencionalidade do usuário/interface
não seria isso?
Nós não seguimos clean architecture a risca no projeto. Minha experiência prática é que não vale a pena para front-end, muita abstração para pouco retorno em cima disso. Por isso não temos interfaces isolados do caso de uso como "ILiSTask" e injeção de uma implementação, é uma coisa só, mas com a implementação interna isolado sem expor as dependências.
Nesse projeto usamos paradigma funcional, por isso as "instancias" de domínio estão nomeadas como "service". Nesse caso do diagrama seria o "PostService" que é responsável pelo conectar com o repository (API) e adaptar os dados antes de export para os casos de uso.
Difícil de explicar tudo isso em uma linha, temos um módulo inteiro no PRN sobre arquitetura, mas se quiser entender mais, temos uma aula gratuita sobre o tema aqui na página coffstack.com.br/profissional-react-native
@@Coffstack aaah saquei
perguntei mais pq a camada que representa
melhor nossas chamadas seria um service ou um repository
que no caso ambos seriam adaptadores (usam interfaces para abstrair)
então o nome acaba sendo confuso
como pos tipo postService.getList
entendo que é uma listagem do post
porem fica esquisito devido a termos post e service juntos
ja que post representa um verbo HTTP
cogitou trocar isso por alguma palavra alternativa tipo
publicationService.getList
parece menos confuso kkkk
claro não é nada que vai mudar
muito perguntei mais pq arquitetura é o que mais estudo
dentro de JS ai é sempre bom trocar uma ideia
vc não desenvolve só código
desenvolve Produto
frontend não gera código
cria experiencias
uma coisa em react que particularmente
tenho usado bastante é injeção de dependências
para casos de uso pq alem de trazer mais testabilidade
traz uma capacidade de criar fakes muito facil
Uso bastante também! Qual ferramenta vc usa para injeção? Ou faz tudo "na mão" ?
@@Coffstack
tentei usar o InversifyJS
porem, achei péssimo kkkk
hj em dia uso um contexto
para gerenciar as dependências
em um modelo MVVM
tenho uns posts sobre
posso te mantar se tiver interresse kkkkk
video muito bom
@@CoffstackTambém uso o contexto API como injeção de dependência e MVVM tanto no React na Web e Mobile
tenho usado tsyringe para injeção de depêndencia, e ate o momento tenho gostado bastante.
@@dev-isaac-gomes só curiosidade msm, eu já vi essa injeção pelo context.