Skip to content
QtWS25 Call for Papers
  • 0 Votes
    3 Posts
    1k Views
    I

    They both seem like dead projects, nothing you can rely on.

    grassator/react-qml last commit was Dec 15, 2017
    only 1 contributor, only active 4 years ago.

    ongseespace/react-qml last commit was Mar 26, 2020
    had 2 contributors, most active 3-4 years ago.

    As you may sensed for the extremely few amount of responses before and considering that ReactJS is since many many years one the most prominent JavaScript library in the world, mostly top 1 (https://2021.stateofjs.com/en-US/libraries/front-end-frameworks). It looks not to be in the priority of the Qt strategy.

    Looking at the architecture of Qt, they seem pretty much incompatible. Qt is a complete stack with a complete e2e experience. Where you don't want to mix other stacks or other frameworks.

    That also means, I think, you cannot for example create QML based components that are reusable in other frontend stacks, where the backend may be anything else. QML are closed components.

    So, in other words no support for Web Components specification: https://www.webcomponents.org/introduction
    which was created to be able to produce reusable components.

    If anybody, disagrees or have more insights, happy to know about it :)

  • 0 Votes
    2 Posts
    647 Views
    C

    Javascript abstracts the concept of pointers. Data is only ever passed around by reference. It is usually safer, since memory management is handled automatically and you can be sure an object equals another object if they are compared.

    If you need to compare objects to see if they are identical, you may have better luck creating a "compare" method that directly compares primitive attributes (strings can be compared directly, for instance).

    Hope this helps, sorry I can't provide a more specific implementation suggestion. Too many details to focus on at once.

  • 0 Votes
    1 Posts
    271 Views
    No one has replied
  • 0 Votes
    4 Posts
    2k Views
    devDawgD

    Okay, so I have made a fair amount of progress since I last commented.

    For either of my strategies, I would come across this Javascript error:

    TypeError: property of object such and such is not a function.

    I realized, with the help of a colleague, that my assignment of the model was what was screwing me. Instead of creating a .qml file to serve as my custom model, I was using the length of a QVector within a context property from C++, meaning that my model was nothing but a number! Hence, zero access to the Javascript array functions.

    So, my new approach is pre-load my models in .qml, rather than constantly make Q_INVOKABLE method calls from a C++ context property class.

  • 0 Votes
    4 Posts
    3k Views
    6thC6

    Well, there is some it seems... just not all? I note there's quite a few comments: // ECMAScript 6 @: http://doc.qt.io/qt-5/qtqml-javascript-functionlist.html

    While I've not used it - that page has:
    map(callbackfn [, thisArg])
    but not Set.. not sure if that helps...

  • 1 Votes
    4 Posts
    5k Views
    romsharkovR

    After a detailed research of various asynchronous techniques such as Promises, Futures, Tasks and Reactive Extensions we came with a new paradigm that solved all our asynchronous problems very elegantly: The Streams Paradigm

    It's inspired by the reactive approach, though superior in many aspects such as abstraction, abortion, resumables etc.

    It's a completely rethought way of writing declarative code, making complex asynchronous operations and transactions (and probably even concurrency) a piece of cake! Nearly everything can be represented, thus abstracted away by a stream..

    UI Elements Sockets Requests (HTTP etc.) Calculations the list goes on...

    This way streams become a consistent protocol of asynchronous and concurrent communication between various application components ranging from the UI frontend to the networked backend.

    We published the first beta release of a QML implementation with a working example aboard, be sure to check it out!

    https://qbeon.github.io/QuickStreams/

  • 0 Votes
    4 Posts
    2k Views
    SGaistS

    Sorry, I haven't worked on the internals of V4 so I can't really comment on that error.

    Maybe QTBUG-50387 and related might shed some light.

  • 0 Votes
    5 Posts
    2k Views
    p3c0P

    @Mathan-M Convert it to list using toList

  • 0 Votes
    5 Posts
    1k Views
    JKSHJ

    @Stefan-Monov76 said in "Some JS files act more like libraries - they [...] never manipulate QML component instances directly" - middle ground?:

    Update: I got a working solution on StackOverflow, you can see it here :)

    Thanks for sharing, and for reporting the doc issue :)