One that I have been thinking about lately is the `QEnumComboBox` [1]. It takes the concept of a combobox (i.e. drop down list/`select`) and combines it with a python `Enum` to produce a very commonly desired functionality: allowing the user to select a value and then converting it to an `Enum`. This to me seems easily reusable because it encapsulates that functionality in a clean way. I can't think of a corresponding example in a JavaScript framework, but I would love to see one. I think this might be more difficult because one can't really pass types at runtime.
I think instead of "truly reusable" I should have said something like "requires minimal configuration." I think Python's reflection capabilities allow one to supply less boilerplate when writing PyQt apps. This is just a subjective impression that I have, and unfortunately I am having trouble elaborating on this in a way that I think would be effective. That is why I asked the author what they thought, since I am wondering if anyone else has had this impression. However, I will think about this more, and I might provide more examples if I can think of them.
Neither JS nor Python really have types at runtime or any other time, but you can approximate them with Objects and/or Classes (of course, I repeat myself ;) ). With some TS magic you can even get the `setEnumClass` call to be well typed, though if I were building it from scratch I'd make the EnumClass prop immutable, too many weird corner cases otherwise.
I've never worked extensively with Qt myself, but when helping out a friend making Maya plugins in Qt we'd occasionally hit SEGFAULTS from writing seemingly mundane Python that'd crash all of Maya. That was enough to turn me off of it, but looking through the docs you linked there are some compelling components. It's nice to have a component library separated from a specific framework (in the React/VUE/etc. sense)... I don't know of any in JS. Every framework seems to think their (incompatibile with everything else) approach to reactivity is the hold grail, and being modular across it would be impossible.
Though reconsidering, I suppose Qt is sorta the same... it's just another framework and their "signals" aren't Python. Ah well.
Diving deeper, signals are weird... they aren't even really part of the underlying C++! Some sort of strange new modifier Qt invented at the level of `private`/`public`/`protected` and such. https://doc.qt.io/qt-6/signalsandslots.html
I am not aware of Qt being the problem here, having built large Qt apps that run stable (coding in C++ only). I guess it is rather an issue with the Python to Qt interface.
