ChangeNotifier == Observer Pattern [Flutter, Dart]

แชร์
ฝัง
  • เผยแพร่เมื่อ 1 ธ.ค. 2024

ความคิดเห็น • 4

  • @gustavospaki7988
    @gustavospaki7988 2 ปีที่แล้ว +1

    Great explanation! 😄

  • @gustavospaki7988
    @gustavospaki7988 2 ปีที่แล้ว +1

    Hi, again
    Dude, I really liked your videos, I discovered the channel recently and I'm watching all about flutter.
    I know how to use the tools, but I wasn't aware of how they work. I am excited to learn these things, even more so when they are well explained.
    A future video theme suggestion is to do something like this one, but for the Provider. Looking at the code of Provider.of there is something with context and inheritedElement and I don't understand well. In fact, my knowledge base of context and inheritedEWidget must be missing even before this Provider content.
    Regardless of whether a video on this topic comes out in the future or not, I hope you continue to post content here, great job 🙂.

    • @icodeyoutodeath
      @icodeyoutodeath  2 ปีที่แล้ว +1

      Thank you a lot!
      Since there is a lot of great content on the web about both Provider and InherietedWidget (th-cam.com/video/Zbm3hjPjQMk/w-d-xo.html) as they are some of the most important concepts in Flutter, I weren't intending to cover them. However, I will have a look, and if there are no good explanations for how Provider works under the hood, I may make a video.
      In short, a provider is just a tool that makes using InherietedWidget a little simpler. We want to provide a value somewhere down the widget tree and then access it at one/many places somewhere up the widget tree without passing that value through the widgets' constructors. Also, thanks to that when the value change then only the widgets that use it and their sub-trees need to get rebuild and rerendered. We could think of it as a wrapper for InherietedWidget (unlike riverpod). Therefore, to understand it, it's crucial to know how InherietedWidget works. I believe the first paragraph at pub.dev/packages/provider says it all.

    • @gustavospaki7988
      @gustavospaki7988 2 ปีที่แล้ว +1

      Thanks for the answer
      I edited my comment before you replied, I noticed the missing building blocks before learning how the provider works.
      The "problem" is that there is a lot of content about how to use the tools (knowledge that i have) and not about how they work.
      And the knowledge is very interconnected, there is so much to learn to fully understand a flow.
      Like, I didn't know that setState basically calls a markNeedsBuild() and that helped me better understand the ListanableProvider when it calls value?.addListener(e.markNeedsNotifyDependents).
      I'm getting off topic, sorry hahaha. thanks for the explanation and sources, they are good first steps to learn how things work internally 🤙