I opted to create a helper function that takes an object that contains the word itself, as well as the count – or frequency – that each word appears. The function simply returns a string based on whether or not certain conditions are made. For example, if the word count is less than or equal to 4, it will return the string “small”. We can then use that to set the fontSize to “small”. Let’s take a look at the code:

import React from "react";
import "./word-cloud.styles.css";

const WordCloud = () => {
  const words = [
    { word: "car", count: 3 },
    { word: "electric", count: 8 },
    { word: "engine", count: 5 },
    { word: "motor", count: 11 },
    { word: "brake", count: 1 },
  ];

  const applyStyling = ({ word, count }) => {
    if (count <= 2) {
      return "x-small";
    } else if (count <= 4) {
      return "small";
    } else if (count <= 6) {
      return "medium";
    } else if (count <= 8) {
      return "large";
    } else if (count >= 9) {
      return "x-large";
    } else {
      return "medium";
    }
  };

  return (
    <div className="main-div">
      {words.map((word, index) => (
        <li key={index} className="word-list-item">
          <p style={{ fontSize: applyStyling(word) }}>{word.word}</p>
        </li>
      ))}
    </div>
  );
};

export default WordCloud;

I opted to go with in-line styling for this specific example instead of creating many classes that each set the font-size property to the proper values. If you wanted to implement a CSS class-based implementation, instead of a style attribute, you’d utilize the className attribute, and assign the returned value from the applyStyling function to that.

The two most common hooks we use when developing a React app are without a doubt useState and useEffect. But there are several other “out of the box” React provides to us, one being useRef. Let’s explore what the useRef hook is, what it does, and perhaps explore a few real world use cases for it.

What is the useRef hook/What does it do?

Simply put, the useRef hook returns a mutable (Can be modified) ref object that has a .current property that is set to the value of the argument that was just passed in. The returned object persists between component re-renders.

This is somewhat similar to the useState hook in which the initial value of the variable assigned by the hook is derived from the argument passed in to useState. One of the main differences between the two however is that the useRef hook does not cause a component re-render. This means it is an excellent choice for when you need to keep track of data but do not want to cause a potentially resource-intensive/expensive re-render. You can do this all “behind the scenes” with useRef!

Let’s see some “real world” examples of the useRef hook in action. Check out the code example below with comments explaining what’s going on for some more insight in to how we can use useRef within our React apps:

import * as React from "react";

const App = () => {
  const counter = React.useRef(0);
  const [rerender, setRerender] = React.useState(false);

  const updateCounter = () => {
    console.log(typeof counter); //sanity check - Yup - it's an object
    console.log(counter); //let's see what's in the counter variable before updating it - it's an object with a key named 'current' set to 0
    counter.current++;
    console.log(counter.current, "Current value of counter");
    //console.log will print the incremented value of counter.current to the console
  };

  return (
    <>
      <h3>Example showing no re-renders</h3>
      <p>Current value: {counter.current}</p>
      {/* here counter.current will NOT update because it does not cause a component re-render */}
      <button onClick={updateCounter}>Increment Counter</button>
      <h3>
        Example showing how to use the useRef element in conjunction with DOM
        elements
      </h3>
      <InputComponent />
      <h3>Force a re-render</h3>
      {*/ let's force a re-render to prove that behind the scenes React is still keeping track of the counter's value but just not re-rendering the BOM */}
      <button onClick={() => setRerender(!rerender)}>Force re-render</button>
    </>
  );
};

const InputComponent = () => {
  let inputElement = React.useRef(null);

  const handleClick = () => {
    inputElement.current.focus();
  };

  return (
    <>
      <input type="text" ref={inputElement} />
      <button onClick={handleClick}>Click to focus!</button>
    </>
  );
};

export default App;

Bonus points: Thanks to JavaScript hoisting we can define a function after it’s been been called and it will not throw an error. Notice how the InputComponent function (component) is defined AFTER it was used within the App function (component).

There are many different ways of implementing conditional rendering within React components (The tried and true if/else statement, a switch statement, etc.) But I recently came across and interesting (And very concise) way to conduct conditional rendering that I wanted to share as a reminder to my future self:

import React, { useState } from 'react'

const MyComponent = () => {

  let [displayText, setDisplayText] = useState(false)

  let hidden = "This is some hidden text"
  let active = "YOU'VE CLICKED THE BUTTON!"

  return(
    <Button onClick={ () => setDisplayText(true)>Press me</Button>
    {
      {
        true:hidden,
        false:active
      }[displayText]
    }
  )
}

You can implement a plain old Javascript object (POJO) in order to get the job done. Whatever you pass into the array is what determines gets displayed.

useEffect(() => {

  return () => console.log("componentWillUnMount")
},[])

Hooks have REALLY grown on me as I continue to become more and more experienced developing with React. Gone are the days of needing to create an entire class in order to gain access to state and lifecycle methods. My preferred method is writing each component I create as a function and pick and choose which hooks I want to utilize depending on the particular use case for the component. I find it to be quick and easy, as just in general easier to read.

Basically, whatever function you return from useEffect hook will be invoked whenever the component is unmounted. A typical use case for this will be to clear some kind of counter or clear an event listener after the component has been unmounted.

In computer programming, a thunk is a subroutine used to inject an additional calculation into another subroutine. Thunks are primarily used to delay a calculation until its result is needed, or to insert operations at the beginning or end of the other subroutine.

https://en.wikipedia.org/wiki/Thunk

Because Javascript runs synchronously (meaning it’ll keep executing despite not finishing the previous line of code – think: an external API call) we have to figure out a way to alter this behavior so that we can make those external API calls to allow our apps to be more versatile. If we don’t change this, our code will not work as intended, or perhaps not at all. Imagine you have a React/Redux app and you’re making an API call to get back a json object containing a list of top 10 movie and you need to map over an array within that json… but what if your array is empty? Or even worse, undefined?

We need to be able to execute code asynchronously as opposed to just synchronously.

Enter Redux Thunk – a way for you to return functions, rather than just actions within Redux.

Here’s a basic example that should make it more clear as to what’s going on:

const INCREMENT_NUMBER = 'INCREMENT_NUMBER';

function addToCount() {
  return {
    type: INCREMENT_NUMBER
  };
}

function increment() {
  return dispatch => {
    setTimeout(() => {
      dispatch(addToCount());
    }, 1000);
  };
}

Imagine calling the increment() function… You’ll see we setup a delay for 1000 milliseconds (1 second). Javascript normally wouldn’t wait around for that 1 second. Instead it would continue to attempt to execute you code and more than likely run into errors as a result. Thanks to the Thunk middleware, we can return functions instead of actions and we now can wait the 1 second.

export function fetchEmployeeInterestsNews(id) {
	return (dispatch) => {
		dispatch(getEmployeesInterestsNews());
			fetch('/v1/employees/' + id + '/interests/newsfeed')
				.then(response => response.json())
				.then(data => dispatch(getEmployeesInterestsNewsSuccess(data)))
				.catch(err => dispatch(fetchEmployeeInterestsNewsFailure(err)))
	}
}

Above is a typical thunk that’s responsible for making an API call, then taking the returned json and dispatching it to the reducer in order to update the global store. If we attempted this without the thunk middleware, the API call wouldn’t finish in time before we attempted to pass it in as an argument to getEmployeesInterestsNewsSuccess().

So how do we get a child to re-render when it’s passed in new props?

Enter the key attribute. React uses that to determine whether or not a re-render should occur. In its most pure form this is what we’re looking to implement:

<div key={your_updated_id>Some content...</div>

And for a more verbose example that really spells out how this is intended to be implemented. Your parent component:

import React, {Component} from 'react'
import ChildComponent from 'ChildComponent'

class MyComponent extends React.Component {
  state = {
    weather: "sunny",
    station_id: 1234
  }

  render(){
    return(
      <ChildComponent current_weather={this.state.weather} station_id={this.state.station_id} />
    )
  }
}

Your child component, which we imported in the above parent component:

import React from 'react'

const ChildComponent = (props) => {
  return(
    <div key={props.station_id}>
      The current weather outside is {props.current_weather}
    </div>
  )
}

export default ChildComponent

In the above child component, we’ve returned a <div> with a key attribute set to {props.station_id}. This way whenever the state of the parent component updates, it then pushes the updated state into the child component via its props. The child component then in turn re-renders because it received a new key.

I’d consider this use case rather contrived in the sense that it’s more or less an anti-pattern and really goes against the essence of React. Though I can see when developing a smaller app there might be a viable argument to be made when you can implement something like the above for a one-off scenario as opposed to implementing something more complex like Redux to manage the global state.

(Scroll down for the tl;dr version!)

ES6 provides the ability to import and export modules, and more specifically, within React this means that you can easily create a stateless component and then later import it elsewhere and use its functionality there. Let’s get right to it…

Named exports

You can have multiple named exports from within a file. The only 2 catches with named exports are that when it comes time to import them, you have to use curly braces as well as use the same name when importing them. Here’s an example:

export const function namedExport() {
	console.log("This is a named export!")
}

export const function yetAnotherNamedExport() {
	console.log("This is a named export!")
}

And now when it comes time to import the above named functions, it would look like the following (Note the usage of the same name, as well as curly braces):

import { namedExport } from './namedExports'
import { yetAnotherNamedExport } from './namedExports'

Default exports

One of the main differences between named vs. default exports is that you can only have ONE default export per file whereas we saw with named exports you can have virtually as many as you’d like. Another difference is that when it’s time to import a default export, you can rename it… and you don’t have to use curly braces:

const function defaultExport() {
	console.log("This is a default export!")
}

export default defaultExport

And now when it’s time to import the above default export:

import defaultExport from './defaultExports'

OR you can do this:

import literallyAnyNameYouWant from './defaultExports'

And when thinking about the logic behind this, the above example starts to make sense: When you have a default export, there can literally only be ONE export, so when it comes time to import it, it doesn’t matter what name you import it as because no matter what, it can only be ONE object that was exported to then import.

tl;dr version – you can have multiple named exports from a file but when it comes time to import them their name matters, as well as curly braces. When talking about default exports, there can only be one default export per file, and their name isn’t important when importing them, nor do you have to use curly braces.