IDOM – It's React, but in Python
rmorshea.github.io
rmorshea.github.io
Take a look at ‘toggle_1()’ function, which is called by a lambda, and takes no arguments. On top of that, it refers to ‘toggle_state()’ which also doesn’t take any arguments. That function calls ‘set_state()’ and is fed a lambda which toggles a Boolean input and somehow all that switches the value of ‘input_1‘.
That boggles my Python mind.
Wouldn’t everything be a lot less magical if it was oop? Then you’d go ‘input_1.toggle_state’ and it is pretty clear to everyone which variable is being toggled.
I know this library is mirroring another framework in another language, but this is the first time I’ve read a piece of code and thought “maybe oop is the better option”.
My point is not to try and argue that this is a poor framework. I have no right to such an opinion and I get that this code generates a JavaScript/html application which will eventually get executed and therefore everything happens one extra step detached from the Python code.
> Wouldn’t everything be a lot less magical if it was oop? Then you’d go ‘input_1.toggle_state’ and it is pretty clear to everyone which variable is being toggled.
I think that's mostly mirroring the syntax from React (where things used to be classes, although functional React is getting more popular).
The main advantage of this singleton based approach is that the dataflow is unidirectional. It doesn't show up in their simple examples, but in more complicated ones, those variables get passed to child components. If you do OOP, you're passing a mutable object to the child component. With this approach, they get a read-only copy of the variable. You can overwrite the value, but it won't propagate up to the parents, so the component can only screw up itself.
It's different, but I don't think particularly magical. The magic is basically "for each component, see what singletons were passed to children. If any of the children's singletons changed, re-render the affected children". I'm not a React expert by any means, but once I got used to that functional paradigm, it doesn't bother me.
Are you sure? it seems every events goes to the server, which is a huge cost compared to fully client side event handling.
At first glance, it seems there is a big problem: _every_ event means a client<>server round trip! I tried this with their basic examples, when I cut the server the client becomes static. It seems to me a lot of the logic could be kept client side. Am I missing anything here?
That is why script has a language attribute, but we ended up being stuck with JavaScript.