5 ms·

Looks like Flutter has been updated as well. I only wish the state management wasn't so convoluted in Flutter

PedroBatista 3y ago
Yes, Google people always have to do some big-brain stuff in their projects. I’m sure the initial reasons for their state management were valid and their heart was pure, but god damn it’s a mess.
- mdhb 3y ago
  I don’t know if I actually buy this statement at face value. It mostly extends from the fact that the Flutter community in general is stuck on a perpetual loop talking about it because there is no “one true way blessed by Google wrapped up into a single package that is appropriate for all use cases”. But in practice it’s exactly the same as any other OOP language or framework where you can pick from multiple paradigms depending on your use case. Want to use a state machine? There are options for that. Same goes for Rx patterns, local state, redux patterns and more. There are a lot of extremely complicated apps who don’t have any issue with it in reality and the drama is very much a community problem rather than a real issue.
  - PedroBatista 3y ago
    That too, but the existence of this page: https://docs.flutter.dev/data-and-backend/state-mgmt/options https://docs.flutter.dev/data-and-backend/state-mgmt/options on the official site it's an indication that something's up with state management. The existence of the Stateless vs Stateful widgets, the "class YourState extends State<>" classes, you can't put a stateful widget inside a stateless widget and a range of many other things that aren't at the top of my mind right now. Of course that are valid reasons of all of this, of course there are "other better ways", but when a large part of your user base wrestles with this for years, it really doesn't matter how smart and correct you are because it is in fact a problem.
  - pkphilip 3y ago
    There are ways of handling state - which have been in use for decades! and in applications with a lot of UI state with dozens of forms (screens) etc. How many of them had these convoluted ideas of state vs stateless widgets, watch, notifiers etc? Consider examples like Visual Basic, Delphi etc.. The GUI components would be aware when their state changed and would update its own display. But now you can't do that anymore - either you redraw the whole screen or not at all. You could receive/send data asynchronously if needed in a separate thread and update the main thread which managed the GUI etc. None of this required jumping through hoops like we are doing now. Example: This is how data could be fetched asynchronously and the UI updated on termination of the call in Delphi: procedure TMainForm.ButtonClick(Sender: TObject); begin RESTRequest.ExecuteAsync( procedure begin Memo.Lines.Add(RESTResponse.Content); end, True, True, procedure(Error: TObject) begin Memo.Lines.Add(Exception(Error).Message); end; end; Note: even with all of the Pascal ceremony of begin/end etc, this code is more succinct and far cleaner and much easier to debug than the state/stateless nonsense that is spread out all over a Flutter codebase. And yes, I do remember that Visual C++ had a bit of a convoluted state management logic for MFC.
    - munificent 3y ago
      > applications with a lot of UI state with dozens of forms (screens) etc. How many of them had these convoluted ideas of state vs stateless widgets, watch, notifiers etc? Consider examples like Visual Basic, Delphi etc. ... The GUI components would be aware when their state changed and would update its own display. I wrote and maintained a lot of large GUI applications in that style during that time, as well as building a couple of GUI frameworks that operated that way. It's fine for a while and as long as the UI is fairly static and there's mostly a 1:1 mapping between pieces of data and UI that shows it. But it scales horribly once you find yourself in a situation where you have lots of computed model data, or model data that is shown in many places in the UI, or a highly flexible UI that changes a lot. You end up in a sprawling mess of event handlers, orphaned bits of UI that aren't on screen but are still inadvertently listening to events, zombie UI that forgot to register an event handler and isn't updating, computer model state that for now good reason lives inside one random button, and then other UI code that is pulling that state from that button and breaks if the button isn't on screen, etc. The reactive style / immediate mode style where you essentially redraw the entire UI based on the current model state is so much simpler and cleaner. Yes, state management can still be weird, but that's because mutable state is hard. There's no silver bullet.
  - pkphilip 3y ago
    This is how flet.dev handles state and UI. Note how simple this is vs the crap that is the standard way of managing state in flutter: By the way, flet.dev is actually using Flutter for rendering!! def main(page: ft.Page): page.title = "Flet counter example" page.vertical_alignment = ft.MainAxisAlignment.CENTER txt_number = ft.TextField(value="0", text_align=ft.TextAlign.RIGHT, width=100) def minus_click(e): txt_number.value = str(int(txt_number.value) - 1) page.update() def plus_click(e): txt_number.value = str(int(txt_number.value) + 1) page.update() page.add( ft.Row( [ ft.IconButton(ft.icons.REMOVE, on_click=minus_click), txt_number, ft.IconButton(ft.icons.ADD, on_click=plus_click), ], alignment=ft.MainAxisAlignment.CENTER, ) )
    - mhoad 3y ago
      Are we just debating imperative vs declarative UI patterns? I think that debate was settled a long time ago to be fair. If you happen to like that approach more that’s cool keep using it but it’s not the done thing in any mainstream modern UI framework that I’m aware of for a reason.
      - pkphilip 3y ago
        Delphi is still being used. And by the way, there is really no reason to use the complicated state management functions even in a declarative UI pattern
        mhoad 3y ago
        Delphi is most certainly not a solution that anyone is reaching for of any kind of regularity in 2023 but again, if you like it keep using it but I’m more than happy to put Flutter up against Delphi as a way of building user interfaces.
- pkphilip 3y ago
  Agreed

Yes, Google people always have to do some big-brain stuff in their projects. I’m sure the initial reasons for their state management were valid and their heart was pure, but god damn it’s a mess.

mdhb 3y ago
I don’t know if I actually buy this statement at face value. It mostly extends from the fact that the Flutter community in general is stuck on a perpetual loop talking about it because there is no “one true way blessed by Google wrapped up into a single package that is appropriate for all use cases”. But in practice it’s exactly the same as any other OOP language or framework where you can pick from multiple paradigms depending on your use case. Want to use a state machine? There are options for that. Same goes for Rx patterns, local state, redux patterns and more. There are a lot of extremely complicated apps who don’t have any issue with it in reality and the drama is very much a community problem rather than a real issue.
- PedroBatista 3y ago
  That too, but the existence of this page: https://docs.flutter.dev/data-and-backend/state-mgmt/options https://docs.flutter.dev/data-and-backend/state-mgmt/options on the official site it's an indication that something's up with state management. The existence of the Stateless vs Stateful widgets, the "class YourState extends State<>" classes, you can't put a stateful widget inside a stateless widget and a range of many other things that aren't at the top of my mind right now. Of course that are valid reasons of all of this, of course there are "other better ways", but when a large part of your user base wrestles with this for years, it really doesn't matter how smart and correct you are because it is in fact a problem.
- pkphilip 3y ago
  There are ways of handling state - which have been in use for decades! and in applications with a lot of UI state with dozens of forms (screens) etc. How many of them had these convoluted ideas of state vs stateless widgets, watch, notifiers etc? Consider examples like Visual Basic, Delphi etc.. The GUI components would be aware when their state changed and would update its own display. But now you can't do that anymore - either you redraw the whole screen or not at all. You could receive/send data asynchronously if needed in a separate thread and update the main thread which managed the GUI etc. None of this required jumping through hoops like we are doing now. Example: This is how data could be fetched asynchronously and the UI updated on termination of the call in Delphi: procedure TMainForm.ButtonClick(Sender: TObject); begin RESTRequest.ExecuteAsync( procedure begin Memo.Lines.Add(RESTResponse.Content); end, True, True, procedure(Error: TObject) begin Memo.Lines.Add(Exception(Error).Message); end; end; Note: even with all of the Pascal ceremony of begin/end etc, this code is more succinct and far cleaner and much easier to debug than the state/stateless nonsense that is spread out all over a Flutter codebase. And yes, I do remember that Visual C++ had a bit of a convoluted state management logic for MFC.
  - munificent 3y ago
    > applications with a lot of UI state with dozens of forms (screens) etc. How many of them had these convoluted ideas of state vs stateless widgets, watch, notifiers etc? Consider examples like Visual Basic, Delphi etc. ... The GUI components would be aware when their state changed and would update its own display. I wrote and maintained a lot of large GUI applications in that style during that time, as well as building a couple of GUI frameworks that operated that way. It's fine for a while and as long as the UI is fairly static and there's mostly a 1:1 mapping between pieces of data and UI that shows it. But it scales horribly once you find yourself in a situation where you have lots of computed model data, or model data that is shown in many places in the UI, or a highly flexible UI that changes a lot. You end up in a sprawling mess of event handlers, orphaned bits of UI that aren't on screen but are still inadvertently listening to events, zombie UI that forgot to register an event handler and isn't updating, computer model state that for now good reason lives inside one random button, and then other UI code that is pulling that state from that button and breaks if the button isn't on screen, etc. The reactive style / immediate mode style where you essentially redraw the entire UI based on the current model state is so much simpler and cleaner. Yes, state management can still be weird, but that's because mutable state is hard. There's no silver bullet.
- pkphilip 3y ago
  This is how flet.dev handles state and UI. Note how simple this is vs the crap that is the standard way of managing state in flutter: By the way, flet.dev is actually using Flutter for rendering!! def main(page: ft.Page): page.title = "Flet counter example" page.vertical_alignment = ft.MainAxisAlignment.CENTER txt_number = ft.TextField(value="0", text_align=ft.TextAlign.RIGHT, width=100) def minus_click(e): txt_number.value = str(int(txt_number.value) - 1) page.update() def plus_click(e): txt_number.value = str(int(txt_number.value) + 1) page.update() page.add( ft.Row( [ ft.IconButton(ft.icons.REMOVE, on_click=minus_click), txt_number, ft.IconButton(ft.icons.ADD, on_click=plus_click), ], alignment=ft.MainAxisAlignment.CENTER, ) )
  - mhoad 3y ago
    Are we just debating imperative vs declarative UI patterns? I think that debate was settled a long time ago to be fair. If you happen to like that approach more that’s cool keep using it but it’s not the done thing in any mainstream modern UI framework that I’m aware of for a reason.
    - pkphilip 3y ago
      Delphi is still being used. And by the way, there is really no reason to use the complicated state management functions even in a declarative UI pattern
      - mhoad 3y ago
        Delphi is most certainly not a solution that anyone is reaching for of any kind of regularity in 2023 but again, if you like it keep using it but I’m more than happy to put Flutter up against Delphi as a way of building user interfaces.
pkphilip 3y ago
Agreed