I just found this tutorial, thanks for making it. I would recommend keeping the 'super' calls (in init and dispose) as they are present in the super class (even if they are empty at the moment). In future versions, they may add some extra code here, which you will lose by not calling them, potentially breaking your app.
@@ResoCoder Would be nice to see it!! But the question is only: based on BLoC pattern or states_rebuilder package?..?? Moreover, which DI will be used in BLoC case?
@@ResoCoder Of course BLoC with get_it (for example) will produce more boilerplate code, BUT... Who knows, is it right choice to switch from well-known approaches to the modern ones? I don't know yet due to lack of experience...
Yeah Yeah! Code reuse it the way to go :) Great video on creating a custom hook. Definitely will be using this in my tutorials / projects as well where I can. Thanks for the detailed video. Very helpful.
Great tutorial, really helpful. and i think we can dispose controllers inside our custom functional hooks as well using useEffect hooks' return method. no need to create hooks with classes :)
That so cool! Hooks look awesome. I also 100% agree with you, that if you only use it in one class, It's not a good idea to CREATE a hook just to use the hook in one widget, if one is already provided for you then that's awesome :D I'll probably start using this library just to take advantage of the useAnimationController hook! I have a personal rule that I never create an abstraction before It becomes necessary. I always start with something that is as concrete as possible that's only used in one place with as little indirection as possible, and if the need arises I create an abstraction that are more versatile :D
I also follow this rule but only in areas where I'm not sure of further implementation. It's not a bad thing to add multiple layers from the beginning if you know you'll need them.
@@ResoCoder Exactly, creating a level of indirection when accessing a datastore of some sort, for example, is probably a good idea, but creating a generic class to deal with some domain-specific issue that I haven't wrapped my brain around yet is probably a baaaad idea.. Keep the content coming :D I always learn a lot from your videos :D
I'd love to hear your (Reso Coder's) opinion on this vs. Blocs, since you generally promoted those in all your 2019 videos. To me, Hooks seem better/easier to use (yes, I come from the React world).
I just watched this video on Flutter Hooks and I have been watching your other tutorials with Blocs. I'm thinking that Hooks can actually be used quite seamlessly with our BLoC logic as well too right? Let's say that certain apps need to do some actions for a "BLoC" hook if that BLoC hook is attached to the widget. What do you think? I would really like to hear your ideas on this!
Thats awesome. I have a small question I use multiple inheritedWidget for having one stateful core. And everything else is a const stateless widget. If i convert some of my stateles widget to hookswidget... will the 'hooks' that i use be the same when the widget rebuilds? Or it does ignore lifecycles and use the same hook? 🤔🤔
If we have a more interactive screen where variables are being set (StatefulWidget) with the hook being called from the build function as it is here it is going to be remade each time we setState(), right? But in this case could we call the hook in initState and use it as a container for our controllers? I can definitely see the benefit of containing the controllers this way because that code can overwhelm everything else.
You have to use the HookWidget. As soon as you have one hook, everything has to be migrated to hooks. Keeping state is easy with the useState hook which grants you a ValueNotifier.
How would you avoid the custom Scrollcontroller hook while still using the animation hook? Since you now inherit from HookWidget, there will be no dispose etc. (like you mentioned) so how is it possible to not abstract the Scrollcontroller away?
Good tutorial, just as a side note, as the code is now, you have a memory leak if you do not dispose the controller for the animation. You seem to be disposing only the scrollcontroller inside the hook.
As it was stated at 12:18 ,the disposal of animation controller will be handled by the hook itself, you will be only required to dispose the custom controller eg scrollcontroller i
Create video about EvnetBus library. I had a problem few weeks ago with hiding bottom nav bar and app bar when user scrolls. I solve it with EventBus lib.
I understand the idea of using hooks in Flutter this way... however I feel I still don't really grasp the benefit of it: in React Native, when you use the Hooks API, you don't really need a Hook class, it really is a function, seems to me like a lambda expression or an anonymous expression is being used. If you need a Hook class, and extending the original Home stateful widget into a HookWidget... is it really a Hook? I thought the idea behind Hooks was to avoid classes, but here we need to put those functions inside a class... Mmmmhhh.....
IMHO, the purpose of Hooks was not to avoid classes. Sure you do have it in React. But the real purpose is to make a logic sharable. This is the point. In React (before hooks), it was easy to share components, but to share logic was really hard. You need to do HOC or Render Props. With hooks, those logic can be encapsulated into a function and be called from any of your components. Just like the hook animation here.
Just not a fan of react. I prefer Flutter’s (and by extension Dart’s) take on composition. What this really does is attempt to make an OOP framework functional. The term ‘hook’ is just a Trojan horse for a paradigm takeover.
I think that Dart will, sadly, never be functional enough. What do you see with hooks that convinces you about them being a paradigm change? From what I discovered, they're just smaller and reusable StatefulWidgets. EDIT: I probably know - composability by calling hooks within hooks.
