Temos que conversar sobre o InheritedWidget

[jacobaraujo7]

Precisamos conversar sobre InheritedWidget Click aqui se ainda não assistiu.

Minha opnião:

• Acho que deveriamos separar o IoC da propagação da instância nos Widget do Flutter.
  Deixa eu explicar:
  Pegue como exemplo o Provider, GetIt ou Modular, todos resolvem a criação da Instancia (IoC) e, por ser objetos singletons acabam sendo consumidos em qualquer lugar do App (Widgets ou dentro de outros serviços) e eu não concordo com isso.
  Acredito que a resolução da instancia deveria acontecer por esses packages mas a propagação deveria ser diretamente pela árvore de Widget com o InheritedWidget.
  Acabamos não usando o InheritedWidget por não sentir a necessidade, já que todos os nossos controllers são singleton`s e podem ser recuperados em qualquer lugar.
  Porém, se impedíssimo que essas instâncias resolvidas fosse recuperadas em qualquer lugar teriamos mais limites.
  Essa falta de limites abre um precedente muito perigoso por injetar coisas que não estão na árvore, perdendo o track e não respondendo a coisas como Hot Reload.
  Eu sinto que ignoramos muitas coisas da arquitetura do Flutter por pensar em facilidades, o que me leva a pensar: Será que não deveriamos respeitar mais a árvore de widgets do Flutter?

Me diz sua opnião ai!

[kmartins]

Então acho que sua colocação está perfeita, única questão seria como podemos resolver a parte dos escopos/módulos, já que quando empurramos uma nova rota, por exemplo, perdemos o acesso ao InheritedWidget da rota anterior, talvez seria interessante uma forma do InheritedWidget ficar disponível para um determinado conjunto de rotas?

Ou até mesmo "levar" todos os dados capturados dos InheritedWidget anteriores para um novo InheritedWidget dessa nova rota?

[lucasnsa]

Boa @kmartins. Olhando a partir do seu post e levando em conta outra conversas que tivemos pessoalmente um ponto a ser muito considerado é a ancestralidade entre InheritedWidgets, nesse contexto temos meios de limitar o escopo de uma instancia, meios de buscar uma instancia ancestral ou de fato ter uma fabrica de instancias e até mesmo combinar tudo isso.

[mateusfccp]

@kmartins O acesso ao contexto do inherited widget não é perdido quando ele está acima do navegador referido na hora da navegação.

[kmartins]

@mateusfccp Sim, eu falei sobre essa possibilidade no comentário mais abaixo, só não sei se isso é tão viável assim para questão do escopo.

[mateusfccp]

Para isso pode-se usar nested navigators, é só que as pessoas não estão acostumadas com isso. No entanto, se estivermos lidando com web e/ou navigator 2.0, não sei como ficaria.

[renanzdm]

Acho que o Provider faz um pouco disso ou é o que chaga mais perto. Visto que voce so consegue recuperar as instancias pelo contexto, e apenas naquele escopo. Claro que se o Desenvolvedor colocar tudo pra ser injetado no main isso sera global. Eu nao sei como seria a forma ideal de se fazer isso da forma correta, mas confesso que as vezes realmente vira uma enorme bagunca, quando nao se tem limites e em todo lugar se pode recuperar uma instancia de seu controller

[kmartins]

Então pra mim a questão fica no seguinte, se preciso reutilizar algo em 2 rotas diferentes, ou você coloca globalmente como você disse ou na hora de fazer um push na rota tu cria um novo Provider colocando o valor que quer reutilizar.

[renanzdm]

Sim, acho que faz sentido a sua colocação, por isso que as vezes o problema nao vai ser o package usado e sim quem esta usando ele rs

[kmartins]

Outro ponto que sinto falta, não sei se o Modular resolve isso já, ou se cabe nessa discussão, a possibilidade de deixar privado a instância, exemplo, no Modular, só dentro do Module eu tenho acesso, nunca fora.

[dtodt]

@jacobaraujo7 talvez seja muito básica a minha duvida, mas no quesito ciclo de vida da dependência, como ficam os binds factory, lazySingleton?

Digamos, caso eu adicione um factory como dependência de um InheritedNotifier na raiz, ele viraria um singleton para aquele widget? Pois a resolução da dependência é feita no construtor?
Ele apenas seria criado novamente, caso fosse usado em um widget no meio da arvore, que seja recriado, ou quando é chamado por outros widgets é isso?

Outro caso se um factory é usado como dependência de um lazySingleton ele vira singleton naquele contexto também, certo?

E para manter uma sinergia com o Modular, eu precisaria iniciar o uso dos InheritedNotifier a partir do primeiro Child do ModularApp, desta forma o primeiro modulo está carregado?

Tenho usado à algum tempo Modular em prod, mas sempre venho buscando formas de melhorar a performance. Dito isto, enquanto escrevia esta duvida, comecei a perceber que as vezes tenho declarado minhas dependências de forma errada 🥲.

[rogeriomq]

Só fato de de ter/garantir o hotReload e melhorar os testes, já é uma grande vantagem. O fato de existir alguns pacotes que tentam resolver isso por fora da árvore de elementos/widgets me leva a pensar em que:
1 - Ficou bem claro na live sobre InheritedWidget(E suas variantes) que não foi dado a devida atenção pela google na documentação do flutter;
2 - Por conta do item anterior, algumas pessoas pensaram em criar algo que desejariam que fosse simples e prático, sem entender o "cerne" de como o flutter funciona em si;

[viniciusddrft]

Cara fantástico isso, por que seguir o fluxo de dados que originalmente o flutter foi criado para ter é algo que realmente a galera não olhava, e foi muito bom o vídeo por que me fez entender sobre toda essa arvore e por que ela é importante, showww ótimo conteúdo.

[dtodt]

Achei interessante a ideia de propagar o IoC pela arvore, fiz um teste aqui no meu código, e funciona.

Porém, tenho usado as NotifierStore do Triple, e não consegui usar essas stores out of the box.
Pra não refatorar muito o meu código, acabei fazendo uma implementação do ValueNotifier com Triple que resultou em uma ListenableStore, vide gist abaixo:

Gist: https://gist.github.com/dtodt/f0662d77127f4fd1345d49a3723059c1

Existe a possibilidade do Triple disponibilizar algo nesse estilo futuramente?

[fabiovalinhos]

Achei muito bom mas gerou me dúvidas.

se eu fizer uma classe sendo InheritedWidget para envolver meu MaterialApp

`class ControllerGeral extends InheritedWidget{

ControllerGeral ({Key? key, required Widget child})
: super(key: key, child: child)

final Page1Controller pag1 = Page1Controller ();
final Page2Controller pag2 = Page2Controller ();
final Page3Controller pag3 = Page3Controller ();
.
.
.
}
`

em seguida aplico este controller geral na raiz

runApp( ControllerGeral ( child: MaterialApp( .....

Faço a injeção pelo contexto em cada página conforme seu controller. Até ai ok.

Minha dúvida: estas instãncias na classe do ControllerGeral InheritedWigte (Page1Controller (), Page2Controller () ... etc) ao serem acionadas não ficam ocupando memória já que não são lazy?
Esse gerenciamento de memória que estou na dúvida.

Hoje uso o GetIt para injeção de dependência.

[dtodt]

A partir do momento que adiciona no InheritedWidget, fica ativo. Então vai para memória.

Algo que teria que testar, mas acho que daria pra fazer um Inherited com um controller e envolver a pagina com ele, assim ele vai carregar ao trocar de pagina.

Tipo:

'/page1'
  InheritedPageWidget
    Page1
'/page2'
  InheritedPageWidget
    Page2
...

Assim ao carregar a pagina, o controller seria instanciado, e ao sair dela, em teoria seria removido da memória.

[fabiovalinhos]

valeu @dtodt .

Até pensei nisso de fazer um InheritedPageWidget para cada página como vc sugere, assim ele aciona seu controller conforme vai sendo solicitado.

Só não testei porque pensei "isso vai dimininuir a praticidade", mas é o que temos.

[dtodt]

De fato, se tiver que fazer um pra cada meio que não faz sentido, à menos que vc use uma interface pro controller, assim vc teria um Inherited só, usado pra vários controllers, carregando a implementação de acordo com a rota.

Quero testar isso uma hora ainda, mas no contexto de autenticação.
Se der certo eu posto aqui no forum.