Redux, the ideal Flutter pattern?

When starting with Flutter I was looking for recommendations for App architecture and most of the time I found references to the Redux pattern.
I’m really honest, Redux never appealed to me. I understand the idea behind the unidirectional data flow but it just seemed too much overhead.

But I wanted to take it to a test and try to create App that is identical to one created with Redux but with the RxVAMS pattern (which I proposed in my last blog post) .

When Iiro Krankka open sourced his beautiful App inKino which is build using redux I had my candidate.

inKino

I asked Iiro if it would be ok if I take his App and refactor it to RxVAMS and he is looking forward to the outcome.

Trying to find out how an Redux app works turned out to be more difficult than expected. Normally when inspecting source code of an app someone else wrote I start with the UI trying to follow the program flow that is triggered by an user action. Trying to do that by using the IDE’s “Go to definition” and “Find all references” didn’t really help because of the way Redux decouples classes. I can only agree with Paul Betts on this:

paulbettsonredux

Comparing the project structure

folder-structure-reduxfolder-structure-rx

The Redux version needs 24 classes for its state management where the Rx version only uses one: app_model.dart


Raw numbers

I wrote a small analysis tool DartStatistics to count code lines, characters and number of classes:

Version Code Lines Code characters classes
Redux 3109 74561 75
RxVAMS 2412 56137 44

This means Redux needs about 30% more lines and characters of code than RxVAMS to achieve the same functionality.

But what if the App gets more complex?

As this App only has one real Page with user interaction I use only one class the AppModel to hold all state of the App. If the App would consists of more complex pages the AppModel would provide a PageModel for each of this Pages that would relay data to the AppModel or directly to the service layer.

The Redux version stores all app state inside one store class so not so much difference here but it needs a lot more code to access and modify it.

But, but Redux will prevent a lot of errors!

True, the fact that views cannot modify state directly but only over dispatching actions might beware you of potential errors but for the price that your code gets much harder to understand and you have to create much more code to reach that goal.
More code also means more places to make mistakes.

Using Streams and RxCommands to communicate between model and view you get an easier to understandable architecture that works without side effects too and you always can follow your code using your IDE’s search commands.

Readability before everything else

If you ever came back to one of your own project after a year you know the feeling to have the feeling someone else must have written this code. Same for any developer that gets the task of continuing the development of a project because the original creator has left the company. So easy to understand and to follow code is paramount.

Why do we use complex patterns?

  • Reusability of code: I really would like to know how many of you have really reused bigger parts of an App in completely different one that wouldn’t be better placed in a independent library from the begin.
  • Exchangeability of components: Often be introduce additional abstraction layers. But who of you have really changed the database after an app was finished?
  • Extensibility: I think it was Kent Beck the creator of Extreme Programming how made the point that using modern IDEs it’s pretty easy to make big refactorings even in large code bases. Having automated tests implemented make sure that you don’t accidentally break something.
  • Error prevention: State management is one of the most difficult areas of any App so using patterns that preventing side effects are a good idea. If one pattern will save you at the end of the day will only show time. Choose a pattern that doesn’t compromise understandability of your code.
  • Testability: This is actual the one that has shown its benefits in daily use. But even here I always will prefer manual Dependency injection before automagically working IOC containers.

I don’t say that these goals are not important and may be helpful from time to time but I want to encourage you to question existing development trends and hypes. Trying to strive for simplicity is a good goal overall.

Try it on your own

O.K. you got it, I don’t like Redux 🙂 You don’t have to believe me so give it a try yourself. Clone both repositories and try to understand how the apps work and share your experiences with us in the comments. I’m really curious to hear them.

Here are the repositories:

Redux inKino

RxVAMS inKinoRx

I’m still exploring how to refine the use of RxCommands with Flutter and there are still some points where I’m not completely satisfied but I will continue this exploration and hope some of you will join me.

Contact me:

9 thoughts on “Redux, the ideal Flutter pattern?

  1. Günter Zöchbauer says:

    Why do we use complex patterns?

    I think the most important point is missing here.

    Patterns are well understood and well documented.

    This makes them easier to learn and replicate and also requires less documentation in code and makes communication easier because there provide established terminology.

  2. Martin Nowosad says:

    You should state that Redux IS the architecture of the Project. Which is a big no go, since the decision to choose frameworks and databases and other details should be one of the last ones. A clean architecture should be completely decoupled from any 3rd party frameworks. By picking Redux you’re not only choosing the framework at a very early stage, you’re coupling your architecture to it. Your App is basing on Redux. A more experienced developer should be thinking twice before giving the potential of his software architecture away to redux.

    • admin says:

      Not sure that you read the post carefully enough. My version of the App doesn’t use redux.
      Also redux isn’t only a framework but also an architectural pattern.

    • GĂĽnter Zöchbauer says:

      Redux is more a pattern than a framework.
      Using packages to avoid some boilerplate doesn’t count as “framework” to me.
      Where would that end? Not using standard libaries?

      • Swav Kulinski says:

        Agree, simple implementation doesn’t require any library at all. Just follow the principles of the pattern. Library is to provide decoupling when your app gets bigger.

        My favourite part of redux is this rule set which doesn’t constrain implementation but enforces the right way of thinking.

        Flutter and ReactNative stand on the ground of giving away power that engineers have (to do right or wrong things) and give it to UX designers (we usually don’t want to listen to)

  3. Oskar says:

    Hi, great post! I have a question – what is the best way to manage advanced project with few modules? Here is my case:
    App starts, then checks if user is logged in. If true go to Dashboard, else go to login page.
    Logged user can open drawer and see all modules (Tasks, Chat, Contacts, Settings, etc.). How should I set current page in that pattern? By changing body part in Main Page?
    I will by grateful for your help.

    • admin says:

      Hi Oskar,

      I would make a StartUpPage the BasePage of your App and push a LoginPage on top for login and replace that with your Dashboard page after successful login.

Leave a Reply

Your email address will not be published. Required fields are marked *