Author Archive for: admin

Original Source: https://www.sitepoint.com/work-with-forms-in-react/?utm_source=rss

Almost every application needs to accept user input at some point, and this is usually achieved with the venerable HTML form and its collection of input controls. If you’ve recently started learning React, you’ve probably arrived at the point where you’re now thinking, “So how do I work with forms?”

This article will walk you through the basics of using forms in React to allow users to add or edit information. We’ll look at two different ways of working with input controls and the pros and cons of each. We’ll also take a look at how to handle validation, and some third-party libraries for more advanced use cases.

Uncontrolled Inputs

The most basic way of working with forms in React is to use what are referred to as “uncontrolled” form inputs. What this means is that React doesn’t track the input’s state. HTML input elements naturally keep track of their own state as part of the DOM, and so when the form is submitted we have to read the values from the DOM elements themselves.

In order to do this, React allows us to create a “ref” (reference) to associate with an element, giving access to the underlying DOM node. Let’s see how to do this:

class SimpleForm extends React.Component {
constructor(props) {
super(props);
// create a ref to store the DOM element
this.nameEl = React.createRef();
this.handleSubmit = this.handleSubmit.bind(this);
}

handleSubmit(e) {
e.preventDefault();
alert(this.nameEl.current.value);
}

render() {
return (
<form onSubmit={this.handleSubmit}>
<label>Name:
<input type=”text” ref={this.nameEl} />
</label>
<input type=”submit” name=”Submit” />
</form>
)
}
}

As you can see above, for a class-based component you initialize a new ref in the constructor by calling React.createRef, assigning it to an instance property so it’s available for the lifetime of the component.

In order to associate the ref with an input, it’s passed to the element as the special ref attribute. Once this is done, the input’s underlying DOM node can be accessed via this.nameEl.current.

Let’s see how this looks in a functional component:

function SimpleForm(props) {
const nameEl = React.useRef(null);

const handleSubmit = e => {
e.preventDefault();
alert(nameEl.current.value);
};

return (
<form onSubmit={handleSubmit}>
<label>Name:
<input type=”text” ref={nameEl} />
</label>
<input type=”submit” name=”Submit” />
</form>
);
}

There’s not a lot of difference here, other than swapping out createRef for the useRef hook.

Example: login form
function LoginForm(props) {
const nameEl = React.useRef(null);
const passwordEl = React.useRef(null);
const rememberMeEl = React.useRef(null);

const handleSubmit = e => {
e.preventDefault();

const data = {
username: nameEl.current.value,
password: passwordEl.current.value,
rememberMe: rememberMeEl.current.checked,
}

// Submit form details to login endpoint etc.
// …
};

return (
<form onSubmit={handleSubmit}>
<input type=”text” placeholder=”username” ref={nameEl} />
<input type=”password” placeholder=”password” ref={passwordEl} />
<label>
<input type=”checkbox” ref={rememberMeEl} />
Remember me
</label>
<button type=”submit” className=”myButton”>Login</button>
</form>
);
}

View on CodePen

While uncontrolled inputs work fine for quick and simple forms, they do have some drawbacks. As you might have noticed from the code above, we have to read the value from the input element whenever we want it. This means we can’t provide instant validation on the field as the user types, nor can we do things like enforce a custom input format, conditionally show or hide form elements, or disable/enable the submit button.

Fortunately, there’s a more sophisticated way to handle inputs in React.

Controlled Inputs

An input is said to be “controlled” when React is responsible for maintaining and setting its state. The state is kept in sync with the input’s value, meaning that changing the input will update the state, and updating the state will change the input.

Let’s see what that looks like with an example:

class ControlledInput extends React.Component {
constructor(props) {
super(props);
this.state = { name: ” };
this.handleInput = this.handleInput.bind(this);
}

handleInput(event) {
this.setState({
name: event.target.value
});
}

render() {
return (
<input type=”text” value={this.state.name} onChange={this.handleInput} />
);
}
}

As you can see, we set up a kind of circular data flow: state to input value, on change event to state, and back again. This loop allows us a lot of control over the input, as we can react to changes to the value on the fly. Because of this, controlled inputs don’t suffer from the limitations of uncontrolled ones, opening up the follow possibilities:

instant input validation: we can give the user instant feedback without having to wait for them to submit the form (e.g. if their password is not complex enough)
instant input formatting: we can add proper separators to currency inputs, or grouping to phone numbers on the fly
conditionally disable form submission: we can enable the submit button after certain criteria are met (e.g. the user consented to the terms and conditions)
dynamically generate new inputs: we can add additional inputs to a form based on the user’s previous input (e.g. adding details of additional people on a hotel booking)

Validation

As I mentioned above, the continuous update loop of controlled components makes it possible to perform continuous validation on inputs as the user types. A handler attached to an input’s onChange event will be fired on every keystroke, allowing you to instantly validate or format the value.

Continue reading
Working with Forms in React
on SitePoint.

Original Source: https://www.sitepoint.com/organize-large-react-application/?utm_source=rss

This article is by guest author Jack Franklin. SitePoint guest posts aim to bring you engaging content from prominent writers and speakers of the Web community.

In this article, I’ll discuss the approach I take when building and structuring large React applications. One of the best features of React is how it gets out of your way and is anything but descriptive when it comes to file structure. Therefore, you’ll find a lot of questions on Stack Overflow and similar sites asking how to structure applications. This is a very opinionated topic, and there’s no one right way. In this article, I’ll talk you through the decisions I make when building React applications: picking tools, structuring files, and breaking components up into smaller pieces.

Build Tools and Linting

It will be no surprise to some of you that I’m a huge fan of webpack for building my projects. Whilst it’s a complicated tool, the great work put into version 5 by the team and the new documentation site make it much easier. Once you get into webpack and have the concepts in your head, you really have incredible power to harness. I use Babel to compile my code, including React-specific transforms like JSX, and the webpack-dev-server to serve my site locally. I’ve not personally found that hot reloading gives me that much benefit, so I’m more than happy with webpack-dev-server and its automatic refreshing of the page.

I use ES Modules, first introduced in ES2015 (which is transpiled through Babel) to import and export dependencies. This syntax has been around for a while now, and although webpack can support CommonJS (aka, Node-style imports), it makes sense to me to start using the latest and greatest. Additionally, webpack can remove dead code from bundles using ES2015 modules which, whilst not perfect, is a very handy feature to have, and one that will become more beneficial as the community moves towards publishing code to npm in ES2015. The majority of the web ecosystem has moved towards ES Modules, so this is an obvious choice for each new project I start. It’s also what most tools expect to support, including other bundlers like Rollup, if you’d rather not use webpack.

Folder Structure

There’s no one correct folder structure for all React applications. (As with the rest of this article, you should alter it for your preferences.) But the following is what’s worked well for me.

Code lives in src

To keep things organized, I’ll place all application code in a folder called src. This contains only code that ends up in your final bundle, and nothing more. This is useful because you can tell Babel (or any other tool that acts on your app code) to just look in one directory and make sure it doesn’t process any code it doesn’t need to. Other code, such as webpack config files, lives in a suitably named folder. For example, my top-level folder structure often contains:

– src => app code here
– webpack => webpack configs
– scripts => any build scripts
– tests => any test specific code (API mocks, etc.)

Typically, the only files that will be at the top level are index.html, package.json, and any dotfiles, such as .babelrc. Some prefer to include Babel configuration in package.json, but I find those files can get large on bigger projects with many dependencies, so I like to use .eslintrc, .babelrc, and so on.

React Components

Once you’ve got a src folder, the tricky bit is deciding how to structure your components. In the past, I’d put all components in one large folder, such as src/components, but I’ve found that on larger projects this gets overwhelming very quickly.

A common trend is to have folders for “smart” and “dumb” components (also known as “container” and “presentational” components), but personally I’ve never found explicit folders work for me. Whilst I do have components that loosely categorize into “smart” and “dumb” (I’ll talk more on that below), I don’t have specific folders for each of them.

We’ve grouped components based on the areas of the application where they’re used, along with a core folder for common components that are used throughout (buttons, headers, footers — components that are generic and very reusable). The rest of the folders map to a specific area of the application. For example, we have a folder called cart that contains all components relating to the shopping cart view, and a folder called listings that contains code for listing things users can buy on a page.

Categorizing into folders also means you can avoid prefixing components with the area of the app they’re used for. As an example, if we had a component that renders the user’s cart total cost, rather than call it CartTotal I might prefer to use Total, because I’m importing it from the cart folder:

import Total from ‘../cart/total’
// vs
import CartTotal from ‘../cart/cart-total’

This is a rule I find myself breaking sometimes. The extra prefix can clarify, particularly if you have two to three similarly named components, but often this technique can avoid extra repetition of names.

Prefer the jsx Extension over Capital Letters

A lot of people name React components with a capital letter in the file, to distinguish them from regular JavaScript files. So in the above imports, the files would be CartTotal.js, or Total.js. I tend to prefer to stick to lowercase files with dashes as separators, so in order to distinguish I use the .jsx extension for React components. Therefore, I’d stick with cart-total.jsx.

This has the small added benefit of being able to easily search through just your React files by limiting your search to files with .jsx, and you can even apply specific webpack plugins to these files if you need to.

Whichever naming convention you pick, the important thing is that you stick to it. Having a combination of conventions across your codebase will quickly become a nightmare as it grows and you have to navigate it. You can enforce this .jsx convention using a rule from eslint-plugin-react.

One React Component per File

Following on from the previous rule, we stick to a convention of one React component file, and the component should always be the default export.

Normally our React files look like so:

import React from ‘react’

export default function Total(props) {
…
}

In the case that we have to wrap the component in order to connect it to a Redux data store, for example, the fully wrapped component becomes the default export:

import React, { Component, PropTypes } from ‘react’
import { connect } from ‘react-redux’

export default function Total(props) {
…
}

export default connect(() => {…})(Total)

You’ll notice that we still export the original component. This is really useful for testing, where you can work with the “plain” component and not have to set up Redux in your unit tests.

By keeping the component as the default export, it’s easy to import the component and know how to get at it, rather than having to look up the exact name. One downside to this approach is that the person importing can call the component anything they like. Once again, we’ve got a convention for this: the import should be named after the file. So if you’re importing total.jsx, the component should be imported as Total. user-header.jsx becomes UserHeader, and so on.

It’s worth noting that the one component per file rule isn’t always followed. If you end up building a small component to help you render part of your data, and it’s only going to be used in one place, it’s often easier to leave it in the same file as the component that uses it. There’s a cost to keeping components in separate files: there are more files, more imports and generally more to follow as a developer, so consider if it’s worth it. Like most of the suggestions in this article, they are rules with exceptions.

Continue reading
How to Organize a Large React Application and Make It Scale
on SitePoint.

Original Source: https://www.sitepoint.com/react-higher-order-components/?utm_source=rss

In this article, we’ll discuss how to use higher-order components to keep your React applications tidy, well-structured and easy to maintain. We’ll discuss how pure functions keep code clean and how these same principles can be applied to React components.

Pure Functions

A function is considered pure if it adheres to the following properties:

all the data it deals with is declared as arguments
it doesn’t mutate data it was given or any other data (these are often referred to as side effects)
given the same input, it will always return the same output.

For example, the add function below is pure:

function add(x, y) {
return x + y;
}

However, the function badAdd below is impure:

let y = 2;
function badAdd(x) {
return x + y;
}

This function is not pure because it references data that it hasn’t directly been given. As a result, it’s possible to call this function with the same input and get different output:

let y = 2;
badAdd(3) // 5
y = 3;
badAdd(3) // 6

To read more about pure functions you can read “An introduction to reasonably pure programming” by Mark Brown.

Whilst pure functions are very useful, and make debugging and testing an application much easier, occasionally you’ll need to create impure functions that have side effects, or modify the behavior of an existing function that you’re unable to access directly (a function from a library, for example). To enable this, we need to look at higher-order functions.

Higher-order Functions

A higher-order function is a function that returns another function when it’s called. Often they also take a function as an argument, but this isn’t required for a function to be considered higher-order.

Let’s say we have our add function from above, and we want to write some code so that when we call it, we log the result to the console before returning the result. We’re unable to edit the add function, so instead we can create a new function:

function addAndLog(x, y) {
const result = add(x, y);
console.log(`Result: ${result}`);
return result;
}

We decide that logging results of functions is useful, and now we want to do the same with a subtract function. Rather than duplicate the above, we could write a higher-order function that can take a function and return a new function that calls the given function and logs the result before then returning it:

function logAndReturn(func) {
return function(…args) {
const result = func(…args)
console.log(‘Result’, result);
return result;
}
}

Now we can take this function and use it to add logging to add and subtract:

const addAndLog = logAndReturn(add);
addAndLog(4, 4) // 8 is returned, ‘Result 8’ is logged

const subtractAndLog = logAndReturn(subtract);
subtractAndLog(4, 3) // 1 is returned, ‘Result 1’ is logged;

logAndReturn is a higher-order function because it takes a function as its argument and returns a new function that we can call. These are really useful for wrapping existing functions that you can’t change in behavior. For more information on this, check M. David Green’s article “Higher-Order Functions in JavaScript”, which goes into much more detail on the subject.

See the Pen
Higher Order Functions by SitePoint (@SitePoint)
on CodePen.

Higher-order Components

Moving into React land, we can use the same logic as above to take existing React components and give them some extra behaviors.

Note: with the introduction of React Hooks, released in React 16.8, higher-order functions became slightly less useful because hooks enabled behavior sharing without the need for extra components. That said, they are still a useful tool to have in your belt.

In this section, we’re going to use React Router, the de facto routing solution for React. If you’d like to get started with the library, I highly recommend the React Router documentation as the best place to get started.

React Router’s Link component

React Router provides a <NavLink> component that’s used to link between pages in a React application. One of the properties that this <NavLink> component takes is activeClassName. When a <NavLink> has this property and it’s currently active (the user is on a URL that the link points to), the component will be given this class, enabling the developer to style it.

This is a really useful feature, and in our hypothetical application we decide that we always want to use this property. However, after doing so we quickly discover that this is making all our <NavLink> components very verbose:

<NavLink to=”/” activeClassName=”active-link”>Home</NavLink>
<NavLink to=”/about” activeClassName=”active-link”>About</NavLink>
<NavLink to=”/contact” activeClassName=”active-link”>Contact</NavLink>

Notice that we’re having to repeat the class name property every time. Not only does this make our components verbose, it also means that if we decide to change the class name we’ve got to do it in a lot of places.

Instead, we can write a component that wraps the <NavLink> component:

const AppLink = (props) => {
return (
<NavLink to={props.to} activeClassName=”active-link”>
{props.children}
</NavLink>
);
};

And now we can use this component, which tidies up our links:

<AppLink to=”/home” exact>Home</AppLink>
<AppLink to=”/about”>About</AppLink>
<AppLink to=”/contact”>Contact</AppLink>

In the React ecosystem, these components are known as higher-order components, because they take an existing component and manipulate it slightly without changing the existing component. You can also think of these as wrapper components, but you’ll find them commonly referred to as higher-order components in React-based content.

Continue reading
Higher-order Components: A React Application Design Pattern
on SitePoint.

Original Source: https://www.hongkiat.com/blog/beautiful-halloween-wallpapers/

Halloween, which falls on the 31th of October is a holiday that normally associated with symbols like “Jack o’ Lanterns“, skeleton, pumpkins and activities like bonfire, costume…

Visit hongkiat.com for full content.

Original Source: https://smashingmagazine.com/2020/10/introduction-to-framer-motion/

In this article, we’ll take a closer look at how Framer Motion helps us in creating awesome animations. We’ll learn how motion components work and learn how to chain animations together. We’ll look into how to make gesture-triggered, timed, and scroll animations with Framer motion. Along the way, we’ll use the things we learn to build five demo applications I’ve set up to show us how we can integrate Framer Motion into real-world applications.

This tutorial will be beneficial to readers who are interested in integrating animations in their React application.

Note: This article requires a basic understanding of React and CSS.

What Is Framer Motion?

Framer Motion is an animation library that makes creating animations easy. Its simplified API helps us abstract the complexities behind animations and allows us to create animations with ease.

Motion Components

These are the building blocks of Framer motion. Motion components are created by prefixing motion to your regular HTML and SVG element (e.g, motion.h1). Motion components can accept several props, with the basic one being the animate prop. This prop takes in an object where we define the properties of that component we want to animate. The properties we define will be animated when the component mounts in the DOM.

Let’s animate an h1 text using Framer Motion. First, we install the framer-motion library and import motion.

npm i framer-motion
import { motion } from ‘framer-motion’;

Then we convert the h1 into a motion component.

<motion.h1
animate={{x: 20, y: -20}}>
This is a motion component
</motion.h1>

This will cause the h1 to slide 20px to the right and move 20px up when it loads. When units aren’t added, calculations are done using pixels. However, you can explicitly set the units you want the calculations to be based on, animate={{x: “20rem”, y: “-20rem”}}>.

By default, a motion component will be animated from the state defined from its styles to those in the animate prop. However, if we wanted to, we could hijack and define the initial animation state of the component using the initial prop. While the animate prop is used to define the behavior of components when they mount, the initial prop defines their behavior before they mount.

If we want our h1 to come in from the left, we control that using the initial prop.

<motion.h1
initial={{x: -1000}}
animate={{x: 20}}>
This is a motion component
</motion.h1>

Now, when the h1 mounts, it slides in from the left.

We are not limited to a single animation. We can define a series of animations called keyframes in an array of values. Each value will get animated in sequence.

<motion.h1
initial={{x: -1000}}
animate={{x: [20, 50, 0, -70, 40] }}>
This is a motion component
</motion.h1>

The transition prop allows us to define how the animations occur. With it, we define how values animate from one state to another. Among other things, we can define the duration, delay, and type of animation using this prop.

<motion.h1
initial={{ x: -1000 }}
animate={{ x: 0 }}
transition={{
type: “tween”,
duration: “2”,
delay: “1”
}}>
This is a motion component
</motion.h1>

Say we were to animate several motion components simultaneously, like in the code snippet below.

<div className=”App”>
<motion.h1
initial={{ x: -1000 }}
animate={{ x: 0 }}
transition={{
type: “tween”,
duration: “2”,
delay: “1”
}}>
This is a motion h1
</motion.h1>
<motion.h2
initial={{ y: -1000 }}
animate={{ y: 0 }}
transition={{
type: “tween”,
duration: “1”,
delay: “.4”
}}>This is a motion h2
</motion.h2>
<motion.h3
initial={{ x: 100, opacity: 0 }}
animate={{ x: 0, opacity: 1 }}>
This is a motion h3
</motion.h3>
<motion.h4
initial={{ scale: 0.7 }}
animate={{ scale: 1.7 }}
transition={{
type: “tween”,
duration: “2”,
delay: “1”
}}>
This is a motion h4
</motion.h4>
</div>

While this works, the variants prop in Framer Motion enables us to extract our animation definitions into a variants object. Not only do variants make our code cleaner, but they allow us to create even more powerful and complex animations.

Extracting our animation definitions into variants objects, we have this:

const H1Variants = {
initial: { x: -1000 },
animate: { x: 0 },
transition: {
type: “tween”,
duration: 2,
delay: 1
}
}
const H2Variants = {
initial: { y: -1000 },
animate: { y: 0 },
transition: {
type: “tween”,
duration: 1,
delay: .4
}
}
const H3Variants = {
initial:{ x: 100, opacity: 0 },
animate:{ x: 0, opacity: 1 }
}
const H4Variants = {
initial:{ scale: 0.7 },
animate:{ scale: 1.7 },
transition:{
type: “tween”,
duration: “2”,
delay: “1”
}
}

Instead of passing the animation definitions into a component’s initial and animate props directly, we extract these definitions into standalone variant objects. In the variant objects, we define variant names that describe each animation’s name as variants.

<div className=”App”>
<motion.h1
variants={H1Variants}
initial=’initial’
animate=’animate’
>
This is a motion h1
</motion.h1>
<motion.h2
variants={H2Variants}
initial=’initial’
animate=’animate’
>
This is a motion h2
</motion.h2>
<motion.h3
variants={H3Variants}
initial=’initial’
animate=’animate’
>
This is a motion h3
</motion.h3>
<motion.h4
variants={H4Variants}
initial=’initial’
animate=’animate’
>
This is a motion h4
</motion.h4>
</div>

In the variants prop, we pass in the name of the variant objects for each motion component and then pass in the animations to the initial and animate props.

We can take our current setup with variants further to reduce repetition. Using variants, we can propagate animation attributes down through the DOM from a parent motion component. For this to work, we create variants for the parent motion.div with similar animation names in its variant object as its children. By doing this, we won’t have to pass the animation names’ to each child component. Behind the scenes, the parent element handles that for us.

const ContainerVariants = {
initial: {},
animate: {}
};
const H1Variants = {
initial: { x: -1000 },
animate: { x: 0 },
transition: {
type: “tween”,
duration: 2,
delay: 1
}
};
//more variants below

<motion.div
className=”App”
variants={ContainerVariants}
initial=”initial”
animate=”animate”
>
<motion.h1 variants={H1Variants}>This is a motion h1</motion.h1>
<motion.h2 variants={H2Variants}>This is a motion h2</motion.h2>
<motion.h3 variants={H3Variants}>This is a motion h3</motion.h3>
<motion.h4 variants={H4Variants}>This is a motion h4</motion.h4>
</motion.div>

Now we have a cleaner code with no repetitions. We turned the container div to a motion component so we could pass in the ContainerVariants object we defined. Since we don’t define any animations on the container, we pass in empty objects to initial and animate. Your animation names must be the same in every variant object for the propagation to work.

Now we understand the basics of Framer Motion. Let’s begin building our fist of 5 demo applications.

Icon Shop

We can create interactive animations based on gestures. Motion components are currently able to listen for hover, tap, pan, and drag gesture detection. We’ll be building this Icon Shop app using the whileHover prop.

Components

App.js: this holds the heading texts.
Card.jsx: here, we define the animations for the icon cards.
CardContainer.jsx: we import and loop through the icons.
styles.js: create, style, and export the motion components. I used styled-components for styling the components.

Let’s start with App.js.

import { H1, H2 } from “./Styles”;
import CardContainer from “./CardContainer”;

return (
<div>
<H1
initial={{ y: -100 }}
animate={{ y: 0, transition: { delay: 1 } }}>
Icon Shop
</H1>
<H2
initial={{ x: -1000 }}
animate={{ x: 0, transition: { delay: 1 } }}>
Hover over the cards to see the motion magic
</H2>
<CardContainer />
</div>
);

We import the H1 and H2 motion components we created in the Styles.js file. Since they are motion components, we use the initial and animate props to define their behavior before and when they mount. Here, we also import and display the CardContiner component.

Now, the CardContainer.js.

import { Container } from “./Styles”;
import Card from “./Card”;
import { ReactComponent as AddIcon } from “./assets/add.svg”;
import { ReactComponent as AirplaneIcon } from “./assets/airplane.svg”;
import { ReactComponent as AlarmIcon } from “./assets/alarm.svg”;
//more svg imports below…

const icons = [
<AddIcon />,
<AirplaneIcon />,
<AlarmIcon />,
//more icons below
];

const CardContainer = () => {
return (
<Container initial={{ x: -1000 }} animate={{ x: 0 }}>
{icons.map((icon) => (
<Card icon={icon} />
))}
</Container>
);
};

Here, we import the SVGs, the Container motion component, and the Card component.

Similar to H1 and H2 in App.js, we define animations of the Container using the initial and animate props. When it loads, it will create a cool effect of sliding in from the left of the browser.

Now, Card.js

import { CardBox, IconBox } from “./Styles”;
const CardVariants = {
beforeHover: {},
onHover: {
scale: 1.1
}
};
const IconVariants = {
beforeHover: {
opacity: 0,
y: -50
},
onHover: {
opacity: 1,
y: 0,
scale: 1.5,
transition: {
type: “tween”
}
}
};

const Card = ({ icon }) => {
console.log(icon);
return (
<CardBox variants={CardVariants} initial=”beforeHover” whileHover=”onHover”>
<IconBox variants={IconVariants}>{icon}</IconBox>
</CardBox>
);
};

Here, we create two variant objects with beforeHover and onHover animations. In the CardVariants object, we don’t want to do anything initially, so beforeHover is an empty object. onHover we increase the scale of the card box.

In the IconVariants object, we define the initial state of the IconBox in its beforeHover. We set its opacity to 0 and push it upwards by 50px. Then, in onHover, we set the opacity back to 1, push it back to its default position, and change the transition type to tween. Then we pass in the variants to their respective motion components. We make use of the propagation, so we don’t need to explicitly set the initial and animate props to the IconBox component.

Animated Navbar

We’ll build a simple Navigation component, and we’ll see how we can create timing relationships between parent and children motion components.

Components

App.js: this holds the heading texts.
Styles.js: create, style, and export the motion components. The components are styled using styled-components.

Let’s take a look at the App.js file.

import { Header, Nav, Link, SvgBox } from “./Styles”;

function App() {
const [isOpen, setIsOpen] = useState(false);
const iconVariants = {
opened: {
rotate: 135
},
closed: {
rotate: 0
}
};
const menuVariants = {
opened: {
top: 0,
transition: {
when: “beforeChildren”,
staggerChildren: 0.5
}
},
closed: {
top: “-90vh”
}
};
const linkVariants = {
opened: {
opacity: 1,
y: 50
},
closed: {
opacity: 0,
y: 0
}
};

We create an isOpen state that will be used to check if the Navbar is open or not. We create 3 variant objects, iconVariants, menuVariants, and linkVariants where we define the animations for the SvgBox, Nav, and Link motion components respectively. The iconVariants is used to rotate the SvgBox 135deg when it’s hovered over. We don’t need to add “deg” to the value. In the menuVariants, we control the top position of the Nav like you would using the position property in CSS. We toggle the top position of the Nav based on the isOpen state.

With variants, we can create timing relationships between parent and children motion components. We define the relationship between parent Nav and its child, Link using the when property in the transition object. Here, set it to beforeChildren, so the parent component’s animations will finish before the child’s animation begins.

Using the staggerChildren property, we set a timing order for each link. Each link will take 0.5 seconds to appear one after the other. This creates a nice visual cue when the Nav is opened. In the linkVariants we animate the opacity and the vertical position of each link.

<div className=”App”>
<Header>
<SvgBox
variants={iconVariants}
animate={isOpen ? “opened” : “closed”}
onClick={() => setIsOpen(!isOpen)}
>
<svg
width=”24″
height=”24″
viewBox=”0 0 24 24″
fill=”none”
xmlns=”http://www.w3.org/2000/svg”
>
<path
d=”M12 4C11.4477 4 11 4.44772 11 5V11H5C4.44772 11 4 11.4477 4 12C4 12.5523 4.44772 13 5 13H11V19C11 19.5523 11.4477 20 12 20C12.5523 20 13 19.5523 13 19V13H19C19.5523 13 20 12.5523 20 12C20 11.4477 19.5523 11 19 11H13V5C13 4.44772 12.5523 4 12 4Z”
fill=”#fff”
/>
</svg>
</SvgBox>
</Header>
<Nav
initial={false}
variants={menuVariants}
animate={isOpen ? “opened” : “closed”}
>
<Link variants={linkVariants}>home</Link>
<Link variants={linkVariants}>about</Link>
<Link variants={linkVariants}>gallery</Link>
</Nav>
</div>

Here, we pass in the variants to their respective components. In the SvgBox, we toggle the state of isOpen whenever it’s clicked, then conditionally animate it based on the state. Like the SvgBox, we conditionally animate the Nav and the Links based on isOpen’s state.

Animated Modal

We’ll build a modal component and learn about Framer Motion’s AnimatePresence, and how it allows us animate elements as they leave the DOM.

Components:

App.js: we set up the showModal state here.
Modal.jsx: the actual animation work takes place here.
Styles.js: create, style, and export the motion components. The components are styled using styled-components.

Let’s look into App.js

import { ToggleButton, Container } from “./Styles”;
import Modal from “./Modal”;

function App() {
const [showModal, setShowModal] = useState(false);
const toggleModal = () => {
setShowModal(!showModal);
};
return (
<Container>
<ToggleButton
initial={{ x: -700 }}
animate={{
x: 0,
transition: { duration: 0.5 }
}}
onClick={toggleModal}
>
Toggle Modal
</ToggleButton>
<Modal showModal={showModal} />
</Container>
);
}

We create a showModal state that will be used to conditionally render the modal. The toggleModal function will toggle the state whenever the ToggleButton is clicked. ToggleButton is a motion component, so we can define animations for it. When it mounts, it slides in from the left. This animation runs for 0.5 seconds. We also pass in the showModal state to the Modal through props.

Now, Modal.jsx

import { AnimatePresence } from “framer-motion”;
import { ModalBox, ModalContent, Container } from “./Styles”;

<Container>
<AnimatePresence>
{showModal && (
<ModalBox
initial={{ opacity: 0, y: 60, scale: 0.3 }}
animate={{
opacity: 1,
y: 0,
scale: 1,
transition: { type: “spring”, stiffness: 300 }
}}
exit={{ opacity: 0, scale: 0.5, transition: { duration: 0.6 } }}
>
<ModalContent
initial={{ y: -30, opacity: 0 }}
animate={{ y: 0, opacity: 1, transition: { delay: 1 } }}
>
Modal content!!!!
</ModalContent>
</ModalBox>
)}
</AnimatePresence>
</Container>

We import AnimatePresence from framer-motion. It allows us to set exit animations for components when they leave DOM. We conditionally render the Modal based on the showModal state. We define the animations for the ModalBox and ModalContent through their initial and animate props. There’s also a new prop here, exit. Having AnimatePresence as a wrapper allows us to add exit animations to ModalBox in the exit prop.

Scroll Animation

We’ll use a combination of the useAnimation hook and react-intersection-observer to create scroll-triggered animations.

Components

App.js: we set up the animations for the Box component and render it in App
Styles.js: create, style, and export the motion components. The components are styled using styled-components.

import React, { useEffect } from “react”;
import { useAnimation } from “framer-motion”;
import { useInView } from “react-intersection-observer”;
import { Container, H1,StyledBox } from “./Styles”;

const BoxVariants = {
visible: { opacity: 1, x: 0, transition: { duration: 1 } },
hidden: { opacity: 0, x: 300 },
};

const Box = () => {
const controls = useAnimation();
const [ref, inView] = useInView();
useEffect(() => {
if (inView) {
controls.start(“visible”);
}
}, [controls, inView]);
return (
<StyledBox
ref={ref}
animate={controls}
initial=”hidden”
variants={BoxVariants}
/>
);
};

The useAnimation hook allows us to control the sequences in which our animations occur. We have access to controls.start and controls.stop methods that we can use to manually start and stop our animations. We pass in the initial hidden animaton to StyledBox. We pass in the controls we defined with the start method to StyledBox animate prop.

react-intersection-observer’s useInView hook allows us to track when a component is visible in the viewport. The useInView hook gives us access to ref, which we pass to the component we want to watch, and the inView boolean, that tells us if that element is inView or not. We use the useEffect to call controls.start whenever the element we’re watching, StyledBox is in view. We pass in controls and inView as useEffect’s dependencies. Also, we pass in the variants we defined, BoxVariants to StyledBox.

Hero Animation

We’ll build a cool hero banner animation using the useCycle hook. We’ll understand how useCycle allows us to cycle through animations.

import React, { useEffect } from “react”;
import { useCycle } from “framer-motion”;
import { Container, H1, HeroSection, Banner, TextBox } from “./Styles”;
import { ReactComponent as BannerIllustration } from “./bighead.svg”;

const H1Variants = {
initial: { y: -200, opacity: 0 },
animate: { y: 0, opacity: 1, transition: { delay: 1 } },
};
const TextVariants = {
initial: { x: 400 },
animate: { x: 0, transition: { duration: 0.5 } },
};
const BannerVariants = {
animationOne: { x: -250, opacity: 1, transition: { duration: 0.5 } },
animationTwo: {
y: [0, -20],
opacity: 1,
transition: { yoyo: Infinity, ease: “easeIn” },
},
};

We define 3 variants, H1Variants, TextVariants, and BannerVariants. However, our focus is BannerVariants. We define 2 animations, animationOne and animationTwo in BannerVariants. These are the animations we pass into the useCycle to cycle through.

const [animation, cycleAnimation] = useCycle(“animationOne”, “animationTwo”);
useEffect(() => {
setTimeout(() => {
cycleAnimation();
}, 2000);
}, []);

useCycle works similar to the useState hook. In the destructured array, animation represents the animation that is active, whether animationOne or animationTwo. The cylceAnimation function that cycles between the animation we defined. We pass in the animations we want to cycle through into useCycle and call cylceAnimation after 2 seconds in useEffect.

<div className=”App”>
<Container>
<H1 variants={H1Variants} initial=”initial” animate=”animate”>
Cool Hero Section Anmiation
</H1>
<HeroSection>
<TextBox variants={TextVariants} initial=”initial” animate=”animate”>
Storage shed, troughs feed bale manure, is garden wheat oats at
augers. Bulls at rose garden cucumbers mice sunflower wheat in pig.
Chainsaw foal hay hook, herbs at combine harvester, children is
mallet. Goat goose hen horse. Pick up truck livestock, pets and
storage shed, troughs feed bale manure, is garden wheat oats at
augers. Lamb.
</TextBox>
<Banner variants={BannerVariants} animate={animation}>
<BannerIllustration />
</Banner>
</HeroSection>
</Container>
</div>

At the end of everything, we pass in the variants to their respective components and watch the magic happen. With this, the Banner will initially slide in from the right based on the animations we defined in animationOne, and after 2 seconds, cycleAnimation will be called which will trigger animationTwo.

As a wise Pig once said, “that’s all folks.”

Conclusion

We’ve gone through the basics of Framer Motion and seen some demo projects that give us a glimpse of the range of animations we can create. However, you can do so much more with it. I encourage you to dive into the docs and go wild.

Resources

Framer Motion Api Docs, Framer Motion
react-intersection-observer, npm
Framer Motion for React, NetNinja