[rattling]
[zipping]
There, finally got everything all packed away.
Oh.
I guess I really packed everything in here.
[thundering]
Oh, I knew that was a bad idea!
♪ [music] ♪
Hi, all! Welcome back to
As a quick recap, in the last episode,
we talked about building the DashShop.
Sorry if I got your hopes up about the Dash merch.
We left off with two big action items.
One, decoupling the
And then also breaking down my widgets into smaller widgets.
The state of my code was, well, not great.
Y'all, I had about four widgets for the entire app.
Each one just had massive
I mean, I'm in the process of moving right now,
and my
They just kept getting bigger and bigger and bigger,
until I regretted every decision that I'd ever made that got me there.
After the last episode, I also received a tweet from a member
of the community who was also experiencing
the same nesting problem that I was.
So, I decided what better time to clean things up then right now.
As a result, that's the focus of this entire episode.
We haven't added any new features to MyDash,
just decoupling and refactoring the existing code
for the dashboard and DashShop,
because, well, tech debt is very real.
To kick things off and make things easier on myself,
I did some preliminary code cleanup.
That's like adding some
removing unused imports, all of that fun stuff.
Then our first big order of business was the
I need to decouple the
the
which was a clunky way of handling that, at best.
The goal here was to make it so that the
the
for transitioning between screens.
I did this by pulling my
and registering it with
So whenever I need to reference my
whether that be for adding an item to the
or to list everything that is in the
I just ask
This change also helped to overcome another drawback from the last episode
where my
Since
the
away from the DashShop.
Once that was done, I jumped into breaking my widgets
into smaller widgets.
Starting with the dashboard, each post was already its own widget,
but I went ahead and broke things down even more.
I went to the news card's
and pulled out pieces of code that had its own job
into their own separate widget.
If you're wondering why I pulled out the widgets entirely
instead of using
check out Craig's video on
This means separating the top post bar, the post image, post caption,
comment section, the like button, and the comment box.
I also ended up creating a white space widget
that is literally just a
It was easier for me to see which
just for adding white space as I was refactoring.
Then, jumping over to the DashShop, things got more complicated
because there's more user interaction to deal with.
On the main shop page, I extracted the product grid,
the product card, bag button, and the filter and search bar.
On the product page, I pulled out the image carousel,
size picker, quantity selector, and the
And finally, over to the
the product card itself, price calculation section,
and the
Throughout this process, I learned that deciding
how to refactor a particular widget,
whether it should be stateful versus stateless,
required more thought than I expected at first,
but it got a little bit easier as I got more of them under my belt.
I was able to use more stateless widgets than I'd expected,
because so many of the widgets are just displaying data
and the state was being held elsewhere.
I will say this too,
watch out for default values that you set.
I got errors quite a few times during the refactoring process
where I forgot that I had set a default quantity in the widgets.
Namely, drop-down buttons were yelling at me
because I was selecting a value that didn't exist as a menu item.
Now, I do have some questions about file structure and debugging.
So let's check in with Fitz.
Hey, Fitz, you there?
[knocking]
[Khanh] Fitz, are you there?
Oh, oh. Hi, hi, Khanh. Yeah, I'm here.
I heard through the door that you had some questions.
Yes, in fact, I do.
So let's go ahead and jump right in
because I know you're a little bit busy
because I just showed up at your door with random questions.
So thank you for showing up, by the way.
Yeah, absolutely.
Cool, so my first question for you, Fitz, is:
I've cleaned up my code and kind of following your guidelines,
breaking down my widgets.
But what does your project file structure usually look like?
Do you separate them by features?
Does each widget have their own file?
I mean, Craig recently introduced me to barrel files,
which lets me import a bunch of files, separating components all at once.
I thought that was really neat, and I've been using them all the time now.
Any thoughts?
Yeah, I think it's good to separate things
so that you don't end up with one giant file, right?
And how you separate them is kind of up to you.
I think my guidance for myself is what makes sense.
And so what makes sense is going to be sometimes widget level,
sometimes feature level, sometimes some other level...
abstraction layer, maybe.
And that's where I would start.
In some cases, like for example, if you look at the skeleton app,
you'll find that there's a settings subfolder
that contains everything about settings.
It contains the setting service, the settings controller,
the settings provider, the settings UI page.
And that makes sense for that particular thing,
because that settings feature--
so these would be the settings for like, controlling dark or light mode,
or whatever other in-app settings you might have for that thing.
That makes sense as a contained unit or a contained feature.
- Yeah, for sure. - You might have some other cases
where you just have a bunch of very small UI elements.
And so maybe you want to have a subfolder that has--
these are my custom UI elements, these are my custom buttons,
my custom sliders, my custom whatevers.
And then that makes sense.
And so there's no really hard--
always do widgets, always do components or features.
It's really just what makes sense to you.
Okay. Gotcha.
Maybe I need to go back, I guess to rethink
how I want it to be structured and what makes sense
as opposed to just trying to break everything out,
and then putting it, scattering it everywhere.
That's a good point. Cool.
All right, so my next question for you is:
there's this meme, the
So that meme is me
I have
and that's not exactly the recommended way of doing that.
And so there's a lot of options when it comes to debugging Flutter apps.
What's your go-to debugging tool or strategy?
Print
No, I'm kidding.
Print
that customized message for yourself
of this value is meaningful for these things for these reasons.
And that's helpful. That's really good.
But the
It clutters the code to some degree.
So it's not ideal.
And so there's two things that I would say here.
One is make use of the DevTools as much as possible.
There's a lot of great feature sets in there
that will do all sorts of things to help with the debugging.
Including a Dart debugger that you can use to separate points
and watch the variable values change,
if that's what you're looking for.
Yeah.
I would also say, if you like having those customized messages
that you have in a
"This value is important for this reason."
Maybe look into some logging and/or logging frameworks
to figure out how you can maintain those,
because also the DevTools will pick those up as well.
And then you can set the different levels for them,
and be able to filter them out for a production app
and then have that automatically streamlined
as opposed to a
you have to go and find all of them and delete them.
Yes, right, yes.
It's the finding and deleting that's usually a lot of fun, right?
That's the best part of coding, right?
Yup.
Cool, okay. So DevTools and logging framework.
Cool! Those are two things that I can dive into.
And maybe we can talk about, in another episode--
maybe not
but maybe I'll crash
Yes, absolutely join
and we'll talk more about how to do these things.
Okay, all right, so next time I show up,
I'll knock on your door, and we can do a
You can help me some more with figuring out all this debugging
and file structure and everything else with MyDash.
Yes, yes, absolutely.
Okay, cool!
Well, I think that was all the questions I had for you.
Thank you so much, Fitz, again, for showing up
on such short notice, always.
Yes, absolutely. My pleasure Khanh. Have a great afternoon.
Awesome, thank you, you too. Bye!
So one last thing before we go here.
What's the best trick that you have up your sleeve
when it comes to refactoring your Flutter code?
Let me know in the comments, or shoot me a tweet on @KhanhNwin.
I'm excited to hear all of your tips.
And so that's all we have for this episode of
Thanks for watching, and I'll catch you in the next one.
Bye!
♪ [music] ♪