5 ms·

I have a request for all the Flutter folks/fans - it would be great if you all can say something about how you can get over / stay sane with the staircase looki

by harikb 6y ago

I have a request for all the Flutter folks/fans - it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base. I started my career writing single threaded Palm OS apps (64k limit) - there was like 10 possible widgets with 5 possible events on each widget and rest of it was application code. Mobile app development is a different beast now. Yes, I sound like old-man-yelling-at-cloud. Is this table-stakes for all UI and App development?

Lionga 6y ago
You just don't throw everything in a big build method, but make small functions for every logical unit instead. Simple, easy, clean and maintainable.
heavyset_go 6y ago
> it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base. The same way you would in any other code base, with the ample use of names and modules, and breaking nested components and logic into their own classes and functions. The problem is that it requires discipline, or at least a standard style guide, to adhere to. It's similar to JavaScript in that regard, where bad practices can seemingly be ignored or even encouraged.
- runeks 6y ago
  I gotta say that I miss some from of let-binding, so I don't have to choose between (a) local variables plus newline-separated statements, including "return", wrapped in {}, and (b) the lovely syntax of `Widget build = (context) => ...`. E.g. instead of writing Widget helloWidget(BuildContext context) { final db = Provider.of<MyDatabase>(context, listen: false); return Row( children: <Widget>[ Text("Hello, "), FutureBuilder<String>( future: db.username, builder: (ctx, snapshot) => snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(), ), ] ); } i'd like to write: Widget helloWidget = (BuildContext context) => let db = Provider.of<MyDatabase>(context, listen: false) in Row( children: <Widget>[ Text("Hello, "), FutureBuilder<String>( future: db.username, builder: (ctx, snapshot) => snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(), ), ] );
- cutler 6y ago
  Trouble is that in most Flutter code the widget staircase is idiomatic. Swift UI also seems to have chosen the same path.
  - heavyset_go 6y ago
    You're downvoted, but I agree. It's unfortunate, but that is why I say that discipline or an enforced style guide is required.
  - solarkraft 6y ago
    I don't really see the issue. Widget layouts are trees. Why shouldn't you represent them as such in your declarative code?
gladimdim 6y ago
You can also use Flutter Inspector - a UI tree representing your runtime layout. It allows to quickly jump between widgets
liquidise 6y ago
I have [self-diagnosed] Code Style OCD. Like you, the Flutter nesting levels was a major fear entering the space. It feels both ugly and inelegant. I found i was over this fear in days if not hours, and continued to improve with my ongoing discovery of helpful UI components. Furthermore, defining your own components and breaking out inline functions into proper functions in your UI classes goes a long way, too. Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. For the reasons i stated, i don't think it is as important as you might think. If you haven't tried Flutter, particularly for syntactical reasons, i would urge you dip your toes in.
- runeks 6y ago
  > Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. So does VS Code. I stared writing my first Flutter app a couple of weeks ago. I’m using VS Code and I have to say the IDE support is pretty great. Regarding syntax and nesting levels, what I don’t is the `git diff` from wrapping the top-most expression in a new class, thus causing everything inside/below it to be indented further, even though only a single class was added. So e.g. wrapping an outer Column in a SingleChildScrollView causes everything inside the column to change in the diff because of added indentation.
  - kennethh 6y ago
    Use the built in git tool in visual code. It highlights differently for white space or you can also turn off white space differences.
tarkin2 6y ago
Smaller staircases. Split your component into functions. I’ve seen some horribly large components that would be much better if split up. Google should really advise this.
deleted 6y ago
[deleted]

by harikb 6y ago

Lionga 6y ago

You just don't throw everything in a big build method, but make small functions for every logical unit instead. Simple, easy, clean and maintainable.

heavyset_go 6y ago

> it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base. The same way you would in any other code base, with the ample use of names and modules, and breaking nested components and logic into their own classes and functions. The problem is that it requires discipline, or at least a standard style guide, to adhere to. It's similar to JavaScript in that regard, where bad practices can seemingly be ignored or even encouraged.

runeks 6y ago
I gotta say that I miss some from of let-binding, so I don't have to choose between (a) local variables plus newline-separated statements, including "return", wrapped in {}, and (b) the lovely syntax of `Widget build = (context) => ...`. E.g. instead of writing Widget helloWidget(BuildContext context) { final db = Provider.of<MyDatabase>(context, listen: false); return Row( children: <Widget>[ Text("Hello, "), FutureBuilder<String>( future: db.username, builder: (ctx, snapshot) => snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(), ), ] ); } i'd like to write: Widget helloWidget = (BuildContext context) => let db = Provider.of<MyDatabase>(context, listen: false) in Row( children: <Widget>[ Text("Hello, "), FutureBuilder<String>( future: db.username, builder: (ctx, snapshot) => snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(), ), ] );
cutler 6y ago
Trouble is that in most Flutter code the widget staircase is idiomatic. Swift UI also seems to have chosen the same path.
- heavyset_go 6y ago
  You're downvoted, but I agree. It's unfortunate, but that is why I say that discipline or an enforced style guide is required.
- solarkraft 6y ago
  I don't really see the issue. Widget layouts are trees. Why shouldn't you represent them as such in your declarative code?

gladimdim 6y ago

You can also use Flutter Inspector - a UI tree representing your runtime layout. It allows to quickly jump between widgets

liquidise 6y ago

I have [self-diagnosed] Code Style OCD. Like you, the Flutter nesting levels was a major fear entering the space. It feels both ugly and inelegant. I found i was over this fear in days if not hours, and continued to improve with my ongoing discovery of helpful UI components. Furthermore, defining your own components and breaking out inline functions into proper functions in your UI classes goes a long way, too. Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. For the reasons i stated, i don't think it is as important as you might think. If you haven't tried Flutter, particularly for syntactical reasons, i would urge you dip your toes in.

runeks 6y ago
> Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. So does VS Code. I stared writing my first Flutter app a couple of weeks ago. I’m using VS Code and I have to say the IDE support is pretty great. Regarding syntax and nesting levels, what I don’t is the `git diff` from wrapping the top-most expression in a new class, thus causing everything inside/below it to be indented further, even though only a single class was added. So e.g. wrapping an outer Column in a SingleChildScrollView causes everything inside the column to change in the diff because of added indentation.
- kennethh 6y ago
  Use the built in git tool in visual code. It highlights differently for white space or you can also turn off white space differences.

tarkin2 6y ago

Smaller staircases. Split your component into functions. I’ve seen some horribly large components that would be much better if split up. Google should really advise this.

deleted 6y ago

[deleted]