Spot on. And is there is anything in computer science that lends itself more to objects than UIs? Has anyone ever looked at a piece of a UI and though, "Nice function!"? Nope.
Bingo! That's a big reason why React originally appealed to me - because, when crafting a UI, you have all these... "things" on the screen. Those things have actions (events) that can be triggered based on user input. Those things have their own bits of logic (functions) that should happen at specified times, or in response to specified input. Those things have their own internal memory (state). And they have their own rules about how-and-where to generate display (the render()).
Well not exactly.... They're called components, not objects.
React has always been based on functional programming concepts, even before hooks, e.g. pure functions, composability, immutability, Redux, etc. Hooks are just the next logical step to making the library more FP-oriented.
I personally love hooks as I find it much faster and easier to write components than with classes (there's also a slight performance boost). Maybe you'd prefer a more OOP-oriented frontend framework like Angular?
I'm talking about paradigms here. No one with even an elementary understanding of JS thinks for a moment that JS_Objects === OO_Objects.
Find programmers who aren't long-time JS/React heads. Then tell them, "I have this thing. It can maintain its own internal memory. It has a view, through which display output is directed. It can have any number of pre-defined actions/events, based on user input, or based on conditions that are passed into it. It has a defined life-cycle. It probably has ancestors. And it can have descendants. It can exist as a single entity, or it can be cloned. The clones can be perfect copies or they can behave differently, based on the initial parameters. So... with all of those parameters in mind, what would you call this thing??"
Then sit back and count the number of people who say, "I'd call that thing a function"...
We all understand that this stuff ultimately gets transpiled down to functions (whether we start with a function or a "class"). But I (and the original commenter above) are talking about the paradigm that best fits a UI "object". (Or "component". Or "element". Or whatever particular name we want to call it.) The paradigm I'm referring to is the exact same paradigm that was directly fostered by the React framework - for years.
As for Angular, I've done a lot of Angular. I can work in it just fine - but I prefer not to. I don't particularly care for it.
In terms of what's "easier" to reason about in React/JS, I personally find functional components easier to understand than class components. E.g. the other day I had to go through a couple of React libraries using classes. It took me a while to adjust to understanding what "this" referred to. Maybe I'm strange for legitimately disliking class components 😆
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.
Spot on. And is there is anything in computer science that lends itself more to objects than UIs? Has anyone ever looked at a piece of a UI and though, "Nice function!"? Nope.
Bingo! That's a big reason why React originally appealed to me - because, when crafting a UI, you have all these... "things" on the screen. Those things have actions (events) that can be triggered based on user input. Those things have their own bits of logic (functions) that should happen at specified times, or in response to specified input. Those things have their own internal memory (state). And they have their own rules about how-and-where to generate display (the
render()).Those things... are called objects.
Well not exactly.... They're called components, not objects.
React has always been based on functional programming concepts, even before hooks, e.g. pure functions, composability, immutability, Redux, etc. Hooks are just the next logical step to making the library more FP-oriented.
I personally love hooks as I find it much faster and easier to write components than with classes (there's also a slight performance boost). Maybe you'd prefer a more OOP-oriented frontend framework like Angular?
I'm talking about paradigms here. No one with even an elementary understanding of JS thinks for a moment that
JS_Objects === OO_Objects.Find programmers who aren't long-time JS/React heads. Then tell them, "I have this thing. It can maintain its own internal memory. It has a view, through which display output is directed. It can have any number of pre-defined actions/events, based on user input, or based on conditions that are passed into it. It has a defined life-cycle. It probably has ancestors. And it can have descendants. It can exist as a single entity, or it can be cloned. The clones can be perfect copies or they can behave differently, based on the initial parameters. So... with all of those parameters in mind, what would you call this thing??"
Then sit back and count the number of people who say, "I'd call that thing a function"...
We all understand that this stuff ultimately gets transpiled down to functions (whether we start with a function or a "class"). But I (and the original commenter above) are talking about the paradigm that best fits a UI "object". (Or "component". Or "element". Or whatever particular name we want to call it.) The paradigm I'm referring to is the exact same paradigm that was directly fostered by the React framework - for years.
As for Angular, I've done a lot of Angular. I can work in it just fine - but I prefer not to. I don't particularly care for it.
Hmmm fair enough. Thanks for the explanation.
In terms of what's "easier" to reason about in React/JS, I personally find functional components easier to understand than class components. E.g. the other day I had to go through a couple of React libraries using classes. It took me a while to adjust to understanding what "this" referred to. Maybe I'm strange for legitimately disliking class components 😆