5 ms·
Here's an equivalent example for your stateful component : Text { property int count: 0 text: count MouseArea { anchors.fill: parent o
by jcelerier 9y ago
Here's an equivalent example for your stateful component :
Text {
property int count: 0
text: count
MouseArea {
anchors.fill: parent
onClicked: count++
}
}
if you put this in a file `C.qml` or load it as a component (http://doc.qt.io/qt-5/qml-qtqml-component.html http://doc.qt.io/qt-5/qml-qtqml-component.html), then you can reuse it in other components:
Item {
C { }
C { count: 23 } // starts at 23
}
For your functionally composed example, all qt objects have a `visible` property so you'd generally do :
MyItem {
visible: props.disabled
}
Note that unlike React, the "default" paradigm is not functional : in QML you describe directly a dataflow graph between the properties of your objects. e.g.
C { id: myCount }
Rectangle {
color: "red"
// the width will change whenever the count increase
width: Math.cos(myCount.count) / 2
}
This is because the objects with which you work in QML are exactly the ones that are going to be rendered - and at a fairly low-level: they mostly translate directly to GL / D3D primitives ; there is no need for a transformative pass like with react.
- mlsarecmg 9y agoAnd that is what i suspected and what i've seen in all examples i have browsed through so far. The enabled prop wasn't the point, it demonstrates functional composition. All of the above uses old, traditional layout inflating, dependency injection, imperative registration for re-using components, ...and common MVC. They are hard for applications that get even slightly complex. There is a major difference between that and Reacts approach.
- dahauns 9y agoSorry to go full "get off my lawn" here, but: How is this different from, say, simple GDI rendering or Swing? With both View is a function of state and rendering is done via idempotent function calls (WM_PAINT bzw. paint()/paintComponent()). This is the real traditional method. (BTW: The comparison to MVC doesn't really make sense, unless you add flux/redux/etc. to the equation.)
- abritinthebay 9y agoHe means the V in MVC and while they pushed that concept for React at the beginning to help people get what it’s for... it’s not really the same at all.
- jcelerier 9y ago.... where do you see imperative registration, layout inflating and MVC in my example ?
- mlsarecmg 9y agoIt just doesn't look comparable to the example i've posted. They were really, really simple, so if QT is the same, i would love to see it do the same. As for imperative registration, didn't you just link me to it? If they were functions, you could do: const A = () => <div>...</div> const B = () => <h1><A /></h1> Notice that the B component can refer to the A component because it's in the same scope. There's no magic and no binding/loading. A is a function that is called inside B's function body. It also isn't done by inference of an ID (which would be registration).
- jcelerier 9y ago> const A = () => <div>...</div> ; const B = () => <h1><A /></h1> Yes, an equivalent in QML would look like this if you want it in a single file: Component { id: a Text { text: "foo" } } Component { id: b Rectangle { Loader { sourceComponent: a } } } but the language really wants you to have one component per file, so : A.qml: Text { text: "foo" } B.qml Rectangle { A { } } > if QT is the same, It's not. QML is at its core not a functional language, it's a declarative & reactive language. In my experience, at least 30-40% of QML code does not need any functions. > There's no magic and no binding/loading. I'm not sure we are using the same meaning of binding. The "A" token in your example is obviously bound to the "A" variable declared before. > It also isn't done by inference of an ID (which would be registration). ids in QML are just the variable names. eg Rectangle { A { id: foo } width: 2 * foo.width }