|
| 1 | +--- |
| 2 | +slug: escolhendo-gerenciamento-estado |
| 3 | +title: Escolhendo o gerenciamento de estado |
| 4 | +authors: rubensdemelo |
| 5 | +tags: [flutter, gerenciamento-estado] |
| 6 | +--- |
| 7 | + |
| 8 | +:::info Resumão: |
| 9 | + |
| 10 | +Flutter é um framework não-opinativo. |
| 11 | + |
| 12 | +Responsabilidade e discernimento na escolha. |
| 13 | + |
| 14 | +Mantenha o mais simples possível |
| 15 | +::: |
| 16 | + |
| 17 | +O Flutter é um framework não opinativo, ou seja, ele não impõe e não obriga sobre como funcionalidades devem ser implementadas. |
| 18 | + |
| 19 | +Permite que os desenvolvedores usem a sua criatividade e experiência para encontrar soluções personalizadas para seus problemas, em vez de serem forçados a seguir um conjunto rígido de regras e convenções impostas pelo framework. |
| 20 | + |
| 21 | +Isso significa que é possível escolher diferentes opções que resolvem o mesmo problema. |
| 22 | + |
| 23 | +Consumir uma API REST, utilizando o package [http](https://pub.dev/packages/http), [dio](https://pub.dev/packages/dio) ou [chopper](https://pub.dev/packages/chopper) ?. |
| 24 | + |
| 25 | +Navegação utilizando APIs nativas ou packages como [fluro](https://pub.dev/packages/fluro), [beamer](https://pub.dev/packages/beamer) ou [go_router](https://pub.dev/packages/go_router) ?. |
| 26 | + |
| 27 | +Armazenamento local, com [sqflite](https://pub.dev/packages/sqflite), [drift](https://pub.dev/packages/drift) ou [isar](https://pub.dev/packages/isar) ?. |
| 28 | + |
| 29 | +Cada uma das opções possuem prós e contras. |
| 30 | + |
| 31 | +No gerenciamento de estado, a mesma coisa. |
| 32 | + |
| 33 | +Sobram alternativas nativas: [setState()](https://api.flutter.dev/flutter/widgets/State/setState.html), [ChangeNotifier](https://api.flutter.dev/flutter/foundation/ChangeNotifier-class.html), [InheritedWidget](https://api.flutter.dev/flutter/widgets/InheritedWidget-class.html), [StreamBuilder](https://api.flutter.dev/flutter/widgets/StreamBuilder-class.html), etc. |
| 34 | + |
| 35 | +E packages, como [riverpod](https://pub.dev/packages/riverpod), [flutter_bloc](https://pub.dev/packages/flutter_bloc), [provider](https://pub.dev/packages/provider), [mobx](https://pub.dev/packages/mobx), etc. |
| 36 | + |
| 37 | +Mas qual o motivo então de discussões acaloradas sobre a "melhor" alternativa para gerenciamento de estado ? |
| 38 | + |
| 39 | +O motivo é simples: não existe "bala de prata", ou seja, não existe a melhor opção. E sim, aquela opção que se encaixa melhor no seu projeto. |
| 40 | + |
| 41 | +Cabe aos desenvolvedores a responsabilidade e o discernimento na escolha. |
| 42 | + |
| 43 | +É natural que as pessoas discutam sobre como fazer isso da “melhor” maneira possível. E cada um vai defender a sua escolha em detrimento das outras. |
| 44 | + |
| 45 | +Felizmente, o amadurecimento do Flutter e da comunidade contribuíram para que estas discussões tivessem cada vez **menos importância**. Mas ainda assim continua sendo um tópico “quente”. |
| 46 | + |
| 47 | +O Flutter é um framework que oferece flexibilidade e liberdade de escolha em suas implementações. |
| 48 | + |
| 49 | +E como mencionado anteriormente, **não existe** a “melhor” maneira. A escolha da opção de gerenciamento de estado ideal depende do projeto e do **contexto** em que está sendo usada. |
| 50 | + |
| 51 | +E para finalizar e responder a pergunta deste post, aqui está a resposta: |
| 52 | + |
| 53 | +- Avalie se as alternativas nativas são suficientes |
| 54 | +- Se optar por packages, considere a complexidade do estado no aplicativo. Avalie a documentação e repositório. Avalie mais de um package. |
| 55 | +- Faça uma prova de conceito com a situação mais complexa possível. |
| 56 | + |
| 57 | +Regra de ouro: mantenha o mais simples possível. |
0 commit comments