A really mental, mental-map for react philosophy (Crash course edition)

Leaving this space to act as a subtext for when they pause for dramatic effect in movies — wink wink

Alrighty, let’s get down to business. Context first, when I started learning React, and bear with me as I’m trying to rewind four years of memory all the way to class based components: it was damn hard. For me, as a newbie, seeing chunks for HTML syntax and JavaScript lines together almost merged together was an abomination, an alien — not the cliched green one but worse, imagine purple.

So for those who want a one-shot plot; this is my interpretation of why react exists and some if not all of it’s principles that justify the existence. Also, I deflect my own negative thoughts with sarcasm and jokes so read on if you think you’d be able to handle that. (kidding.. not.)

So obviously the first words that came out of my head was *censored*. And then I started googling — the only thing you can do when nothing else works — as to what exactly was the reason this library / framework (and god help me when they decide CONCLUSIVELY what it is) came into existence. The first keywords that popped multiple times back then was “reusability”, “component structure” and ice cream.. cause I was way too hungry at the end of all the research.

Re Usability

Obviously added the space in between on purpose to signify the exact same thing. The one principle that guided creation of React was reusability. Now I’ve got minimal exposure with MVC frameworks but based on what I know the extent to which, a component or module or whatever is the basic unit of whatever framework you use, is reusable is limited.

On the other hand, sharma-ji ke beta over here(urban dict for those who don’t get this) was made with this specific goal in mind. I bow my head to facebook engineers just this once. All jokes aside, separated from any constricting business logic from it, a react component can literally be used with just its corresponding props any number of times and anywhere, theoretically and almost practically.

Data Updation — in react lingo, state and prop updation

Come on, tell me you don’t think this is worth it. Amongst all the complex ways to update and manage data in a web component or class in most, if not all frameworks, react state updation is super easy and super teachable to others who haven’t got the exposure yet.
Pair this with the virtual DOM and you’ve got an engine with 1000 horses in a world still running on actual horses (may have exaggerated this one a lil bit), but you get the point.

JSX

Okay, who’s used a template engine before in a classic MVC architecture? You know somewhere in the back of your head in that tiny dark corner you’re realising while using react that you can never, ever go back to template HTML.
JSX was and still is one of the best things that react ever did. I admit, initially I kinda dissed on the whole thing but eventually seeing the DOM element markup and functionality together does give you some sort of weird satisfaction.
You definitely can do without JSX as well, as I’ve seen others do it, but if you’re telling me you’re gonna do
React.createElement('div', null, `Hello ${this.props.someValue}`);
every, single time.. boy you’ve got more patience and gumption than me.

Say, I think I’ve been babbling on and on so much about React and maybe I’ll stop here and save the rest for later. Like always, this article is not exhaustive, accurate to the power of accurate or the best way to understand it, but just my two cents that can add to another 98 to make a dollar.

Cowabunga!
- T.