Não siga as melhores práticas com RxJS
Se você utilizar as boas práticas 😍 , você irá correr o risco de deixar o código bonito e as pessoas felizes, tem certeza que você quer isso?
Unsubscribe, pra que?
Muitos, inclusive eu, dizem que precisamos fazer “unsubscribe” dos nossos observables, caso não o faça, você corre o risco de ter vazamento de memória, tem certeza que você quer evitar problemas com lentidão, e deixar seu usuário feliz com uma aplicação performática?
Dizem que takeUntil ou takeWhile pode ajudar…
Talvez os dois exemplos acima, sejam difíceis de ler, dizem que ainda há outra opção, simplesmente usar OnDestroy do Angular…
Curtiu? Agora você tem algo mais pra se preocupar, e o código ficou grande. Melhor não usar isso, deixar vazar memória e apagar todos os unsubscribe 😅 ,né 🤓 Veja abaixo, como fica bem melhor:
Subscribe hell
Tinhamos, callback hell com promisses, agora temos Subscribe hell com Subscribes. Porque você tem de usar, pipe, switchMap ou mergeMap para encadear operadores?
Sério, não seria melhor usar o padrão Raduken do Ryu? Se você usar o Subscribe hell, deixa o código fácil de entender(ou não), afinal, quem precisa saber os operadores do RxJS quando se pode usar o padrão Rakuken?
Funções pura? Mais credo, pra que?
Dizem que funções puras, torna o código previsível e testável unitariamente, mas nós nem gostamos de teste unitário, não é mesmo 😉 ? Pra que fazer assim…
Quando se pode fazer assim…
Async PIPE?
Dizem que async pipe promove um código limpo, permitindo menos código por realizar subscribe implícito.
Você gosta tanto assim de escrever pouco código, e delegar para o Angular algo que você mesmo pode fazer na mão? A alternativa é não usar o async pipe. Faça você mesmo o subscribe.
Encapsular Subjects dos serviços? Pra que?
Dizem que proteger seus subjects é uma boa prática, isso evita uso inadvertido do mesmo, e você poderia fazer isso assim…
Mas você quer fazer oque quiser, com os subjects, e deixar sua equipe utilizar como quiser, não é mesmo? O código baixo demonstra como fazer isto:
Bem melhor não mesmo? E de quebra tem menos código :D
Evitar que stream de dados sejam passados para componentes filhos
Tem certeza que você quer evitar efeitos colaterais, desacoplando componentes usando o padrão Smart/Dump componentes?
Passar stream de dados para componentes filhos, delega a responsabilidade de fazer o subscribe/unsubscribe do stream criado no componente pai no filho, legal né? Você sempre precisa olhar os dois pra entender o comportamento inteiro. Shoooooowwwwwww!!!!
Marble diagrams, nãoooo, isso não é para você!
Imagino que você não saiba oque é marble diagram, não se preocupe, você não precisa saber oque é isso, ele só vai te ajudar a testar seus componentes com um código limpo.
Uma função como esta…
Seria testado assim…
Mas você prefere testar assim (certo?)…
Você gosta tanto assim de escrever código que deixa sua equipe feliz 🙃? Faça sua escolha 😜
