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), 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.

And 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.

Sorry 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.)

He 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.

.... where do you see imperative registration, layout inflating and MVC in my example ?

It 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).

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