[Interest] [QML] Need advice on frontend architecture

Ben Lau xbenlau at gmail.com
Wed Dec 2 10:59:34 CET 2015


On 2 December 2015 at 06:14, Ronan Jouchet <ronan.jouchet at cadensimaging.com>
wrote:

> On 11/18/2015 12:35 PM, Ben Lau wrote:
>
>> I think there is no popular recommended frontend architecture for
>> QML application yet. And I would like to make one.
>>
>> Since I also code in React/Flux, and it should be a good choice for QML
>> application too. Therefore, I have started a project called QuickFlux to
>> allow people to write their application in a Flux way:
>>
>> https://github.com/benlau/quickflux
>>
>> It provides AppDispatcher plus utility components for QML and C++.
>>
>
> Thanks Ben! (and sorry for the late answer), I'm giving it a try.
>
> At first glance it fulfills its promise, but I'm not sure I'd use it: it's
> indeed close to the Flux API, but would be a heavy change to introduce that
> feels like a lot of fight-against-the-framework trouble.
>
> (I'm not criticizing your solution -which does look awesome!- and I have
> no doubt you know how to work its quirks when they happen. I'm just
> pointing out I'm a Qt newcomer still learning the ropes, and am wary of
> introducing opinionated dependencies I don't control.)
>

Never mind. I understand that there has something will make people
confusing and documentation is not clear yet. It will be great to hear what
people actually think about it.

In fact, the core design of QML, React and even Angular JS are totally
different. Therefore, Flux architecture framework may not be applied in Qt
completely

AngularJS: Two way data binding
QML: One way data binding
React: Store -> Emit Change event -> Re-render

React only apply the "diff" from previous render and current render. That
is why it could achieve a very fast performance.

However, QML did similar things too.The Qt Scene Graph only render the
changed part of screen. Therefore, data binding will not really cause any
performance issue to QML application unless it is poorly designed.

And in fact, it is not possible to write QML application in a way like
React's render loop. If you code in React mind set, there must be a trouble.

Ofcoz you could still declare store component and emit change event for
other view component to fetch data. That will be closer to React style.

Anyway, Qt and React are totally different. You can't avoid
fight-against-the-framework troubles. ;)


>
> I was more hoping for some documentation or blog post helping me
> re-structure our QML in a way that, with 20% of effort:
>   A. Delivers an 80% of the simplicity/maintainability of Flux (or
>      any MVC/MVVM approach helping client state isolation)...
>   B. ... in a way that stays QML-ish and only relies on vanilla QML
>      building blocks.
>
> Examples/talk of such a QML architecture still very welcome :)
>
>
I don't think you could make a Flux like application with using vanilla QML
building blocks.


> On 11/18/2015 12:35 PM, Ben Lau wrote:
>
>> I think it should be fine to code regular GUI application in Qt's
>> javascript engine. In my case, I did made a program to solve a graph
>> problem. Finally I have switched back to C++ code.
>>
>
> Out of curiosity, what made you switch back?


> Finally, for anyone interested in these topics, check out this excellent
> presentation from Thomas McGuire at Qt World Summit 2015, it has some great
> tips (and some controversial ones, one of them being "Avoid JS in QML, just
> do C++").
> [Effective QML] https://www.youtube.com/watch?v=vzs5VPTf4QQ
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20151202/9ba11baa/attachment.html>


More information about the Interest mailing list