Writing QML Application in a Flux way

[benlau]

@Vincent007 hmm. Let's me think about it. By the way, I am going to publish another article with similar topic but better explanation, code and diagram on a blog in this week.

[clogwog]

Hi Ben,

i'm not sure if this is a bug but i'm trying to figure out how to use quickflux by making a small change to the todo example.

I added a 'mark all items done' button and mark all items as done. however the ui doesn't always update.

example: 1) start application (3 items in list 1 in done)
2) press 'all done' -> all items disappear (expected)
3) show all items by checking 'show completed' (expecteD)
4) unmark one item (for example 'Task A')
5) press 'all done' -> 'Task A' doesn't update to done ?

if i uncheck and re-check 'show completed' the model and view are back in sync.

https://github.com/clogwog/fluxtest1

am i missing something ?

[benlau]

@clogwog I can't reproduce your problem in my example program and in your code. When it is set to "Show Completed". It will show every tasks. So if you set a task done in "Show Completed" mode. It won't disappear. The behaviour should be correct.

[clogwog]

no, i was expecting it to show all tasks as you said, i just expected it to switch back to checked when i pressed the 'all done' button

so when you are in the 'show completed' mode in step 5 with a task you just set to 'uncompleted' and then press 'all done' your tasks goes back to checked ?

[benevo]

@benlau

Hi Ben,

Thank for your sparking idea about this area, It's charming & meaningful to do this.
BTW, could U show the link of Ur another article with better description if possible.

Thanks !

Happy New Year !

[benlau]

@clogwog said:

no, i was expecting it to show all tasks as you said, i just expected it to switch back to checked when i pressed the 'all done' button

so when you are in the 'show completed' mode in step 5 with a task you just set to 'uncompleted' and then press 'all done' your tasks goes back to checked ?

oh, you mean in your program. I didn't realize that you have added a "All Done" button. The problem is about data binding in Qt. Qt use one-way data binding. Although it has binded CheckBox.checked to model.done , the binding will lost whatever it is toggled by user event. It is overridden by system. And that is why step 5 failed.

You may solve this problem in this way:

At TodoVisualDataModel.qml:

    delegate: TodoItem {
        id:item
        uid: model.uid
        title: model.title
        property bool done: model.done

        onDoneChanged: {
            checked = model.done;
        }

        Component.onCompleted: {
            item.VisualDataModel.inNonCompleted = Qt.binding(function() { return !model.done})
        }
    }

@benevo: thx. The article is not ready yet. I will post it within this few days.

[clogwog]

@benlau thank you for taking the time to tell me this !
i have learned something new.

kind regards,
tom

[stackprogramer]

nice,thanks for share,i think MVC is too good for our Qml project.

[benlau]

@benevo @Vincent007 The new article is ready.

Action-Dispatcher Design Pattern for QML — Medium

[Vincent007]

@benlau

Do you think it is beneficial to use Action-Dispatcher Design Pattern in C++ ?
If Yes, would you mind giving us an example in C++ ?

[benlau]

@Vincent007 yes, I think so. However, I am not coding in pure C++ way. I could provide a C++ and QML mixing example code. Before it is ready, you may take a look about the C++ API of QuickFlux:

QFAppDispatcher Class | QuickFlux 1.0

[Vincent007]

@benlau Thank for your new example in advance!

I think it is time to show your work to Qt contributors via Qt development mailing list. I think your work can help Qt contributors think how QML should be evolved in feature.

[Vincent007]

Someone implemented FLUX too!

[benlau]

@Vincent007 Interesting. thx.

I am happy to see more people talking about using Flux in Qt/QML even they are not using my library. That means the approach really works. Moreover, until now, I don't see a standard QML application guide available yet. I would like to draw more attention from Qt users / developers to think about this problem.

p.s I have added a FAQ about why it need a Dispatcher instead of just a QObject:

Why use AppDispatcher instead of listening from AppActions directly?

[benlau]

v1.0.4 has been released.

New Components

KeyTable

KeyTable is an object with properties equal to its key name. Once it's construction is completed, it will search all of its string property. If it is a string type and not assigned to any value, it will set its value by its name. It can be used to create ActionTypes.qml in QuickFlux Application.

Example:

KeyTable {

    // It will be set to "customField1" in Component.onCompleted callback.
    property string customField1;

    // Since it is already assigned a value, KeyTable will not modify this property.
    property string customField2 : "value";

}

Filter

Filter component listens for the parent's dispatched signal, if a dispatched signal match with its type, it will emit its own "dispatched" signal. Otherwise, it will simply ignore the signal.

This component provides an alternative way to filter incoming message which is suitable for making Store component.

Example:

pragma Singleton
import QtQuick 2.0
import QuickFlux 1.0
import "../actions"

AppListener {
    id: store

    property ListModel model: ListModel { }

    Filter {
        type: ActionTypes.addTask
        onDispatched: {
            model.append({task: message.task});
        }
    }

}

It is not suggested to use nested AppListener in a Store component. Because nested AppListener do not share the same AppListener::listenerId, it will be difficult to control the order of message reception between store component.

In contrast, Filter share the same listenerId with its parent, and therefore it is a solution for above problem.

Changes

AppScript

1. Added "autoExit" property

examples/todo

1. Migrated to use KeyTable and Filter
2. Added StoreAdapter to demonstrate how to use "waitFor" between stores.

StoreAdapter.qml

import QtQuick 2.0
import "../stores"

Item {

    Component.onCompleted: {
        TodoStore.waitFor = [UserPrefsStore.listenerId];
    }

}

[benlau]

QuickFlux v1.0.5 has been released.

New Component

ActionCreator

ActionCreator is a component that listens on its own signals, convert to message then dispatch via AppDispatcher. The message type will be same as the signal name. There has no limitation on number of arguments and data type.

For example, you may declare an ActionCreator based component as:

import QtQuick 2.0
import QuickFlux 1.0
pragma singleton

ActionCreator {
  signal open(string url);
}

It is equivalent to:

import QtQuick 2.0
import QuickFlux 1.0
pragma singleton

Item {
   function open(url) {
     AppDispatcher.dispatch(“open”, {url: url});
   }
}

Changes

QFAppDispatcher

1. Added dispatch(const QString &type, const QVariant& message) member method for C++ to dispatch message.

[benlau]

v1.0.6 has been released

New Component

1. Object - It is a QtObject that able to hold children component.

Changes

1. Filter

a) Now it could listen from any component that has "dispatched" signal

Item {
  signal dispatched(string type, var message)

  Filter {
    type: ActionTypes.addItem
    onDispatched: {}
  }
}

b) Support to hold children item

Filter {
  Promise {
  }
}

c) Added "types" property to filter multiple types of action

Filter {
  types: [ActionTypes.addItem , ActionTypes.removeItem]
}

2. ActionCreator

a) Added "genKeyTable()"

According to the registered signal in the ActionCreator object, it could create a key table (ActionTypes) in QML.

3. KeyTable

a) Added getSourceFile()/genHeaderFile() - Generate a C++ header and source file for this KeyTable object.

Bug Fix:

1. [QTBUG-58133] Crash on emitting a signal from C++ to QML with undefined QJSValue - Qt Bug Tracker

2. qmlRegisterType under MSVC goes nuts · Issue #7 · benlau/quickflux

Preview of Quick Flux 1.1

As a preview of new components in v1.1, they are also included in this release. But the API is not frozen. It may change in the official release.

1. Dispatcher - non-singleton Dispatcher
2. MiddlewareList / Middleware - a mechanism to extend the functionality of dispatcher allowing for advanced asynchronous workflow and integration with visual component like FileDialo
3. Store - A replacement of AppListener
4. Hydrate - Serialize and deserialize a store to/from a JSON object.

[benlau]

v1.1 has been released!

Detailed explanation:

What is new in Quick Flux 1.1?

New Features

1. Support Non-singleton dispatcher.

2. Middleware - a mechanism to extend the functionality of dispatcher allowing for advanced asynchronous workflow and integration with visual component like FileDialog.

3. Store - A replacement of AppListener that could listen from non-singleton dispatcher, and re-dispatch the action message to another Store components sequentially. It could avoid the over-complicated waitFor mechanism.

4. Hydration - Serialize and deserialize a store to/from a QVariantMap object.

New Components

1. MiddlewareList & Middleware

2. Store

3. Hydrate

See Class Document for details

Bug Fix

https://bugreports.qt.io/browse/QTBUG-58133

Reference

What is new in Quick Flux 1.1?

[GTDev]

I like the proposed architecture by Ben Lau a lot!

However, for small QML apps, you can also introduce a similar pattern with a smaller and lightweight solution purely in QML.

If you're interested, you can find the full developer guide here: https://v-play.net/apps/avoid-cpp-models-qt

Cheers,
GTDev