DEV Community: Matti Salokangas

An Introduction to React

Matti Salokangas — Fri, 12 Feb 2021 18:23:00 +0000

Starting Off

If you aren't familiar with Javascript or want to make sure to fill in the gaps, read through this javascript primer from MDN: Javascript Basics

This content is inspired by the React docs.

What is React?

At the highest level, React is a Javascript library that is the "View" in the MVC (model/view/controller) pattern.

React components allow you to represent your application data in a tree of components.

Your entire app could be a giant tree of components or you could have mini-component trees in various parts of your existing application.

Writing Components

Each component in your apps tree is written using a special extension to the javascript language called JSX. JSX stands for Javascript and XML and once you get the hang of it, it is really nice! The syntax can turn off some folks initially, but in time you get used to it. Dive more into JSX in the docs here.

What does it look like?

<SomeJSXElement>Hello World</SomeJSXElement>

In order to make this work, Facebook took advantage of a tool called babel and created a plugin that transforms JSX into regular old javascript that a browser can understand.

So, you write this:

<SomeJSXElement>Hello World</SomeJSXElement>

And babel transforms it into this:

React.createElement(SomeJSXElement, null, "Hello World");

There is nothing stopping you from writing all your React using React.createElement(...) however it will be painful and is generally not recommended.

Props vs State

Components don't do much without having some sort of properties set or some local state.

Here are some general rules when it comes to props vs state:

Props are passed down the component tree.
State is localized to the component it is used in, but can also be passed down to child components as a prop.
Global state is achieved through Context, which we will discuss later.

Example

Props

In the example below, "name" is considered a prop of the "MyComponent" component.

It is passed to the component like so: <MyComponent name="Sarah" />

If you want to update a prop, you'd typically also pass a function to your component that would provide the new value for the prop. For example, <MyComponent name="Jim" updateName={updateName} />

State

"favoriteColor" is considered state and is updated by calling the "setFavoriteColor" function.

You might update it after clicking a button or typing into a textbox.

const MyComponent = ({ name }) => {
  // This is using array destructing
  // The default value for "favoriteColor" will be "Green"
  const [favoriteColor, setFavoriteColor] = useState("Green");

  return (
    <div>
        Hi {name}!  Your favorite color is {favoriteColor}.
    </div>
  )
}

MyComponent.defaultProps = {
  name: "Foo"
}

MyComponent.propTypes = {
  name: string
}

Designing Components

When beginning to design a component or an entire page in React it is helpful to approach things using this technique:

Whiteboard or write up static HTML first
Decide where it makes sense to extract your components given the UI
Consider what props or state each component will need:
- Pay attention to…
- Shared props
  - What props are needed across multiple components?
    - Does it make sense to keep track of these props in the parent component or is something that should be in context? Usually parent component is the best place to start until you need it else where.
- Local state
  - What can be localized to the component?
Create your components
- Make sure to add your propTypes and defaultProps

Function vs Class Components

There are generally two approaches to writing components; function components or class components. Both are valid ways to express React components.

Class components are a great way to learn, however there is a movement towards using Function components and hooks, so that should be the focus. There are exceptions, such as ErrorBoundary components that must be class based, but otherwise, it is recommended to use function components.

Examples

Function Components

There are a couple ways to express function components. All of these are the same, just different ways of doing things.

Using a fat-arrow function:

const MyComponent = ({name}) => {
  return (
    <div>Hello, {name}</div>
  )
}

This can actually be even cleaner, which is sometimes why the fat-arrow function is preferred:

const MyComponent = ({name}) => <div>Hello, {name}</div>

Using a named function:

function MyComponent({name}) {
  return (
    <div>Hello, {name}</div>
  )
}

Class Components

class MyComponent extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

Lifting State Up

No matter how much design you do up front, one will inevitably run into a scenario where more than one component needs access to some local state.

In this case, you will want to lift your state up the component hierarchy so you can pass the state back down as "props".

The React docs explain this quite well here

Global State

There are times when you will need to access something deep down in the component tree and also at the top. Rather than passing those props down through the component tree (called prop drilling), you can use "context".

To use context...

You must first create it.
Then you provide the context to your components by wrapping them in a "Provider"
You then gain access to context by using the useContext hook

Read more here

Example

// Create context
const MyContext = React.createContext();

// Provide it to your app using a Provider
const App = () => {
  const [theme, updateTheme] = useState();

  return (
    <MyContext.Provider value={{ theme, updateTheme }}>
      <Container>
        <Header />
        <Content />
        <Footer />
      </Container>
    </MyContext.Provider>
  )
}

// Then, let's say down in your <Content /> component you want
// to access the theme:

const Content = () => {
  const { theme } = useContext(MyContext);

  return (
     <div>
       You are using the {theme} theme!
     </div>
  )
}

Hooks

A fairly recent update to React was the introduction of hooks. These are simply special functions that start with "use", abide by some rules and allow you to do things in function components that were previously achieved via higher order components or class components.

Let's take a look at a few common hooks. If you are eager to dive in, check out the docs here

useState

Any time you want to keep track of something that you will be changing over time and want to tell React to re-render when it changes, you'll use the useState hook.

Read more here

Example

const [name, setName] = useState("Jim")

useEffect

Any time there is some sort of side effect, you'll want to use a useEffect hook.

Read more here

Example

// This will run every render
useEffect(() => {
  console.log("I ran!")
})

// This will run every time the "loading" prop changes
useEffect(() => {
  console.log(loading)
}, [loading])

// This will run every time the "loading" prop changes
// and will also run a function returned from the useEffect
// hook when this component is removed from the DOM
useEffect(() => {
  console.log(loading)

  return () => {
    console.log("This is where you can run clean up code!")
  }
}, [loading])

useLayoutEffect

Works the same as useEffect, but you'll want to use this if you are doing any sort of measuring of style-related things with the DOM. Essentially, if you find yourself accessing HTML elements properties like height or width, you will want to use the useLayoutEffect hook.

Read more here

useRef

Allows you to keep track of something for the lifetime of your component. This is often used to access the native DOM element associated to some JSX element.

Read more here

Example

const MyComponent = () => {
  const inputRef = useRef(null);

  const doIt = () => {
    // Output the background color for the div
    console.log(inputRef.current.style.backgroundColor)
  }

  return (<>
    <div ref={inputRef} style={{backgroundColor: "#123"}}>Hello World</div>
    <button onClick={doIt}>Click Me</button>
  </>)
}

Rules of Hooks

There only a couple rules one must abide by in order for Hooks to work in the React world.

1) Hooks must be first
2) Hooks can only be using in function components or other hooks

Read more here

Render and Portals

There are a couple ways to render React components. The most common way in the web-world is to call react-dom's render method. The other way is by using a portal, which allows you to basically inject a React component anywhere in your site.

Sometimes you aren't working with a 100% React application. For example, if you are working on a WordPress site where you want to use React for a dropdown menu at the top of the page and a specialized store locator tool. This is where you'd want to lean on React's portal.

Read more here

Mapping Data and Keys

Often times you will be displaying a list of things. If you find yourself using map, make sure to provide each item with a key.

Read more here

Example

data.map(item => <li key={item.id}>{item.label}</li>)

Odd Html Attributes

One oddity of React is that they had to slightly adjust some HTML attributes in order to have it jive with the ones already established for native HTML elements.

Some examples:

Rather than<div class=..., you'd use <div className=...
Rather than<button onclick=..., you'd use <button onClick=...
Rather than<label for=..., you'd use <label htmlFor=...

Be on the look out for these! There are only so many and if you do happen to make a mistake, React is pretty good about yelling at you in the console. So, be sure to pay attention to those console warnings!

Cleaner React: Conditional Rendering

Matti Salokangas — Fri, 25 Sep 2020 17:10:47 +0000

Often times React components become hard to understand due to conditional rendering. At first a simple if/else or ternary operator appears benign to your overall readability, but over time as changes occur another if/else or ternary may be added.

Compounding this issue is when conditional operators are nested many times, which unfortunately is too easy to do.

Let's first look at how to conditionally render in React and then dive into several experiments that might present more readable ways to conditionally render in React.

Conditional Rendering Styles

Simple Scenario

Scenario: Show a login component vs a register component given the property "isLoggedIn"

Using &&

Used quite often the "&&" is easy to throw in for some quick conditional logic.

const Session = ({ isLoggedIn }) => {  
 return (  
   <>  
     {isLoggedIn && <Login />}  
     {!isLoggedIn && <SignOut />}  
   </>  
 );  
};

Using If/Else Statements

Given this simple scenario, a guard clause works here and is a bit more readable than the "&&".

const Session = ({ isLoggedIn }) => {  
 if (isLoggedIn) {  
   return <SignOut />  
 }  

 return <Login />  
};

Using Ternary Operator

This also is easier to understand; being able to one line this is pretty nice.


const Session = ({ isLoggedIn }) => isLoggedIn ? <SignOut /> : <Login />;

Complex Scenario

Scenario: Show a login component vs a register component given the property "isLoggedIn", in addition show the "UnicornLogin" component if the "isUnicorn" flag is true.

Using &&

This is awful. It is clear that the "&&" is only good to use sparingly and only when there is one condition.

const Session = ({ isLoggedIn, isUnicorn }) => {  
 <>  
   {isLoggedIn && !isUnicorn && <Login />}  
   {!isLoggedIn && isUnicorn && <isUnicorn />}  
   {!isLoggedIn && !isUnicorn && <SignOut />}  
 </>;  
};

Using If/Else Statements

Less awful, but this is going to make things tricky if you ever wanted to wrap each of the components being returned with another component.

const Session = ({ isLoggedIn, isUnicorn }) => {  
 if (isLoggedIn) {  
   return <SignOut />;  
 } else if (isUnicorn) {  
   return <UnicornLogin />;  
 };

 return <Login />;  
};

Using Ternary Operator

Also, less awful, yet prone to the same struggles as using if/else statements when more changes inevitably occur.

const Session = ({ isLoggedIn, isUnicorn }) => {  
 if (isLoggedIn) {  
   return <SignOut />;  
 }

 return isUnicorn ? <UnicornLogin /> : <Login />;  
};

Conditional Gotchas

Now that we've seen how to use conditional rendering in React, let's take a look at some specific examples where conditional rendering may not do what you expect.

Logical "&&" Operator

Rendering a 0 when mapping

When using "&&" to check the length of a data set and then mapping over it will render "0" when that list is empty.

This was recently highlighted by Kent C. Dodds in his article https://kentcdodds.com/blog/use-ternaries-rather-than-and-and-in-jsx

The code below will render "0" when data is empty.

const RenderData = ({ data }) =>  data.length && data.map(...);

This can be resolved by either using a ternary operator instead of "&&".

const RenderData = ({ data }) =>  data.length > 0 ? data.map(...) : null;

This can also be resolved by either using an if/else statement.

const RenderData = ({ data }) =>  data.length > 0 ? data.map(.const RenderData = ({ data }) => {  
 if (data.length === 0) return null;

 return data.map(...)  
}

Rendering a 0 in a component

This React Native specific, but when conditionally rendering a component and passing in your condition you may inadvertently render a 0. This results in your app crashing and the following error message: "Invariant Violation: Text strings must be rendered within a component.".

This will crash your app if "message" is ever 0:

message && <Text>{message}</Text>

Nested Ternaries

Ternaries are nice if you have one condition. However, it is too easy to not refactor and quickly add another check and then another.

This is a simple example, you can imagine what this would look like if each component we rendered were 5-10 or more lines long.

const RenderData = ({ data }) => {  
 return data.length === 0 ? null  
   : data.length === 1  
   ? <SingleItem data={data} />  
   : data.length === 2  
   ? <DoubleItem data={data} />  
   : <MultiItem data={data} />  
}

Writing Better Conditions

We've taken a look at how to write basic conditional statements in React, along with some pitfalls to avoid. Let's consider how we can write better conditional code in React.

Conditional Operator Component

I think it is easier to read JSX if your brain only has to parse and not conditional statements plus . So, how can we write conditional operators as XML?

Let's consider creating a component called "RenderIf" and takes a boolean property of "isTrue" and renders its children.

export const RenderIf = ({ children, isTrue }) => isTrue ? children : null;

RenderIf.propTypes = {  
 children: node.isRequired,  
 isTrue: bool.isRequired,  
};

Re-writing our example with the "RenderIf" component, I'm mostly looking at XML. However, there is still some boolean logic that could be cleaned up.

const RenderData = ({ data }) => {  
 return (  
   <>  
     <RenderIf isTrue={data.length === 1}>  
       <SingleItem data={data} />  
     </RenderIf>  
     <RenderIf isTrue={data.length === 2}>  
       <DoubleItem data={data} />  
     </RenderIf>  
     <RenderIf isTrue={data.length > 2}>  
       <MultiItem data={data} />  
     </RenderIf>  
   </>  
 );  
}

We can clean up the boolean logic by wrapping our "RenderIf" component.

const IfSingleItem = ({ children, data }) => <RenderIf isTrue={data.length === 1}>{children}</RenderIf>  
const IfDoubleItem = ({ children, data }) => <RenderIf isTrue={data.length === 2}>{children}</RenderIf>  
const IfMultiItem = ({ children, data }) => <RenderIf isTrue={data.length > 3}>{children}</RenderIf>

const RenderData = ({ data }) => {  
 return (  
   <>  
     <IfSingleItem data={data}>  
       <SingleItem data={data} />  
     </IfSingleItem>  
     <IfDoubleItem data={data}>  
       <DoubleItem data={data} />  
     </IfDoubleItem>  
     <IfMultiItem data={data}>  
       <MultiItem data={data} />  
     </IfMultiItem>  
   </>  
 );  
}

Having our Cake and Eating it too!

I personally like reading more declarative React, however one of the pitfalls that I had not mentioned is that the children for the RenderIf component will still go through a render cycle even if our condition is false. This is because RenderIf is still JSX vs being straight javascript.

So, how do we get around this?

I happen to write a RenderIf Babel plugin that does just this! You can find the code out on my GitHub here.

Essentially, this plugin will take code that looks like this:

<RenderIf isTrue={someCondition}>
  <span>I am the children</span>
</RenderIf>

and turn it into this:

{someCondition ? <span>I am the children</span> : null

So, we are getting our declarative syntax and when it is transpiled, we get the more performant version. Also, if you use this plugin you won't have to write your own RenderIf component! 🎉

When to Refactor

Often times if there is an accumulation of complexity in a component it is a sign that there are components that should be refactored out. Although knowing exactly when and how to refactor is hard to know, here are some general rules of thumb that you might consider.

100+ Lines of Code

Keep components to less than 100 lines. As you start to get into the 100-250 line territory you should really start thinking about refactoring. If you are at 500+ lines of code, that should be refactored as soon as possible.

High Cyclomatic Complexity

Cyclomatic complexity is the number of paths through your code. So, if you have a simple if/else block, then it has a cyclomatic complexity of 2, where as if you had a block of if/else if/else if/else if/else, the cyclomatic complexity would be 5.

You can enforce this by using the ESLint complexity rule

It is up to you what level of complexity is appropriate, but somewhere around 4-5 is usually a good place to start.

Cleaner React

We can write cleaner React by extracting out distracting syntax and knowing when to refactor.

Creating a helper component like "RenderIf" is an example in how you could extract out conditional logic into a declarative syntax. This makes it a little bit easier for your brain since it is mostly taking in XML. Building on that idea, we can wrap our helper component to create a richer set of conditional components that add even more context.

At the end of the day, a component that is large and complex, no matter how clean the React is, will be prone to bugs and simply not fun to work on. It is a good practice to know when to refactor and to be disciplined to do that refactor when you know it needs to happen.

Happy coding and keep your React clean!

Originally posted on ZEAL's blog here
‍

Coding without Ego

Matti Salokangas — Sun, 01 Mar 2020 19:03:31 +0000

I think an often overlooked quality that makes a software developer "senior" is that they don't feel like they need to defend their code, that they are open to changing directions and to doing it another way.

However, I also think there are "senior" developers out there that simply want to do it their way and don't care what others think. That is ok too; just not great if you want to help others grow.

Ego

What is the ego? You ask google and it will tell you "a person's sense of self-esteem or self-importance.". It makes me think that if I am not defending my self-importance that I might just let others run the show. This "defense" can be distilled down to one's own pride. We are often told to take "pride" in our work, but no one really said to take some pride, but be open to feedback because it probably could be improved.

Pride

I remember taking so much pride in my code that if someone said anything about it, I would take it personally. I think anyone who is a programmer knows what I am talking about. Well, there's no getting around it and it is just part of the journey! Often times I think a new developer is so eager that she or he works relentlessly to learn all of the things...I mean the learning tracks nowadays are nuts! It's no wonder so many of us get so burned out and then have to deal with imposter syndrome. 😩😩😩

Pairing

Given today's climate, it is very difficult to feel comfortable. This was why I wrote about staying uncomfortable; you simply cannot keep up and might as well just accept it.

Working at Zeal we pair program a lot. Sure, there's a lot of debate about this; some do not like pairing others do. If it isn't your thing, no big deal, but I think we can all take something away from pairing that has nothing to do with writing code and getting a product shipped.

I remember my first pairing experience. It was kinda like all of sudden I was on a stage and was live coding, which back then was scary for me. Thankfully the folks at Zeal were kind to me and showed me the way with kindness and thoughtfulness. It was an experience that set the tone for me and how I approach pairing.

Simply put, I code (and pair) without ego. I do not identify with my code. The things that I do try to identify with are:

Readability
Maintainability
Testability

These 3 things are more often than not the most important things for me as I am writing code. All of these are selfless and require that I do things that might be uncomfortable. A refactor that I just don't feel like doing or oftentimes listening to my pair and realizing that I am wrong.

Nobody loves brown field code, but it can better if we write code that is easier to read, update and test. That is indisputable.

Empathy

I do believe that empathy is gaining more and more momentum as a fundamental skill for a software developer. But, how do
you teach this? Well, for starters let's ask google again what this is: "the ability to understand and share the feelings of another." Pretty straight forward definition, but in practice, we have all these hurdles in our mind. The biggest is our own ego. Ego is nearly the antithesis of empathy.

It certainly is good to feel good about the work you do and you should! However, this doesn't help others feel good. This is where empathy comes in and is equally important to be aware of as ego. When pairing empathy is paramount, especially if you are in a position of seniority, it can be quite threatening to your pair. In these scenarios your collective result will be colored by the subtle tension between you and your pair; the code will simply not be as good as it could have been.

When pairing, ask yourself (be honest):

Am I resisting input from my pair? If so, ask why? Probably not a good reason...
Is there a sense of flow? If not, where is the resistance?
Where are my reactions coming from? Am I reacting out of compassion or fear?

There are many questions you can ask yourself, but the point is to become aware. Pairing can be a humbling experience for many. It can be a bit painful on bad days, but on good days it can be a greater experience than coding solo. It can be even better when ego and empathy are balanced. The key is awareness.

Be aware of how your pair is feeling.

Be Better than Yesterday

It is our ego that makes us feel like an imposter or that we didn't do a "good enough" job. It is a hollow feeling and
sucks for sure. However, this is a lie; we did do a "good enough" job and we are not an imposter. At least that is what
our best friend would tell us. But, this isn't what we tell ourselves, we are our own worst enemy unless we become aware of it. So, pay attention to what is going on in your mind, specifically that inner dialog. Simply through awareness, you can improve your own world and make today a little better.

Paying attention to your thoughts helps, but only goes so far. Not feeling bad is better than feeling bad. But, feeling good is certainly better than not feeling bad. It is a funny thing that when we help others we get a sense of fulfillment. It is like free happy points. Honestly, give it a try. Go out of your way, do something unexpected for a stranger that simply makes their day. You will have a rush of feel-good neurotransmitters and your overall sense of well being will be much higher!

It is the Balance

To bring it together, I believe we can all write better code by balancing our ego with empathy. Be proud of whatever you do, because you should feel good about yourself. But, at the same time, you should feel that same sense of pride in others as you acknowledge their triumphs.

The balance is tricky, but essentially be selfish, but also be selfless.

See original post here

DEV Community: Matti Salokangas

An Introduction to React

Starting Off

What is React?

Writing Components

Props vs State

Example

Designing Components

Function vs Class Components

Examples

Function Components

Class Components

Lifting State Up

Global State

Example

Hooks

useState

useEffect

useLayoutEffect

useRef

Rules of Hooks

Render and Portals

Mapping Data and Keys

Odd Html Attributes

More Advanced Topics

Frameworks

Cleaner React: Conditional Rendering

Conditional Rendering Styles

Simple Scenario

Using &&

Using If/Else Statements

Using Ternary Operator

Complex Scenario

Using &&

Using If/Else Statements

Using Ternary Operator

Conditional Gotchas

Logical "&&" Operator

Rendering a 0 when mapping

Rendering a 0 in a component

Nested Ternaries

Writing Better Conditions

Conditional Operator Component

Having our Cake and Eating it too!

When to Refactor

100+ Lines of Code

High Cyclomatic Complexity

Cleaner React

Coding without Ego

Ego

Pride

Pairing

Empathy

Be Better than Yesterday

It is the Balance