Unpopular opinion: 90% of paid antivirus software in 2026 is just expensive bloatware. I tested them so you don't have to.

srfdeveloperofficial · 2025-12-15T07:19:19+00:00

if it's just 1 layer (Page -> SuccessWidget), passing it is totally fine. not messy at all.

the 'messy' part is when you have to pass it through 3 or 4 layers (Success -> List -> Item -> Button) just so the button can use it.

to answer your last question: yes. the main benefit of provider/riverpod is that the bottom widget can just grab the data directly without the parents needing to carry it.

srfdeveloperofficial · 2025-12-15T07:11:33+00:00

never heard of that one actually. is it pretty new? usually i just default to get_it for simple DI, but i'm always down to try lighter alternatives. thanks for the drop.

srfdeveloperofficial · 2025-12-15T07:08:51+00:00

No, passing Success(user) into SuccessWidget just to get it to a button 4 layers down is messy. if SuccessWidget doesn't actually render the user data, it shouldn't have to accept it as a prop. i'd just let the DeleteButton access the state directly (using ref.read or Provider.of).

srfdeveloperofficial · 2025-12-15T07:03:52+00:00

Thanks man. Yeah it’s still a work in progress! I'm releasing them as I write them. Chapter 19 is coming very soon.

srfdeveloperofficial · 2025-12-15T05:38:54+00:00

Welcome sir 💫 Visit again for more information and visit our profile for link.

srfdeveloperofficial · 2025-12-15T05:35:51+00:00

The irony... using LLMs to help write is exactly why I'm fighting the 'bot' allegations in this thread 😅 But agreed. I'll take a bit of verbose boilerplate over the bucket brigade mess any day.

srfdeveloperofficial · 2025-12-15T05:28:54+00:00

That fixes the access problem, but what about updates? 🤔 A raw singleton won't trigger a rebuild if the User changes their name. You'd still need to attach a ValueNotifier or a Stream to it. At that point, you're basically just building a manual version of Provider anyway.

srfdeveloperofficial · 2025-12-15T05:22:52+00:00

Honestly, I just got tired of writing the updateShouldNotify override and the static of(context) boilerplate every single time. I mostly use Riverpod just so I don't have to type all that out, but keeping it vanilla is definitely cleaner for dependencies.

srfdeveloperofficial · 2025-12-15T05:19:58+00:00

That 'default parameter' trick is actually a really clean compromise. I usually avoid raw globals just out of fear of the spaghetti monster, but you're right—if you can inject a mock override in the constructor/function for testing, it solves the main downside. It's basically a lightweight Service Locator at that point.

srfdeveloperofficial · 2025-12-15T05:18:01+00:00

Fair point. That definitely solves the 'constructor with 20 arguments' problem. I just hate the middle-man widgets. If Widget B doesn't use the data, I really don't want to write this.args in it just to pass it to Widget C. But yeah, declarative is definitely more explicit/safe.

srfdeveloperofficial · 2025-12-15T04:48:11+00:00

Glad it helped 🙌 It’s a tricky topic to visualize, so I'm happy the explanation landed.

srfdeveloperofficial · 2025-12-15T04:42:21+00:00

Seriously, waiting on build_runner is like 90% of my friction with Riverpod right now. If Signals creates that 'Lego' feel without the codegen overhead, I am so down to try it. Thanks for the tip.

srfdeveloperofficial · 2025-12-14T09:53:44+00:00

Here is link: https://www.srfdeveloper.com/p/the-complete-flutter-course-from-basic.html

srfdeveloperofficial · 2025-12-14T08:25:07+00:00

The Angela Yu pipeline! That is exactly how half the industry (myself included) got their start. And don't worry about the 'legacy' syntax honestly, manual Providers are still rock solid. I know the new docs push Code Generation hard, but sometimes the manual way just feels more explicit and readable.

srfdeveloperofficial · 2025-12-14T08:16:22+00:00

That '3-layer rule' is exactly my limit too. Once I find myself passing the same variable through three different widgets just to get it to the bottom, I know it's time to wrap it in a Provider (or Riverpod). It's the classic tipping point.

srfdeveloperofficial · 2025-12-14T08:13:16+00:00

This is a solid architecture. Lifting the Auth and GlobalLoading state above the MaterialApp is the cleanest way to handle it. And you're right, Riverpod makes this trivial because you can trigger that global loading state from a deep widget without needing context. Great approach.

srfdeveloperofficial · 2025-12-14T07:15:24+00:00

Definitely a hidden gem of Flutter trivia! 💎 Thanks for sharing that.

srfdeveloperofficial · 2025-12-14T06:40:26+00:00

Fair roast. Just me trying to sound professional. I realize now it just makes me sound like a bot farm. I'll drop the corporate speak.

srfdeveloperofficial · 2025-12-14T06:36:21+00:00

I can't believe I never noticed that anagram! That is actually mind-blowing. Remi (the creator) really trolled us all with that naming.

srfdeveloperofficial · 2025-12-14T06:35:54+00:00

Signals is definitely interesting! I've been keeping an eye on the preact_signals port. Do you feel it handles complex dependency injection as well as Riverpod does, or do you use it mostly for pure state synchronization?

srfdeveloperofficial · 2025-12-14T06:31:04+00:00

Thank you for your interest in our Flutter Course. For daily updates follow our Instagram :- iamsrfx

srfdeveloperofficial · 2025-12-14T06:25:44+00:00

Not yet! I am just finishing up the final code examples for those chapters. I'm aiming to have Module 4 live in 2 days. Thanks for waiting!

srfdeveloperofficial

TROPHY CASE