|
|
|
|
|
by aatd86
1207 days ago
|
|
Yes, it's more of a design problem of some of these libraries though. Ideally, signalling shouldn't be retrofitted on normal variables.
It assumes then that you overload variable access (assignment and reads). Then it's hard to know which variables are reactive and which ones are not. The problem stems from the overloading of semantics. A UI is mutable so it's not about mutable state being wrong but the unit of variability are not program variables but rendered props which are basically DOM Element properties.
In react, it just happens that it uses variables whose values are injected in the DOM elements via jsx but that's an issue (especially when dealing with exports, prop drilling etc) So until a plain variable and a reactive variable are made to look different everywhere in code, it will remain confusing. And even then, it's not optimal. Disclaimer: I'm currently implementing a cross-platform UI framework in Go and that's the reason why I had to think about it since traditional languages do not have reactive variables. |
|