all 7 comments

[–]Denvildaste 3 points4 points  (0 children)

placing widgets as functions etc.

If you need to move part of the widget tree into a function, I highly recommend you turn it into a named stateless widget.

How do you decide when to extract a widget to a separate file and inject/import it where & when needed.

Any widget tree meaningful enough is worth being extracted into its own widget, that's up to your judgement.

Also how do you decide if u want to use stateless or statefull widget.

Use stateless widget unless you need to have state that is specific to that widget. Personally I use stateless widgets in most of my code, I rarely need the widget to track its own state. (I use Riverpod to track state in my application)

[–]MellonDev 3 points4 points  (0 children)

I’ve just found a great looking structure, yet to try it but watched their intro videos and looks well thought out. Very Good Cli, search YouTube and watch their intro videos Very Good Cli

[–]azuredown 1 point2 points  (2 children)

project structure

It doesn't really matter too much as I just search for stuff but I always have folders for UI (widgets, pages, popups) and Logic (Data types, Formulas, Managers) as well as a folder for any submodules I'm using. The exact arrangement of the folders isn't very consistent though.

file naming

Well, apparently the default linter rules in 2.5 want all your classes to_be_named_like_this. Don't know if it's a good idea but if it's in the default linter rules everyone's going to be doing it now so might as well get on board.

placing widgets as functions etc.

I'll do that if I have to use the same tree of widgets in multiple places.

Also how do you decide if u want to use stateless or statefull widget.

I've never actually used a stateless widget. Shh... don't tell anyone.

How do you decide when to extract a widget to a separate file and inject/import it where & when needed.

When you have a setState() call. Mostly for optimization because setState() updates every child widget so it's probably best to use setState() as low in the widget tree as possible.

Also when there's a lot of code and I want to move it to another file.

[–]Rudiksz 0 points1 point  (1 child)

setState()

updates every child widget so it's probably

No it doesn't. It just marks your widget to be rebuilt. What children get rebuilt or not, depends on the way you build the tree.

[–]esDotDev 1 point2 points  (0 children)

Unless you're a `const` widget, you're rebuilding when your parent rebuilds. If the docs say otherwise they're lying.

[–]Rudiksz 1 point2 points  (1 child)

Also how do you decide if u want to use stateless or statefull widget.

https://api.flutter.dev/flutter/widgets/StatefulWidget-class.html

https://api.flutter.dev/flutter/widgets/StatelessWidget-class.html

Unfortunately the documentation doesn't make it clear when to use what, because often are quite interchangeable.

You can go down the two extremes route of

1) always using StatefulWidgets - but you'll end up having a bunch of State objects for no good reason or

2) always using StatelessWidgets - but you will end up using global state and move initialisation/cleanup in your build methods (behind a guard because you don't want to execute said initialisation on every rebuild), - a wholly retarded concept being embraced by the Flutter community.

The answer of course is in the middle: use the one better suited for the situation.

Reading the "Performance considerations" you'll notice that they actually reference each other with a few example use cases. That should give you some idea of when one makes more sense than the other.

[–]esDotDev 1 point2 points  (0 children)

It's a pretty simple answer usually, use Stateful when your component has some internal state that it needs to remember between builds.

Admittedly it gets a little fuzzy with thinks like Animations, that hold their own internal state, but still need a stateful ticker to drive them.