Hi Ronan,
On 19 November 2015 at 00:14, Ronan Jouchet <ronan.jouc...@cadensimaging.com > wrote: > Hi. > > I recently joined a nascent QML project with the objective to bring it > from the "working prototype" stage to something maintainable and efficient. > > Previously, my last GUI work was on a web application using React [1] + > Flux [2], which I *loved* for the mental simplicity and testability their > functional model brings (i.e: update the state, be confident that {1. the > view is updated, 2. with good performance regardless of the state mutation > complexity / number of bindings}). > > Now, back to QML, looking at the documentation, examples, and a few blog > posts, > > - I find a good overview of QML language constructs > > - ... as well as tons of simple, mostly stateless widget examples > > , but: > > - I have yet to encounter frontend architecture recommendations (like Flux) > > I think there has no any 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++. I am still finding a best way to adopt Flux in QML application. If you have any suggestion / question, please feel free to ask. - I often stumble on QML constructs that push me into > one-component-directly-mutating-another corners. Drinking the React > kool-aid made me very wary of those, and I'd now actively avoiding them > because they can quickly lead to spaghetti. For example, QML states [3], > and direct mutations using `parent`, `root`, or accessing by id. > > So, as you can expect, I'm trying to bring a Flux-ish approach to our QML > app, by creating central data stores encapsulating {a. my application state > as pure data, b. functions to manipulate the state}, and making my QML > components depend on this pure data. > > But so far it feels like I'm swimming against the tide, plus: > > - I have little idea how performance will evolve down the road. > > - Contrarily to the web application mentioned in the introduction, I also > have to mix my JS state with C++ classes instantiated in my QML, also > bringing their own state, which I use too in QML. > > - My store-observing logic implies regularly using `onXyzChanged` signal > handlers (e.g. to re-generate a ListModel when the source Array changes), > which means bring Data Store attribute `xyz` to the local QML component > scope, which isn't feasible with a current-scope-limited aliases [4], so > I'm using ordinary property references (property var cheeses: > dataStoreInventory.cheeses;), which "allocates a new, unique storage space > for the property", effectively doubling the memory usage of my state, with > unknown memory leaking behavior. > > If you write in strict Flux way, you may add a "updated" signal to your store. And update your UI whatever you have captured the signal. It is not really a common practise for QML, but it is just a matter of do you feel comfortable with it. > - I'm reading lots of very affirmative, but sometimes old, and often > poorly researched articles encouraging QML developers to avoid JS and do > all the logic in C++, save for basic widget arithmetic. As a web developer, > the productivity benefits of JS are obvious to me (plus the library > availability, *when* libraries are content with the exotic JS environment > provided by QML, but that's another question), but these claims are > starting to make me wary of too much JS in my QML app. Or maybe these > cautionary tales are just instances of good tools badly used yielding bad > results? Anyway I'm wondering how much JS is reasonable in a long-running > QML app with serious performance expectations (calculations and heavy 2d/3d > in C++, QML gui) > > 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. > As you can guess, I'm lost in all this. Do you have battlefield-tested > advice/links to structure QML apps? Thanks for your help. > > [1] https://facebook.github.io/react/ > [2] https://facebook.github.io/flux/ > [3] http://doc.qt.io/qt-5/qtquick-statesanimations-states.html > [4] > http://doc.qt.io/qt-5/qtqml-syntax-objectattributes.html#property-aliases > > -- > Ronan > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest