5 ms·

This seems like a misunderstanding of what React is. JSX is not a template. It is a DSL or superset with direct access to the presentational layer. It gets "tra

• westoncb 8y ago
  There is no reason you couldn't use the example QML above in place of JSX and still receive the same benefits. It would still be `View = fn(state)`; it's just a different syntax for specifying `fn`.
  • mlsarecmg 8y ago
    From what i've seen this is layout inflating, you have a template and you fill it imperatively. Which would be one of the oldest paradigms we have. Maybe i am getting this completely wrong, forgive me in that case, but in all examples i've seen so far it's like that. Could you please paste an example of a real, functional QT component? For instance a component that is re-used in another component, const A = ({ text }) => <div>{text}</div> const B = () => <A text="hello" /> <B /> // -> <div>hello</div> as well as functional composition (higher-order-components): const canBeDisabled = Component => props => props.disabled ? null : <Component {...props} /> const ComposedB = canBeDisabled(B) <ComposedB /> // -> <div>hello</div> <ComposedB disabled /> // -> null an example for statefull components would also be nice: class C extends Component { state = { count: 0 } up = () => this.setState(state => ({ count: state.count + 1 }) render() { return <div onClick={this.up}>{this.state.count}</div> } } <C /> // -> <div>0</div>, clicks count up reactively
    • jcelerier 8y 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 8y ago
        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.
        • dahauns 8y ago
          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.)
          • 8y ago