Consider using flet-routed-app for routing

[iron3oxide]

Since less (boilerplate) code and standardization should be aimed for, especially when it comes to routing, it might be worthwhile to refactor the app directory a bit in order to use the flet-routed-app library. Being the maintainer of said library, I will adapt it to the needs of tuttle wherever necessary.

[iron3oxide]

Small update on this: template routes are now integrated into the library, which was one of the main inhibiting factors. The next big one to tackle is that views don't receive a uniform set of parameters (excluding route parameters of course).

Since every one of the varying parameters (including TuttleParams) seems to be some member of the TuttleApp and each ViewBuilder in the library will automatically receive the RoutedApp as an attribute when it is added to said app, I suggest a refactor which would move the responsibility of passing app attributes/methods to the respective view into the build_view method of a custom TuttleViewBuilder class that inherits from the abstract ViewBuilder class.

This would either mean adding something like on_theme_change to TuttleParams as an optional attribute or creating a separate ViewBuilder implementation for each view that requires special parameters. Which one would you prefer?

[vlad-ed-git]

@iron3oxide add on_theme_change to TuttleParams.

[clstaudt]

Lacking much experience with Flutter / Flet, I don't have a strong opinion on this particular issue.

In general, I give a lot of importance to code readability and accessibility. We need to make life easy for open source contributors through the right architecture decisions. I'd ask you to consider if passing long lists of callbacks and big parameter sets to the various components could make the code base hard to navigate and understand.

[clstaudt]

@iron3oxide Do you want to keep us up to posted on your development progress by creating a branch and a draft pull request?

[iron3oxide]

Lacking much experience with Flutter / Flet, I don't have a strong opinion on this particular issue.

In general, I give a lot of importance to code readability and accessibility. We need to make life easy for open source contributors through the right architecture decisions. I'd ask you to consider if passing long lists of callbacks and big parameter sets to the various components could make the code base hard to navigate and understand.

In this instance, I'd argue it might make the code more readable, but certainly not less.

In general, I find that the current architecture could be more accessible. It took me some time, blog posts about the MVI pattern and a study of #76 to understand what was going on. Maybe a small collection of diagrams explaining the architecture could help? The alternative would of course be a thorough refactoring, which would slow down the project considerably.

@iron3oxide Do you want to keep us up to posted on your development progress by creating a branch and a draft pull request?

Will do, I'm starting to get out of the assessment/analysis phase.

[clstaudt]

In this instance, I'd argue it might make the code more readable, but certainly not less.

Yes, I am counting on your proposal to simplify some things @iron3oxide. Thanks for your effort.

@vlad-ed-git and I have so far worked out the current architecture and it's a work in progress. @vlad-ed-git has introduced the MVI pattern because

• it's typical in app development
• it offers clear separation of concerns, encapsulation and decoupling of view and backend layer (for example, the data layer would be easy to switch out from under the UI)

In general I think that it's a good idea to follow a MVI pattern. However, decoupling view and backend remains a challenge, and the MVI approach is neither trivial to apply, nor is it something that can be applied mechanically to yield perfect decoupling. You can still entangle UI and backend in subtle ways while building view, intent and data source classes.

I agree that the current architecture poses some challenges. And the UI code is relatively verbose. We may be able to make it more concise, but verbosity may also simply come from using Flet / Flutter.

Here is a wonderful quote from a talk on software architecture that describes my attitude:

I hate code and I want as little of it as possible in our product.

Documentation yes, but the architecture is also a work in progress so we haven't invested in writing it down.

The alternative would of course be a thorough refactoring,

Any specific ideas @iron3oxide ?

[iron3oxide]

To preface this: I found this blog post about the MVI pattern and this comparison to other architecture patterns to be very enlightening, though they are both a bit Android specific. While their defintions of MVI differ a bit, they seem to agree on the following:

1. a presenter is useful or even necessary to achieve separation of concerns and low coupling
2. the view should only be concerned with displaying the UI and propagating UI events
3. the view should be stateless

These principles/recommendations are not being followed right now in tuttle, which was certainly a reason for my initial confusion.

Any specific ideas @iron3oxide ?

I am by no means an expert on the MVP pattern, but I found it to be intuitive and helpful when used with flet, hence my MVP counter example project. If tuttle were to adopt a similar architecture (I'm totally on board with the MVI definition of the comparison blog post for example), it would have the following benefits:

• some code could be removed, because the presenter would have knowledge of the app instance, so e.g. TuttleViewParams wouldn't be needed anymore.
• the three principles mentioned above would be followed, which would mean better separation of concerns, testability etc.

The downsides would be:

• time and effort needed for refactoring
• more files (I take it you are not a fan of that @clstaudt), as each view module would need at least an extra presenter.py file and ideally also a protocols.py file if one doesn't want to cram the protocol classes into existing files

[clstaudt]

Thanks for the input @iron3oxide. Need some time to study that.

As for the pros and cons:

some code could be removed, because the presenter would have knowledge of the app instance, so e.g. TuttleViewParams wouldn't be needed anymore.

I struggle frequently with not having access to the app instance. And a helper class like TuttleViewParams is a bit of an architecture smell because it is a bag of unrelated things that need to be passed around, right?

time and effort needed for refactoring

Accessible architecture with sparse code is very important, there are a lot more features on the roadmap. So better sooner than later. Possibly after release of version 1.0beta to the non-Python-speaking public.

more files (I take it you are not a fan of that @clstaudt), as each view module would need at least an extra presenter.py file and ideally also a protocols.py file if one doesn't want to cram the protocol classes into existing files

Indeed not a fan of many files, especially if it's an unpythonic habit carried over from C++ and Java-like languages (extreme case: one class per file). If it gives the project a clear structure though adding more files can be justified.

[clstaudt]

2. the view should only be concerned with displaying the UI and propagating UI events
3. the view should be stateless
   These principles/recommendations are not being followed right now in tuttle, which was certainly a reason for my initial confusion.

@iron3oxide Did you find some code examples that go against these principles?

[iron3oxide]

I struggle frequently with not having access to the app instance. And a helper class like TuttleViewParams is a bit of an architecture smell because it is a bag of unrelated things that need to be passed around, right?

Agreed.

Accessible architecture with sparse code is very important, there are a lot more features on the roadmap. So better sooner than later. Possibly after release of version 1.0beta to the non-Python-speaking public.

Should I finish the PR related to this issue beforehand? Feels like waiting for the architecture to be settled might be wiser.

Indeed not a fan of many files, especially if it's an unpythonic habit carried over from C++ and Java-like languages (extreme case: one class per file). If it gives the project a clear structure though adding more files can be justified.

I'm not necessarily a fan of "one class per file" either, but I much prefer it to generically named files/modules with a lot of loosely related functionality inside. IMHO, the logic/inner workings of a project can be expressed in a reasonably verbose and well-organized file structure. If I search for a functionality, I'd rather spend 10 seconds navigating a large file tree to find the file I am 100% sure it is located in than spend the same 10 seconds or less searching through three possible files in a smaller file tree. Anyway, this is probably a matter of personal preference.

@iron3oxide Did you find some code examples that go against these principles?

Take projects/view.py for example:

• ProjectFiltersView very explicitly has a state
• ProjectEditorScreen and other Screens have instance variables that constitute state, e.g. self.tag
• None of the views in the file propagate events, they all have their own event handlers which sometimes contain business logic, e.g. ProjectEditorScreen.on_save()