Comparação entre BLoC, ScopedModel e Redux - Parte Final


BLoC , ScopedModel , Redux … diferenças, quando usar, quando NÃO deve ser usado, vantagens, desvantagens…

Comparações

Essa análise me permitiu comparar três dos frameworks mais usados (ou qualquer outro nome que possamos usar para se referir a eles), em sua forma nua.

Estes 3 quadros têm os seus prós e contras, que eu listo aqui abaixo (Esta é a minha opinião pessoal, claro…):
 

Redux

1. Prós
- O Redux permite centralizar a gestão de um Estado graças ao fato de que os Redutores são os únicos que podem realizar a transição de um estado para outro. Isso torna a transição de estado perfeitamente previsível e completamente testável.
- A facilidade de inserir middlewares no fluxo também é um ponto positivo. Se, por exemplo, você precisa validar constantemente a conectividade com o servidor ou rastrear as atividades, esse é um espaço perfeito para essas rotinas.
- Isso força o desenvolvedor a estruturar o aplicativo em termos de "Evento - Ação - Modelo - ViewModel - Exibição".
 
2. Contras
- Uma única loja e um enorme estado (se você quiser manter as boas práticas do Redux)
- Uso de funções métodos de nível superior: em Redux, redutores e middlewares são geralmente, mas não necessariamente, funções de nível superior ou métodos que não fazem parte de uma classe. Como consequência, nada impediria chamá-los de fora do escopo da Redux Store, o que não seria o ideal. Já ScopedModel e BLoC usam uma classe específica para o modelo ou o bloco.
- Muitas comparações "se ... então" nos níveis de redutores e middlewares
- Muitas reconstruções (cada vez que há uma mudança no estado)
- Requer o uso de um pacote externo com os riscos que o pacote evolui com a quebra de alterações.

3. Recomendação
Eu poderia recomendar o Redux quando você precisar lidar com um estado de aplicativo global, como, por exemplo, autenticação de usuário, carrinho de compras, preferências (idioma, moeda)…
 
4. Não recomendado
Eu não recomendaria o Redux quando você precisa lidar com várias instâncias de algo, cada uma delas tendo seu próprio estado.
 

ScopedModel

1. Prós
- ScopedModel torna muito fácil reagrupar o modelo e sua lógica em um único local.
- ScopedModel não requer nenhum conhecimento da noção de Streams, o que facilita a implementação para iniciantes.
- ScopedModel pode ser usado para lógicas globais e locais
- ScopedModel não está limitado ao gerenciamento de estado
 
2. Contras
- ScopedModel não fornece nenhum meio de permitir que o código saiba qual(is) parte(s) do Modelo foi alterada e causou a invocação do ScopedModelDescendant
- Muitas construções. Cada vez que um Modelo notifica seus ouvintes, tudo relacionado àquele Modelo é reconstruído (AnimatedBuilder, InheritedWidget…)
- Requer o uso de um pacote externo com os riscos que o pacote evolui com a quebra de alterações.
 
3. Recomendações
- Quando os desenvolvedores não estão muito familiarizados com o Streams
- Quando o modelo não é muito complexo
 
4. Não recomendado
- Quando um aplicativo precisa reduzir o número de compilações, por motivos de desempenho;
- Quando um aplicativo precisa saber precisamente qual parte do modelo foi alterada.
 

BLoC

1. Prós
- facilita o reagrupamento da lógica de negócios em um único local
- torna muito fácil determinar com precisão a natureza de quaisquer alterações (por meio de sua interface de saída, baseada em Streams)
- torna muito fácil limitar o número de (re)compilações ao mínimo necessário, graças ao uso do StreamBuilder Widget
- O uso de Streams é muito poderoso e abre as portas para muitas ações (transformar, distinto, debounce ...)
- podem ser usados ​​para lógicas globais e locais
- não se limita ao Gerenciamento do Estado
- Não requer o uso de nenhum pacote externo.

2. Contras
- Se você quiser seguir a regra principal, só podemos lidar com sinks e streams.
- Pessoalmente, meus BLoCs também expõem getters/setters/API, o que remove esses “contras”.
- É mais difícil para os iniciantes começarem com o BLoC, pois isso requer um entendimento adicional de como o Flutter realmente funciona
 
3. Recomendações
- Eu não vejo nenhuma restrição.
 
4. Não recomendado
Eu não vejo nenhum caso em que eu recomendaria não usar um BLoC, exceto quando os desenvolvedores não estão familiarizados com a noção de Streams.
 

Outros pacotes

Antes de falar sobre qualquer conclusão, gostaria de mencionar que existem vários pacotes adicionais hoje em torno da noção de Redux, entre os quais os 2 seguintes podem ser interessantes para aqueles que ainda preferem Redux:

- rebloc, que combina aspectos do Redux e do BLoC
Este pacote é bastante interessante, mas ainda não resolve a sobrecarga de execução de código, ligada à noção de redutor (se a ação for… então). No entanto, vale a pena dar uma olhada nisso.

- fish_redux, da equipe Alibaba Xianyu.
Este pacote não é um framework de Gerenciamento de Estado, mas sim um Framework de Aplicação, baseado no Redux.
Este pacote é muito interessante, mas requer mudar totalmente a maneira de desenvolver um aplicativo. Essa solução facilita a estruturação do código em termos de Ações e Redutores.
 

Concluindo

Portanto, existe alguma "solução única e perfeita"? De fato, eu diria que não existe uma solução perfeita “uma só”. Isso realmente depende do seu caso de uso e, além disso, realmente depende de qual framework você está mais confortável.

Como conclusão, vou falar apenas as minhas considerações pessoais: Eu nunca usei Redux até agora em nenhum dos meus projetos e nunca tive a sensação de que perdi alguma coisa. O mesmo se aplica ao ScopedModel…

Vários meses atrás, comecei a trabalhar com o BLoC e uso essa noção em todos os lugares para quase tudo, é muito conveniente. Isso realmente tornou meu código muito mais limpo, mais fácil de testar e muito mais estruturado e reutilizável.

Espero que este artigo tenha lhe dado algumas ideias adicionais ...

Fique atento para novos artigos!
1226 Visualizações
Awesome Flutter