React for JavaScript Programmers (NOT JavaScript for React Programmers)

Those of you who learned JavaScript probably learned the imperative way, instead of the functional way needed for React. Most React tutorials barely cover the different programming paradigms, and in fact, several tutorials actively treated "regular" JavaScript as something to be learned "separately" after learning React, with titles such as "Vanilla JS for React Developers" or "JavaScript for React Developers".

But what if we want to go the other way... Learn React.js after learning regular JavaScript?

First, you need to understand the differences between imperative and functional programming. See previous blog entry that discusses the differences between the two.

We will assume that you at least understand the "basics" of React, like you have to close the tags like XML in the JSX syntax, that almost everything is a part of the render() function, and so on. You know about state and props and can do the basic calls... But you're just not quite making the "mental leap" in order to think the React way, or to start an app from scratch.

This was my main problem with React... not being able to *think* in React for a long time. Like if a component keeps a state, then when you have multiple components, who keeps the state? Do they each keep some? Do they pass them like hot potatoes? When to use state vs prop? What do react hooks have to do with anything and everything? And so on.

But one thing at a time. First, a little expansion on something we discussed previously... immutability.

If you remember from our discussion in functional programming in blog post 1... There needs to be ONE central source of truth. It could be the app keeping track of everything as states, it could be relying on redux storage. The point is... be consistent... ONE single source of truth.

There are a few related concepts that I will mention here and give you a short explanation:

  • single source of truth / NO shared state
ONLY one component will keep the state. Any other components that use that specific will have to be passed the state as a state or prop. This way, NOTHING will ever "get out of sync". Timing is no longer an issue. 
  • single source of truth / NO mutable data
Data is immutable in functional programming. By not allowing it to change, you've avoided a source of bugs... the inadvertent change of data and the history of the state is preserved and can be tracked. 

Just keep in mind that Const in JavaScript does NOT create an immutable object... just a variable. They are not the same thing. You can use third-party libraries to help you implement immutable data structures, that that's beyond the scope of this article. 
  • single source of truth / NO side effects

A "true" function in functional programming does not affect ANYTHING ELSE... it just delivers the result in a return statement. If it changed any global variable or did ANYTHING other than its job, which is process one set of values into another set, it has a side effect.

Technically speaking, console.log() statement is a side effect too. But obviously, we need them for debugging purposes. So don't worry too much about it, at least not until you finished debug the thing.

And we don't really want side effects, because tracking them down is... painful. So try not to have any. Just imagine code without side effects... VERY easy to debug, right?

Now, another thing to remember... React, using a functional programming paradigm, does not really have variables. It has a "state" instead. A component can keep its own state. One of the trickiest things to learn in React is where to stick the state, and some people tend to go drastic and put everything at the app level. While it works, that basically is the React equivalent to storing everything as global variables in imperative programming. It is NOT recommended.

A state should be kept as low as it can be, but as high as it should be. I know, it doesn't really make sense yet.

Next, let's look at a real React.js example. Then hopefully it makes a bit more sense.

Comments

Post a Comment

Popular posts from this blog

Yet another take on recursion

Recursion is often one of the hardest things to "get" in programming, so when you have your "aha" moment, it's that much more amazing. Conceptually, it's not that hard to see, but how do you actually program one such?  First, realize that " recursion is a method of solving a problem where the solution depends on solutions to smaller instances of the same problem." Let us try something simple. Let's say... I want you to sum up the elements of an arbitrary array, let's call it arr. It can have any number of elements, and each element is an integer. For the purpose of this exercise, let's just say it's [1,2,3,4], but it can be any integer, and the array can be any valid size. And I want to you use recursion, not loop (no for or while or such statements).  Now, remember the definition: "solving a problem where the solution depends on the solutions to smaller instances of the same problem".  Let's call this function rsum (...
Read more

The Bare Essential Guide to Git

Image
One thing new programmers often see mentioned is "git", and a lot of jobs require you to know git or a similar version control tool. So what is it, and how do you learn it?  This is NOT a git tutorial. This is the "bare essential" guide to git, just enough to get you started. I'll guide you on how to  start a personal project repo on GitHub,  link it with your local git repo, then have you  make some changes,  commit that change,  push it to the remote repo (on GitHub),  revert that change locally.  This will NOT cover branches (and checkouts and pull requests and so on) and forks, or multiple contributors. You can read a more complete guide on that. This will, however, get you working with your own code repo.   Please keep in mind that this is JUST enough to get you started using git and GitHub. It BARELY scratches the surface of the power git offers when you have multiple contributors and their code starts to conflict, and the power of...
Read more

How to Solve a Problem 5: Horse-Racing Duals and HyperDuals

 Let us take a look at one of the competitors to HackerRank... CodeWars, and one of the puzzles on it. This one is called Horse-Racing Duals, and a harder version called HyperDuals. But one thing at a time.  You can access the problem here:  Link Read the problem very carefully. Noticed that it lists " external resources: Sorting, Lists "? Clearly, you will need to sort the solution.  I am going to do this in JavaScript, which is pretty universal.  First, they did NOT create any data structure(s) for you, so you have to create your own. I simply called mine horses . And I added a line in the readline loop to load the number into the array.  const   N  =  parseInt ( readline ()); var   horses = [] horses . length = N ; for  ( let   i  =  0 ;  i  <  N ;  i ++) {      const   pi  =  parseInt ( readline ());      horses [ i ]= pi } But...
Read more