Tag Archives: React.js

Coding

When do you need useMemo (and when don’t you)

Leave a comment

It’s confusing when we should use useMemo and when we shouldn’t.

useMemo isn’t free $

useMemo comes with a small cost. So we should understand when it’s a benefit, and when it doesn’t provide any value.

  • Small usage in RAM to memoize & remember the resulting value
  • It costs a small cpu cycle to loop over & compare the dependency array & run internal fn of useMemo

So we should be smart when we use it.

useMemo isn’t always needed

useMemo isn’t needed in certain cases. For example, casting something to Boolean, or doing simple math isn’t an expensive operation and returns a primitive like “boolean” or “number”. These value will always be the same every time they are re-render run 

true === true and 5 === 5.

Conversely, an array or object don’t have equality,

 [] !== [] and {} !== {} and new Date !== new Date.

Two tests of if you need useMemo

  1. Is the calculation to get the value is complex (looping, calculating, initializing a class)?
    • Or is it cheap (comparisons of numbers, boolean, casting types, simple math)
  2. Is the returning complex value (object, array, fn, or class)?
    • Or is it a primitive value that is simple to compare (number, boolean, string, null, undefined)

Examples

  const date = useMemo(() => Date.parse(isoDateString), [isoDateString]);

We should use useMemo

  1. 🛑 Initializes the Date class
  2. 🛑 Returns a Date Object, which is not a primitive
  const isAdmin = useMemo(() => runExpensiveSearch(accounts), [accounts]

We should use useMemo

  1. 🛑 Runs an expensive function to get the value
  2. ✅ Returns a primitive value

In cases where it’s neither an expensive calculation nor a complex object, useMemo isn’t necessary.

-  const isArchived = useMemo(() => Boolean(process?.deletedAt), [process?.deletedAt]);
+  const isArchived = Boolean(process?.deletedAt);

We don’t need useMemo

  1. ✅ Casts to a boolean which is a cheap operation
  2. ✅ Returns a primitive value
-  const numberOfAccounts = useMemo(() => accounts.length, [accounts]);
+  const numberOfAccounts = accounts.length;

We don’t need useMemo

  1. ✅ Getting the length property is cheap
  2. ✅ Returns a primitive value

Just remember the two tests

  • Is it complex / expensive function?
  • Is the value not a primitive?

What about useCallback?!

I’m so glad you asked! The principles are similar. In general, all callback functions should be memoized via useCallback. Functions are considered a non-primitive value thus never have equality unless we memoize them via useCallback.

(Cover Photo: Feldstraße Bunker, Hamburg, Germany – Jonathan Stassen / JStassen Photography)

Coding

setup VSCode with REACT_EDITOR (or any editor)

Leave a comment

When an error occurs with an app Created with Create React App the error screen is super helpful.

You can click on this error in the browser to jump directly to the line of code inside your editor! But how do you setup VSCode with REACT_EDITOR?

Console error:

Could not open SomeFile.js in the editor.
To set up the editor integration, add something like REACT_EDITOR=atom to the .env.local file in your project folder and restart the development server. Learn more: https://goo.gl/MMTaZt

Setup your editor to be open from terminal

Google “How to open [your editor] from terminal” to find instructions for your editor.

For VSCode, open the command pallet ( Command Key + P ) and type > shell to install “code” into your PATH environment variables.

You should now be able to open terminal and type code to open VSCode. Pretty nifty!

Setup your React Project to know which editor to open

Create a new file (or edit the existing) .env.local file.

setup VSCode with REACT_EDITOR this will be REACT_EDITOR=code and for other editors set it to the command you found to open your editor from the terminal.

Credit to this StackOverflow Answer.

Related post: Favorite Sublime 3 Packages

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

An Introduction to Redux

Leave a comment

Redux’s ideology is a unidirectional data flow. This pattern reduces long term complexity, encourages re-usability, and generally discourages spaghetti code. 🍝

Video Series: https://egghead.io/courses/getting-started-with-redux

Terms & Descriptions

The core of everything is the Store, Action, and Dispatch. In its simplest form it’s all you technically need. From there Thunks & Sagas enhance the the tooling around the Dispatching of Actions.

Store

  • A singleton object/state for the app.

Action

Dispatch

  • You “Dispatch an Action to the Store” to update the store.
  • Dispatch sends the Action payload through the Reducer.

Reducer

  • Receives the Action payload from Dispatch and modifies the Store.
  • Reducers contain no business logic, they only modify the Store described in the Action

Thunk

  • Considered the old way, but sometimes still has great applications in simple cases.
  • You can “Dispatch a Thunk to either access state or do ajax work”
  • Within a thunk you can call additional Dispatch
  • Within a thunk you can access the state of the store.
    • Good for conditionally firing subsequent api calls, or dispatches.
    • Good for pulling together data from the store into a dispatch.
  • Good for very simple ajax calls, you can Dispatch Actions from ajax response
  • Best way to understand Thunks in my opinion is to look at the 10 lines of source code:

Saga

  • Regarded as a better replacement for Thunks
  • Can require more effort than Thunks to understand, and build.
  • Within a Saga you can access the state of the store.
    • Great for conditionally firing subsequent api calls, or dispatches.
    • Great for pulling together data from the store into a dispatch.
  • Sagas can subscribe to listen and fire when some Actions have been Dispatched
  • Great for moving side effects to be self contained instead of sprinkled throughout the app
  • Provides great debounce / cancel / takelatest logic nearly for free.
  • Can do long running / scheduled Actions
  • https://redux-saga.js.org/docs/introduction/BeginnerTutorial.html

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

React “stateProps PrecalculationError” and TypeError ‘state’ of undefined

Leave a comment

Debugging a React component can be a pain.

There are many causes for “statePropsPrecalculationError”, for debugging see my post on Debugging React statePropsPrecalculationError post.

When you specifically have ” ‘state’ of undefined” the fix is simple:

Recently I ran into “statePropsPrecalculationError” alongside with the the console warning TypeError: Cannot read property ‘state’ of undefined(…)`.

This is super easy to fix, but not immediately obvious. Whenever you use `this.setState()` inside your component, you must define your initial state!

Just add a `getInitialState()` definition!


const MyComponent = React.createClass({
getInitialState() {
return {
isOpen: false
};
},
toggleOpen() {
this.setState({isOpen: !this.state.isOpen});
},
render() {
return (

Hello World!

);
}
});

Coding

Code: Data structure

Leave a comment

In my understanding there are different types of data. Each is unique in purpose, mutability, and scope. Clearly identifying the role of an attribute and grouping it with related ones creates a cleaner interface to work with.

Raw Attributes

The raw data that is persisted to the server.

This data should be treated as if immutable, unless planning to persist a change of one of the values to the database. This is the once source of ‘truth’ that is trustworthy. If it is reformatted, or changed it looses its trustworthiness.

user: {
 firstName: 'Phil',
 lastName: 'McCool',
 username: 'pmccool'
}

Computed Values

Take in Raw Data, and reformat it for later use.

More often than not these are a convince to remove the need to repeat logic throughout the app.

If there is an urge to create a value here to describe the model’s content ‘isAdmin’, ‘fullName’, there is a good chance these ought to be part of the data schema to start with.

They can come at a cost of being computed but not always needed everywhere throughout the app. Alternately getter functions could be used to allow a more ‘on-demand’ approach (add result caching and get the both of both worlds).

computed: {
 fullName: 'Phil McCool',
 shortName: 'Phil M.',
 numberVowels: 3
}

State

Describing the state status, of either the data or of the component/view.

State data describes progress or what things are doing currently – [changing, updating, modified]. While these are similar to configuration items, they mutable are more closely tied to the model data describing what is happening to it. If their were multiple components/views that display the same model, they may all want to know the current state of the data. It’s meta data to the data.

These values should update frequently.

state: {
 isLoading: false,
 isModified: true,
 page: 4
}

Configuration

How something should be displayed or behave.

These ought be on the component/view that is rendering the item. It describes the preferences of how something should behave or be displayed. Think of them as options, ways to deviate from the norm, an API for this component/view.

A component/view should have a set of defaults for these values to fall back upon.

Config attributes can make it tempting to overload abstraction. Draw a line of making a new component/view when the core functionality has config options that cause different logic paths.

config: {
 size: 'large',
 template: 'card',
 color: 'blue'
}

 

Take Aways

It can be very tempting to merge or stuff configuration and state data right into the model data. It’s convenient, but lazy. It taints the raw data. If put an ‘isLoading’: true value into our data model then persist it to the server, we ought to feel like we did something wrong.

Ideally we would be able to group data in our actual data structures, but at minimum, we can always just keep in mind the role of an attribute and group mentally.

TL;DR

  • Not all data is alike.
  • Don’t mutate / override original data
  • Computed, State, and Config data shouldn’t be mixed in with raw data.