Qt

[jamesdbrock]

Like many other people, I want to write good-looking apps with React-style (Model-View-Update, The Elm Architecture) in 100% Python.

Congratulations on implementing Hooks in Python; I believe you’re the first person to do that.

https://maartenbreddels.medium.com/advance-your-ipywidget-app-development-with-reacton-6734a5607d69

Once a common library for rendering/reconciliation exists, the same procedure can be repeated for Qt

It sure would be nice if we could write PySide6 apps with Reacton. Here’s an issue for talking about that.

[maartenbreddels]

Hi @jamesdbrock,

Good to hear you like Reacton, and declerative UI's. I have explored Qt support a while ago, and I actually managed to get that working.
Would you be interested in that?
I could open a draft PR, so you can see what I looks like.
I see https://github.com/pyedifice/pyedifice uses the classes based approach, while Reacton uses the function style, any strong reasons for 1 vs the other?

Regards,

Maarten

[jamesdbrock]

I have explored Qt support a while ago, and I actually managed to get that working. Would you be interested in that?

Yes please! But is it realistic for Reacton to support both iPyWidgets and PySide6? Are you going to end up limiting Reacton to the common feature set of each? I've surveyed all these half-finished Python declarative GUI projects and it seems like a common theme is trying to abstract over multiple backends.

I see https://github.com/pyedifice/pyedifice uses the classes based approach, while Reacton uses the function style, any strong reasons for 1 vs the other?

Historical reasons. @fding wrote Edifice in 2021, when functional-style React Hooks was still new. I think he used the class-based approach because it was established and well-understood. Edifice also has a make_component function decorator, but without Hooks it’s not very useful.

I, personally, strongly prefer pure functional programming for everything.

[maartenbreddels]

Dear James,

Checkout out #21 for the POC.
As you can see there is nothing that needs to be changed in core.py (well, that first commit is unrelated to this PR, it might be the fix for #14). So we didn't really need to abstract over multiple backends, it kinda came out naturally.

I currently don't have much interest in supporting Qt myself, nor do we (Widgetti) have the bandwidth right now.
We could be interested in a Reacton-qt build on top of Reacton since that would give extra eyes on it. I would say Reacton is pretty solid right now, and the test coverage is quite extensive.
There is a little bit of technical dept, and possible could use a performance review, which would benetit both the widget and the qt backend.
If these are things you would be interested in, I could see a fruitful collabaration.

I would be less interested in adding many more features in Reacton, or doing unneeded refactors that could potentially change behaviour. Since Reacton is the foundation of Solara, we are conservative about making changes.

Let me know what you think.

Regards,

Maarten