Provider Study 1-3

1. ProxyProvider
   어떤 프로바이더에서 다른 프로바이더의 값이 필요할 때 쓰임..?
   ex) 배경색에 따라 카운터 값이 바뀌어야할때에 가능하게 해주는 친구!

=> 다른 프로바이드에 값에 기초하여 빌드하는 프로바이더?

=> 다른 프로바이더의 값이 바뀔떄마다 업데이트를 시켜야함!

=> 프록시 프로바이더가 의존하는 값을 처음으로 획득했을 때
=>프록시 프로바이더가 의존하는 값이 바뀔떄마다
=> 프록시 프로바이더가 리빌드 될떄마다
업데이트 콜백이 불러야함! (언제 불러야할까요?)

어떤 프로바이더가 변하는 값에 의존하는 경우에도 프록시 프로바이더를 씀

  ChangeNotifierProvider<Counter>(create: (_) => Counter()),
            ProxyProvider<Counter, Translations>
                // counter가 변할때마다 업데이트 될 것이므로 create는 필요없음
                (update: (_, counter, __) => Translations(counter.counter)),
            // Translations의 인스턴스를  mutation 시키는 게 아니라 매번 새로운 Translations의 인스턴스를 만들어줌@!
            // 순전히 컴퓨티드 스테이트만 같은 것만 만드는 거라면 지금처럼 하는게 맞음! 그게 아니라면 changeProxyProvider를 쓰면 돼여

2. 페이지 랜더링 프로세스 of stateful widget
   create an element(BuildContext) => initState => didChangeDependencies => Build

페이지 완성 후 할 수 있는것

.initState
페이지 랜더링 도중! (마운팅 되고있는 중)
콘텍스트를 그릴 수 없음!
다른 페이지에 해주세요!

addPostFrameCallback
현재 프레임이 완료된 이후에 콜백을 수행해라(진행되는 것을 현재 이후로 해라!)
ex) WidgetBinding.instance!.addPostFrameCallback((Duration timestamp){
// Do something
})

3. error solution
   main.dart hotrestart 해주기
   routes를 잘못 읽을 떄
   build를 잘못 걸었을 때

4. Provider action
   ui를 변경시키는 게 아닌 다이로그 보여줌, 스낵바, 바텀 시트, 네비에이션등은 주의가 필요함

액션 수행 3가지

ChangeNotifier를 이용 => 에러가 발생한 그 시점에서 dialog 표시, 비즈니스 로직, ui 명확히 구별 안됌
ui 액션 부분 이용 => 에러가 트리거된 함수에서 다이어로그 표시 방식, 관련된 로직을 한 군데에서 처리하는 방식,
changeNotifier의 addlistner의 콜백이용 => 로직이 클리어하지만, 리스너를 등록 / dispose 하는 보일러 플레이트 코드를 만들어야하는 점이 있음 / 프로그램 로직상 리스너가 적절히 디스포짓 되지 않고 동일한 수행하는 여러가지 리스너가 있으므로 주의해서 사용해야함