Seems to me like there's a trade-off that's been made by the broader JS community, and that trade-off is causing some of your (understandable) angst with regard to props. The trade-off I'm talking about is in regard to two-way data binding.
With two-way data-binding, you bypass a lot of this confusion because there's no distinction between "initial value" and "current value". There's just one value. Sure, you set it to some "initial" value, but once that value is updated - from anywhere - the initial value is destroyed.
I used to do some Flex development and, once I got my head around it, I really kinda loved it. And when KnockoutJS came out, I thought that's where we were heading in the JS world. But something funny happened on the way to the forum...
"Two-way data-binding" seems to have become a dirty word in the JS community. Although I understand some of their gripes, I definitely don't see two-way data-binding as a bad thing, and I kinda wish people hadn't decided that it's voodoo, but, whatever...
The point is that, when the "next wave" of frameworks came out, they seemed to be hellbent on not implementing two-way data-binding. But they still need to have some way of updating values (state) if they're gonna be of any use. And thus... you get this dichotomy between how something was initially represented and how it's currently represented.
Thanks much for taking the time to read and comment. I agree with your observations. The distinction I am looking for is between props that are relevant for rendering and props that aren't. Props that are allowed to change and props that don't (sometimes it is okay to update the initialValue on the fly but it might require work as loading new assets etc).
The 'props' interface treats all of them as subject to change at any time and doesn't allow you to express anything else. I have seen components in which maybe 10% of the props were subject to change after initialisation (the rest was configuration, static callbacks and such). Trying to understand and debug those can be a pain.
Because I have a lot of experience with languages like Java in which you have proper constructors, methods (beyond just 'render') and so on, I sorely miss this richness of functionality here and feel forced to dumb down my designs 😔
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Seems to me like there's a trade-off that's been made by the broader JS community, and that trade-off is causing some of your (understandable) angst with regard to props. The trade-off I'm talking about is in regard to two-way data binding.
With two-way data-binding, you bypass a lot of this confusion because there's no distinction between "initial value" and "current value". There's just one value. Sure, you set it to some "initial" value, but once that value is updated - from anywhere - the initial value is destroyed.
I used to do some Flex development and, once I got my head around it, I really kinda loved it. And when KnockoutJS came out, I thought that's where we were heading in the JS world. But something funny happened on the way to the forum...
"Two-way data-binding" seems to have become a dirty word in the JS community. Although I understand some of their gripes, I definitely don't see two-way data-binding as a bad thing, and I kinda wish people hadn't decided that it's voodoo, but, whatever...
The point is that, when the "next wave" of frameworks came out, they seemed to be hellbent on not implementing two-way data-binding. But they still need to have some way of updating values (state) if they're gonna be of any use. And thus... you get this dichotomy between how something was initially represented and how it's currently represented.
Thanks much for taking the time to read and comment. I agree with your observations. The distinction I am looking for is between props that are relevant for rendering and props that aren't. Props that are allowed to change and props that don't (sometimes it is okay to update the initialValue on the fly but it might require work as loading new assets etc).
The 'props' interface treats all of them as subject to change at any time and doesn't allow you to express anything else. I have seen components in which maybe 10% of the props were subject to change after initialisation (the rest was configuration, static callbacks and such). Trying to understand and debug those can be a pain.
Because I have a lot of experience with languages like Java in which you have proper constructors, methods (beyond just 'render') and so on, I sorely miss this richness of functionality here and feel forced to dumb down my designs 😔