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?

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.

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.

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];
    }

}

New Components

1) AppScript

AppScript is a helper component to handle asynchronous sequential workflow. The immediate benefit of using AppScript is the centralisation of code in a place. Instead of placing them within onXXXX code block in several components in several places.

2) AppListenerGroup

AppListenerGroup collects listener ID from all of its child AppListener and initialize their waitFor property.
It could be used as the base type of a Store component for setup dependence between them.

MyStore1.qml

AppListenerGroup {
    AppListener {
    }
    AppListener {
    }
}

MyStore2.qml

AppListenerGroup {
   waitFor: MyStore1.listenerIds
}

Changes

AppDispatcher

1. Added addListener() function

Registers a callback to be invoked with every dispatched message. Returns a listener ID that can be used with waitFor().

2. Added removeListener() function

Remove a callback by the listenerId returned by addListener

3. Added waitFor() function

Waits for the callbacks specified to be invoked before continuing execution of the current callback. This method should only be used by a callback in response to a dispatched message.

AppListener

1. Added “listenerId” property

The listener ID of this component. It could be used with AppListener.waitFor/AppDispatcher.waitFor to control the order of message delivery.

2. Added “waitFor” property

If it is set, it will block the emission of dispatched signal until all the specified listeners invoked.

Example code:

AppListener {
  id: listener1
}

AppListener {
  id: listener2
  waitFor: [listener1.listenerId]
}

Critical Changes

The first argument of dispatched signal has been changed from "name" to "type", for following the naming convention of Flux.

signal dispatched(string type,object message)

Remarks: It won't affect code that uses filter property.

Updated example code:

// Listen for multiple messages.
AppListener {
    onDispatched: {
        switch (type) {
            case "messageType1":
                // ...
                break;
            case "messageType2":
                // ...
                break;
        }
    }
}

Other Changes

QFAppDispatcher

Added new method: "singletonObject"

    /// Obtain a singleton object from package for specific QQmlEngine
    static QObject* singletonObject(QQmlEngine* engine,QString package,
                                    int versionMajor,
                                    int versionMinor,
                                    QString typeName);

Changes:

AppListener

Added new properties, “filter” and “filters”. Once it is set, only message with name matched will emit “dispatched” signal.

By using “filter" property, users could write their listener in a more simple way:

New Method:

AppListener {
    filter: “NewItem"
    onDispatched: {
       // Code to handle “NewItem” message here.
   }
}

Old method:

// Listen for multiple messages.
AppListener {
    onDispatched: {
        switch (name) {
            case "messageType1":
                // ...
                break;
            case "messageType2":
                // ...
                break;
        }
    }
}

`
or

AppListener {

  Component.onComponented: {
    on("messageType1",function() {
       /// Your code here.
    });
    on("messageType2",function() {
       /// Your code here.
    });
  }
}

Classes

• AppDispatcher
• AppListener