Forem: Seth Corker

How to organise React components

Seth Corker — Sun, 17 Jan 2021 14:45:26 +0000

React’s popularity was its ease of use, it didn’t tell you where to put anything which made it easier than frameworks like Angular which had an expectation of your apps structure and dictated it more forcibly. This is also one of the hidden complexities of React, you can easily add it to your project, and it starts simple, but you’ll see pretty quickly that without some guidelines on where components and supporting files should be placed, it can get messy fast.

Here’s a common approach I used when I started writing React, organisation by type. Then, I’ll show you what I moved toward as projects grew. It’s a simple technique that allows for a nice developer experience as projects inevitably grow. First, let’s see why this problem exists.

Why React is great and why React is terrible

As a developer, the appeal of React was its position within the context of Model-View-Controller architecture. Originally, it was the “View”. Handle your business logic and domain modelling however you like and pass it to React to display it. This made it effortless to adopt because you didn’t have to change what you were doing too much. You could bring your own models and controller layer. React is still very much a library rather than a framework. This is its biggest strengths, but it’s also a weakness when it comes organisation.

React doesn’t define any conventions on where your components should go or how they should be organised within a larger system. This is a freedom the developer has to decide. This freedom can be terrifying for new developers. There is no right answer, so you get fragmentation of best practices.

I’ll show you two approaches to organising React components, this isn’t specific to just React and will work with many other component-based libraries and frameworks. There are tradeoffs with both approaches, as there always is, and it may not suit everyone’s taste, but it’s what I’ve found to be useful working on many different projects over the years. Let’s jump into the first approach.

The problem with organising by type

Organising components by type is a common approach to take and why wouldn’t it be? We’ve been doing it since React’s inception. Even the maintainers of React have recommended separation by containers and components. Ruby on Rails developers are familiar with the standard hierarchy and scaffolding that maps perfectly from filesystem to Model-View-Controller. It’s obvious where each type of file needs to go. Organising by type works well for small projects. With a few components, you’re not going to get lost, and it’s easy to keep track of everything. Let’s take a look at how we might organise files in a React app when organising by type.

How does it work?

The reasoning behind organising by type is that everything that’s similar should live in the same place. Your React components should live in a components folder. Tests, in a tests folder. CSS styles, in a styles folder and so on. Sometimes there might be some changes to this structure if you’re using CSS-in-JS solutions or opting for tests closer to the component than the top-level directory but, for the most part, this structure can be seen in many React projects. Once you have more than 10 components, things might start to get more challenging. At larger sizes, it can be overwhelming.

Why it can be problematic

The biggest challenges I’ve faced when working with structures like this become apparent as a project grows. In the beginning, it’s great. You know where everything goes, every component, container, stylesheet and test has its place. As time goes on and the project grows, it becomes more challenging to work with individual components.

Developer experience and scaling is impacted

Let’s say you want to edit a button component. Open the component’s file and start editing away. Then you need to edit your styles, so you also navigate to your styles folder, find the button and open that. Now the component is updated, the tests are broken and some stories need to be updated. You navigate to those respective folders and open tests/button.test.js and stories/button.story.jsx too. What happens when you now want to open up the components that consume the button and make changes to them too?

When organising components by type, I often find myself bouncing back and forward in different files in different places to get changes made. I don’t want to close certain files because I might need to navigate back to them again, so I just end up with a cluttered workspace with a multitude of tabs open in my editor. In this example it’s not so bad but as the level of nesting grows, it can become challenging to find what you need. At that point, it’s often easier to search for files and ignore the structure in day-to-day development completely.

What am I missing?

An issue arises when components don’t all have the same files associated with them. Your standard components might have stories, styles, tests and the component itself but what if it doesn’t? It’s not easy to figure out at a glance. Did you notice the screenshot I included is missing a test? Maybe, what if there were 10 components or 100? You have to rely on other tools or investigation to figure out the dependencies for your components. If a test is missing, it’s not obvious.

Where do I put it?

What happens when you decide there’s some component logic that only relates to your header component, and you want to break it out into an utils file? The current structure doesn’t allow for this. The obvious thing to do is create a new top-level folder called utils. So let’s do that. We’ve made a new utils/header.js file, but we’ve also made a commitment to where files go in the future. We’ve created a signal for other engineers who will continue to expand on this concept and maybe even break up existing components to meet this new structure. This exacerbates the problem I mentioned earlier, not all components will share the same dependencies and knowing this involves manual investigation. It’s clear where to put files when the folder already exists but it’s unclear what warrants a new folder’s creation.

Components are movable

Organising files by type makes it more awkward to move components within the project or to pull them out. You have to go through and find the dependencies for a component that live in very different places across the filesystem, update the dependencies and hope you didn’t miss anything. Your imports are often predictable but lengthy and a chore to change. It’s not a big deal as refactoring the location of components is unlikely to happen often but when it doesn’t, it can be error prone.

So what’s a better approach as a project scales?

Organising components by locality

How does it work?

Organising by locality is an extension of encapsulation. Everything that a component relies on lives as close to the component as possible. This makes it easy to see the dependencies of a React component because the named folder contains the component itself alongside tests, utils, stories and styles. The names chosen, include the component name, the type of file it is and the extension.

Why I like this folder structure for components

There are many ways to organise components in React and other component-based libraries. This one is one of my favourites because I find it the most flexible. It can start of simple and grow as your project grows. It’s easy to use and offers a nice developer experience.

It’s clear what’s missing

When organising by type, it’s not immediately obvious if there is a test or style associated with each component. When organising by locality, it’s obvious. If a component doesn’t have an associated test, stylesheet or story, looking in a single place tells us. Adding these files is easy too, it all happens in the same place.

Scaling is easy

Adding a new component is easy. Create a folder with the component name and add your supporting files. As your project grows, these component folders can begin to take on different shapes depending on requirements. A button component might start off being enough but eventually requires different components or styles for different purposes. You could extend this structure without breaking the core organisation principle. All the variants of the buttons are still buttons and have coupling with styles and tests, so they can all live within the same hierarchy.

This gives developers more flexibility when needed, a component can be as simple or complex as it needs to be while still following a consistent structure. If one component needs different stylesheets depending on use, it can have them and the complexity is contained within the component’s domain. If you need an utils file just for one component, you can add it to just that component’s folder without any obligation to keep adding utils for components that don’t need them.

Components are movable

As you project grows, these components can be moved around easily. If your supporting styles, and utils are imported using relative imports, it doesn’t matter where the component folder moves to. The references won’t change. Likewise, your stories and tests can import the files under test using relative imports too. There’s no need to follow paths throughout your codebase trying to corral the various spread out dependencies.

Avoiding index.js

In both approaches, I got rid of one of the most annoying issues, index.js. It’s common to find widespread usage of index.js in projects to clean up file paths when importing projects and to act as an entry point for a particular folder. In practice, this can be a pain. Navigating through definitions and landing on an index.js means another layer of indirection. You end up importing and exporting files from these files to make a nicer public interface for consuming components and there’s nothing worse than looking at your editor trying to find a file when everything is called index.js. This is also why both approaches include the component name as the prefix followed by the intent of the file and ending in an extension. This is more easily searchable across the codebase and helpful when editing multiple files to avoid confusion.

Extending this approach

It can be difficult to find the right structure for your project. There may be things you don’t like and that’s okay. Change it. Organising by locality can be combined with organisation by type when necessary too. This helps with certain frameworks like Next.js where you might want to keep your pages directory, business logic and components separate. It can be applied to atomic design philosophy where your components folder could contain atoms, molecules and organisms. Then within each of those divisions, lives the component folder.

Conclusion

Organising components by locality is my favourite approach so far. It’s flexible and scalable. It offers a nice developer experience and isn’t difficult to transition to. Organising by locality creates clear boundaries around components which can be useful when you simply want to transplant your components into its own component library. If it doesn’t work for you, expand upon it and combine it with what you need. Every team works differently and projects can benefit from different styles of organisation that better suit the teams that work on them. In the end, it doesn’t matter how you choose to organise your React app, as long as you choose something.

First Code Component in Framer Web

Seth Corker — Thu, 03 Dec 2020 18:42:23 +0000

Hi all 👋,

If you like creating prototypes with Framer Web and want to achieve more complex interactions, this is the tutorial for you! I've worked on this short tutorial series to help you understand code components in Framer Web. This is the beginning of that journey.

❓ What we'll make

Throughout the series, we'll be making some screens you might see in a mobile banking app. The code components we'll build together in this part is a line item and bar chart. We'll build these in code and then put them onto the canvas like any other component.

🔨 Why is it useful

Framer Web is a great prototyping tool but it can be even better when you know a little bit of code. I'll help you take the first step. If you've coded a little bit, this will be a breeze. If you're a professional web developer or have React knowledge then you'll see how you can leverage your existing skills in Framer Web.

We’ll cover the basics of a React component, styling your components in JSX and how to leverage default props all within the context of Framer Web. The skills you learn here are applicable to React apps too. You can take your prototypes from Framer Web into code and that’s just what we’ll be doing throughout the series.

🗺️ Where to go from here

The skills you learn here are applicable to Framer Web but they're also many of the same skills you'll need if you want to create React components. I even show you how to go beyond Framer Web and take your project into a separate code project. This makes handoff to other developers easy and will help you build better collaboration between design and engineering.

I hope you found this useful and can't wait to see what you create! If you're new to Framer Web, give it a shot. If you're a long time user, I hope this is useful for trying something new.

🙌 Thanks for reading and watching!

GROQ vs. GraphQL?

Seth Corker — Thu, 03 Dec 2020 12:17:57 +0000

Sanity CMS supports query language called GROQ but you can also query data with GraphQL.

This got me thinking, what does GROQ give me that GraphQL doesn't. I'm interested in hearing your thoughts if you've used one, the other or both! What's the deal with GROQ?

What's your experience of GROQ and is there a reason to use it over a plain GraphQL query?

ABCs for Web Developers

Seth Corker — Tue, 01 Dec 2020 20:31:25 +0000

For the holiday season I thought I'd do something a bit different. Why not make a ABCs website for web developers?

What is this?

In the style of alphabet learning books of childhood, ABCs for Web Developers has a little rhyme and web technology associated with it. Over the next 25 days I'll be adding a new letter to the website.

Disclaimer

This is a bit of fun, not to be taken too seriously. There are lots of great technologies that I could have chosen for each letter but I'm limiting it to just one. Let's see what happens next year, until then I hope you enjoy.

Stay up to date with the rest of the letters, I'll add one daily until the 26th of December.

Watch the videos or visit the link to see the original web version.

A is for Angular

View the web version of A

B is for Babel

View the web version of B

C is for CSS

View the web version of C

D is for div

View the web version of D

Check back daily for the next one in the series.

Animate Styled Components with Framer Motion!

Seth Corker — Mon, 30 Nov 2020 07:43:36 +0000

I love Framer Motion because it's a library that's easy to use and powerful. I've created page transitions within Next.js and cool interactions like tap to expand. It's a very versatile library for animation in React and it's not just limited to building from scratch.

If you're using a CSS-in-JS library then it might not be immediately obvious how to integrate Framer Motion smoothly but once you know, it's as easy as 🥧.

Watch this short tutorial on how you can add animations and gestures like drag, to an existing UI library built on top of styled-components.

The core concepts

Here's a quick reference to help you out!

Turning a styled-component into something animatable

Use the as prop and specify motion.div or another motion.<some html element> to start using Framer Motion for that component.

<MyComponent as={motion.div} animate={{ y: 100 }} />

Animating it's as easy as adding the animate, transition, and other props you're used to adding directly to motion elements.

Making your own styled-components and integrating with Framer Motion

Define your styled component but instead of passing an html element as the first argument, give it a motion element instead.

const MyCustomComponent = styled(motion.div)`
  width: 2rem;
  background-color: tomato;
`;

Need to add drag functionality? Simply pass in the prop when you use it!

<div>
  <MyCustomComponent drag />
  <MyCustomComponent animate={{ opacity: 1 }} />
</div>

It's as easy as that. If you use styled-components to build your React apps then I hope you this helps you develop rich experiences with animation and interactivity without the hassle. Framer Motion is my favourite library for tinkering with animations and it's versatile enough to be used with a variety of different frontend technology.

References

Want to create something cool in React95?
Check out Framer Motion for animating React components
Learn more cool animations you can achieve including animations on scroll

How it feels to write a web page from scratch in 2020

Seth Corker — Sun, 29 Nov 2020 16:39:04 +0000

In a world of build tools and web frameworks, it’s not often you just sit down and code a webpage from scratch. No CSS framework. No auto-prefixing. No webpack config or dependency manager. No intermediary steps involved. Not even a line of JavaScript. Just me, my editor, my browser and the raw materials of the modern web. It’s been a serene experience that feels unfamiliar in 2020.

I’m a software engineer living and working in London. In my daily work my primary tools for the web are React, Next.js, GraphQL and Emotion for CSS. In my personal projects, I often play around with different technologies like Gatsby, Svelte and whatever else looks interesting at the time. I don’t often get the chance to write plain HTML and CSS. It’s not that I avoid it but it just never seems to be part of my workflow like it once was. I decided to take a step back and start a project with the core building blocks of the web, it’s been a novel experience.

When you get used to something like React, it becomes comfortable, it becomes the de facto tool for the job. Need a new blog? Use Gatsby. Want a marketing site? I’ll use Next.js. Need styling for a quick admin interface? Take your pick of CSS frameworks and/or component libraries. There’s a plethora of choices, a tool for every job that all fits into the React ecosystem and more broadly, the ecosystem of the web. To ignore that for a moment, however brief, is a breath of fresh air. To forget all of it and go back to basics, to code like the early web, it’s liberating.

So, why did I do it? I wanted to try out variable fonts and I didn’t need any reactivity, I just wanted to tinker with a static webpage. That’s why I avoided Create React App. I avoided all of the tools I’ve relied on over the past 5 years and just did it. This is what, I discovered along the way and a few reasons why you might want to give it a go every now and then.

Hand crafted CSS

Before the explosion of JavaScript into the behemoth it is today, there were few things more contentious than CSS. A language that is loved and hated with equal measure. There have been many systems created to make CSS easier to wield like BEM, SMACSS and OOCSS. There are preprocessors that aim to add features and fix the flaws like LESS and SASS. Now with the rise of React, there are countless ways of including CSS in your app from simple imports to CSS-in-JS solutions.

I left this all behind to hand-craft some CSS. Here’s what I learned.

Dev tools are wondrous

Box Shadow editor in Chrome dev tools

Colour picker in Chrome dev tools

Working in the browser’s dev tools is great. The developer tools from Firefox, Chrome and Safari are excellent. The best part is that they just come with browser. There’s nothing to find, add and configure unless you really want to. CSS is one of the primitives of the web and dev tools can make working with it a dream. My favourite feature is the ability to live edit your CSS with workspaces. Changes made in dev tools are synced with your project on your filesystem. It’s almost like an evolution of Dreamweaver for the modern era. You can inspect gradients, create box shadows without trying to remember which order values should be in and all from within the browser. It’s the ultimate WYSIWYG, there’s no guessing what your page will look like - you’re editing it live, zero delay.

Vendor prefixes are becoming less relevant

One downside of editing your CSS by hand is the lack of auto-prefixing. With every year and every new release of browsers, this is becoming less relevant. Browser support in a much better place than it was a few years back and the majority of what you need to do is supported. Jumping through hoops to get a nice developer experience with modern tooling feel antiquated when a great solution already exists. It might not meet all the needs of browser compatibility out of the box, but the experience is great and the feedback, instantaneous.

Artisanal HTML

I’ve been writing React components for over 5 years now. Before that, I used to write a lot of HTML, a lot of CSS and a lot less JavaScript. In the past, there was often a templating language that generated HTML. Templates with Ruby on Rails, ASP.NET or Pug. There was never a need to write HTML by hand for the majority of products I’ve worked on. So what was it like?

Wait, how do I do this again?

It feels unfamiliar writing plain HTML again. Years of React has made me forget some of the differences between JSX and HTML. Writing class instead of className feels out of the ordinary. I had to delve into the recesses of my mind to remember the proper way to link a stylesheet; when you’re doing React, you’re often used to a transpile step and more likely to add CSS to the build chain. These little differences throw you off for a while as you re-acclimatise to that estranged markup language.

Separation of concerns

The most refreshing thing about writing HTML from scratch and CSS from scratch is the separation of concerns. I miss it. Writing markup in one file and how it looks in another, loosely coupled with class names is great. The product I work on professionally uses Emotion, which means styling is added directly to the element and is pulled into the head of the document on build. It’s useful in some circumstances and isn’t as noticeable when hidden away in reusable components but it’s always present. When parsing code, looking at the semantic structure isn’t as easy when styles are essentially inlined for the majority of elements. Your markup, styles and logic are smooshed into a Frankenstien’s monster that we call a React component. There’s also a gap between what you write and what’s produced, a class name is automatically generated for each element so tracing a style from a production build back to the source can be challenging.

A separate CSS file and HTML file make it easier to parse both files. It’s just more readable. It’s not necessarily the best method for a component based frontend but a lot of webpages, it works so well. There is some back and forward when inspecting classes in HTML and the implementation in CSS but it’s nothing that can’t be eased by using dev tools or a split editor.

Zero JS

I often don’t get a chance to just write a static web page, and if I do I often include JavaScript to add little enhancements here and there. As a daily React developer, my mind is constantly aware of where interactivity could be added. There’s often a need for interactivity and JS is the goto tool. For my experiment, I didn’t write a line of JavaScript. The most complex thing on the page is some stateless animations which are achieved with CSS. It’s useful to remember that CSS is a really powerful language. It may be difficult to master but once you have a good understanding of it, you can make web pages more interactive and feature rich. You can go a long way before JS is necessary.

The most fun from not using CSS is the constraints it adds. Constraints make the most interesting decisions, they force you to think with the tools you have and push the boundaries further than you normally would. Setting myself an artificial constraint of not using JS was fun because it forced me to use CSS for animations and focus on the look and feel rather than functionality. You’re not tempted to add additional libraries because you can’t. You’re not attempting to manage state within a component because there is little to no state. Constraints give you a framework to work within, to the push the limits of and to embrace.

You should try it

I don’t often get the chance to write HTML, CSS or plain JS in day to day life and I don’t think I’m alone. In my job, HTML is rarely written by hand because external requirements often mean that markup is generated by data. It’s generated by a CMS or piped into React components so it can be made interactive. There’s an expectation of compatibility because you’re serving a large audience with different devices and it has to work consistently across all of them. This results in CSS being generated rather than hand crafted. It’s safer. It’s more compatible. It’s more scalable. Your styles are auto-prefixed, to work with multiple browsers, deduped and minified for faster loading. JavaScript is often the result of a pipeline that starts with TypeScript and/or JSX. The source code makes its way towards something safer, more compatible and easier to maintain . It’s very rare to write JavaScript from scratch with no changes between the source we write and the bundle the client receives.

Should you stop using modern tooling, throw caution to the wind and code like it’s 1999? Probably not.

Modern tooling gives us superpowers for manipulating the raw elements that make up the web but it’s a layer of abstraction. That’s not a bad thing. The modern approach to web development takes some of the tedium out of frontend development. It’s allowed us to move faster than ever before and create experiences which are feature rich and delightful to use on more devices than ever before. Having said this, sometimes it’s nice to have a break. Everything is a tradeoff and sometimes it’s nice to revaluate. It’s a breath of fresh air to just sit down and whip up a simple webpage without ever waiting for a build step. Never installing a package via npm. Having full control over the output.

It takes away certain decisions like which package manager to use, how to bundle assets, which CSS-in-JS method is the best. It adds constraints. You’re not thinking of what package could solve a problem, you’re tinkering directly with the web and working with its quirks and limitations. It’s not bad or good, it’s just different. It harks back to times where we had different problems and different concerns.

I challenge you to go out of your comfort zone and give it a go. See what it’s like to code from scratch in 2021, you might learn something new or gain an appreciation for how far we’ve come.

If you enjoyed this and would like to read more articles like this as soon as they come out, check out my blog.

Page Transitions in Next.js with Framer Motion

Seth Corker — Mon, 16 Nov 2020 09:28:45 +0000

What we’re building

I’ll help you start adding more delight to your Next.js app (or other React apps) with transitions between pages. We’re going to use the AnimateSharedLayout component from the Framer Motion API to make pages blend between each other seamlessly.

See the demo

Why?

The web is a powerful platform that has a lot to offer. By adding seamless transitions between webpages, we begin to shift towards a more native feeling UI which delights user’s and brings your website or web app into a class of its own.

Why Next.js?

Next.js is a popular framework for building web apps and for good reason. It builds upon React to offer a great developer experience. One of the most obvious features we’re leveraging is the built in routing. We’re going to build our transitions upon what’s already built in to Next. If you’d like to apply this technique to an existing project, it should be easy to do so.

Why Framer Motion?

Framer motion is an easy-to-use library which can achieve our desired transition effect quickly and is powerful. It gives us the ability to mix a variety of different animation types and can be a good foundation for making your pages even more delightful for users. When combined with Next.js, it offers a rich user experience and developer experience that I love.

What we need to start animating

The two key ingredients are Next.js and Framer Motion. If you’re not using Next.js and instead are using another React router library, you’ll still get and idea of how this could fit in. It’s not exclusive to Next.js or Framer Motion, these are just two of my favourites that work well together. Feel free to mix and match.

About the project

The project contains two pages which we will animate between. The elements that are not shared between pages will animate in while the elements that are shared will animate between pages instead.

Page transition tutorial

Identify the elements that stay the same

For our example we’re going to animate between two pages. The first page is a simple landing page with an image, a title, a paragraph and a button. Clicking on the button will navigate to our other page. A features page with the same title and image but it’s surrounded but other icons and feature descriptions.

We can’t transition between all of these elements because they aren’t all on both pages. The title and image are the same so these are the most obvious candidates. The button looks like it could work but the text content differs, it’s possible with a bit of work to create something that looks passable but I’ll skip the layout transition for this element.

Adding the AnimateSharedLayout to `_app`

The first step is to set and forget our AnimateSharedLayout component. The component enables us to animate layout changes between different components and tell Framer which elements are shared and therefore should transition to the new state. To set this up, inside _app we’ll import it:

import { AnimateSharedLayout } from "framer-motion"; then wrap our Component.

Our _app looks like this. I’m using the Bulma CSS library and SASS along with FontAwesome icons. The Component prop in the context of MyApp is the whatever page we are currently on. In Next.js, this acts as a layout which is used across our pages. It’s especially useful for our purposes because we want to be able to animate seamlessly between all the pages in our app.

import "../styles/theme.sass"
import "@fortawesome/fontawesome-free/css/all.css"
import { AnimateSharedLayout } from "framer-motion"

function MyApp({ Component, pageProps }) {
  return (
    <AnimateSharedLayout>
      <Component {...pageProps} />
    </AnimateSharedLayout>
  )
}

export default MyApp

We’ve added AnimateSharedLayout but nothing has changed, let’s turn our title and image elements into motion components.

Using layoutId to setup the transitions

On our first page, index.js, let’s import the motion component from framer-motion, import { motion } from "framer-motion";. This component allows us to turn normal html elements into animatable components. Usually, we’d add the animate prop, so we can define the animation but the only thing we need for the transition is the layoutId prop. It’s a string which will be unique across our app.

Our title will go from this:

<h1 className="title has-text-weight-bold is-1 is-size-2-mobile is-spaced">
  The only Todo App you'll ever need
</h1>

To this:

<motion.h1
  className="title has-text-weight-bold is-1 is-size-2-mobile is-spaced"
  layoutId="title"
>
  The only Todo App you'll ever need
</motion.h1>

We’ll do the same with the figure element that wraps our image.

<motion.figure className="image" layoutId="image">
  <Image src="/assets/task.png" layout="responsive" width={780} height={501} />
</motion.figure>

Let’s replace the matching elements on our features.js page too. When the page transitions from / to /features, framer will treat the elements on one page with the elements on the second page as the same if they share an identical layoutId.

Try it out, and we’ll see the title and image moves smoothly across the screen.

Completing the look with motion

The approach is very cool because it allows us to go forward and back between pages and the transition works as expected. This is a good starting point, and we’ve achieved the core effect but I think it needs a bit more. Let’s finish the look off by utilising Framer Motion to add an intro animation to elements that aren’t shared across pages.

For elements that are unique to a page, we’ll fade them in.

Here’s an example of the subtitle on the index page:

<motion.p
  className="subtitle"
  initial={{ opacity: 0 }}
  animate={{ opacity: 1 }}
  transition={{ delay: 0.2 }}
>

This is a straightforward fade in animation that starts with an opacity of zero and animates to an opacity of 1 after a delay of 200ms.

But what happens when the user first visits a page? Can we animate all elements in? With Framer Motion, yes we can. We can add the animate prop to have an intro animation that will play when the user opens the page and this won’t affect the transition to the next page.

Here’s our animation, a fade in with a slight scale up effect

<motion.h1
  initial={{ scale: 0.8, opacity: 0 }}
  animate={{ scale: 1, opacity: 1 }}
  className="title has-text-weight-bold is-1 is-size-2-mobile is-spaced"
  layoutId="title"
>

Let’s see the final product:

Where to now?

We’ve created some cool effects that really breath life into the app with pretty minimal effort for the developer. Framer Motion allows us to create these complex layout animations easily and without compromise. It’s easy to tweak how pages animate in or out as well as the transition between pages. I hope you’ve learned something new and will apply some of these techniques to your projects.

The web is a platform that can do so much more than static webpages. As a platform for rich user experience, we have the opportunity to craft more imaginative user interfaces that really react to the user’s actions and exceed expectations. Animation through page transitions is one of the tools we have available to enrich experiences, and they’re easy with Next.js and Framer Motion.

Resources

See the demo
Read more about how this works and more uses cases, Framer Motion API: AnimateSharedLayout documentation
Find the completed project repo on GitHub
Follow along and make your own adjustments with my starter project repo on GitHub.

If you enjoyed this and would like to learn more about Framer Motion or web development in React, check out my Benevolent Bytes blog. I also have a YouTube channel, Coding with Seth, where I make video tutorials to help you craft better web experiences

How to animate scroll position in React

Seth Corker — Mon, 15 Jun 2020 08:53:46 +0000

What we’re animating in React

I’ll walk you through how I created the following animation with Framer Motion and React. It’s shows an envelope which as you scroll down, a letter slides out before sliding down over the envelope.

See the letter animation example in Framer Motion.

If the iframe above isn’t working, you can also see the letter animation example in Framer Motion here.We’re creating a simple effect where a letter looks like it’s being drawn from an envelope. The animation happens when scrolling up or down.

If you’re looking for some more guides with examples of how to use Framer Motion, take a look at how you can create a spinner loading animation or a tap to expand animation

How to control animations on scroll with `useViewportScroll`

The useViewportScroll hook is one of my favourite features of Framer Motion. It allows us to control animations based on the scroll position.The way achieve this simple letter opening animation is by mapping time to the scroll position so when the scrollbar is at the top of the page, our animation is at the first frame.When the scrollbar is at the bottom of the page, our animation is at the last frame. Scrolling back up the page will reverse the animation.This is a simple effect but it’s possible to create complex animations and base them entirely on where the X and Y scroll position is.

How do we use it?

For our letter example, we are basing the animation on just the Y position so we just use the hook like so:

const { scrollYProgress } = useViewportScroll()

This hook returns scrollY, scrollX, scrollYProgress and scrollXProgress. I chose not to use scrollY because I don’t really care about how many pixels we’ve scrolled down the page.I just want to know where we are in the animation from 0 to 100% complete that’s why I use scrollYProgress which gives us a value between 0 and 1, then we transform that however we need to with the useTransform hook below.

What `useTransform` does and how to use it

The useTransform hook is useful for transforming one value to another. What does this mean?It allows us to take our scrollYProgress which is between 0 and 1 and get a different set of values like so:

const { scrollYProgress } = useViewportScroll()
const scaleAnim = useTransform(scrollYProgress, [0, 0.5, 1], [1, 1, 1.5])
const yPosAnim = useTransform(scrollYProgress, [0, 0.4, 1], [0, -250, -100])

What you’ll notice is that the first argument is scrollYProgress, this is what we want to transform.The second argument is a series of numbers that we want to transform between. We know scrollYProgress can be 0 at the minimum (we haven’t scrolled down the page at all) and 1 at the maximum (we reached the bottom of the page).So why do we use three values? Well, it’s because the animation we want to create has three distinct keyframes.So if look at his example for our Y position, useTransform(scrollYProgress, [0, 0.4, 1], [0, -250, -100]), we are saying at the beginning Y position 0 should transform to 0. No change.When we are 40% down the page (0.4), the Y position should be -250px upwards. Finally, when we reach the end of the page, the Y position should be at -100px.

Tip for using the `useTransform` hook

When you use the useTransform hook this way, make sure you have the same number of input values as output values so if you need three keyframes then make sure you use two arrays of values as the second and third arguments.

Breakdown of the letter animation example

The structure of the example

Let’s walk through the example, I’ll breakdown the steps used to create letter animation and why certain decisions were made.I’m using CSS-in-JS to keep the style as close to the code as possible, you don’t have to do this and Framer Motion doesn’t demand you do it either.It’s possible to use CSS modules, plain old CSS or a combination of all the above.

Laying out the scene

First, I created some high level components to match the mental model of what we’re trying to achieve. An envelope with a letter inside it.

<div style={letterSceneStyle}>
  <Envelope>
    <Letter />
  </Envelope>
</div>

The style for the container div is to give us enough space to scroll. A larger height will make the animation slower because the user has to scroll more for it to reach 100%. I chose a comfortable speed/viewport size of 200vh.

const letterSceneStyle = {
  height: "200vh",
}

Creating the envelope

Now we get into how the animation works. The only prop the envelope accepts is children, in our case. This is the <Letter />.A benefit of having the letter within the envelope is any animation we apply to the envelope will affect the letter.

function Envelope({ children }) {
  const [ffLayer, setFfLayer] = useState(0)
  const { scrollYProgress } = useViewportScroll()
  const scaleAnim = useTransform(scrollYProgress, [0, 0.5, 1], [1, 1.2, 0.8])
  const yPosAnim = useTransform(scrollYProgress, [0, 0.5, 1], [0, 100, 200])
  const zRotAnim = useTransform(scrollYProgress, [0, 0.5, 1], [0, 3, 0])
  scrollYProgress.onChange(x => {
    setFfLayer(x > 0.4 ? -1 : 0)
  })
  return (
    <motion.div
      style={{
        ...envelopeStyle,
        scale: scaleAnim,
        y: yPosAnim,
        rotateZ: zRotAnim,
      }}
    >
      {children}
      <div style={{ ...frontfaceStyle, zIndex: ffLayer }}>
        <button onClick={() => window.scrollTo(0, 1500)}>Open Me</button>
      </div>
    </motion.div>
  )
}

We make extensive use of the useTransform hook to transform scrollYProgress into the values we need.In the case of scaleAnim, we want it to start at 100% scale then get larger halfway through the animation and small at the end.We also move the envelope down the screen with yPosAnim and perform a slight tilt with zRotAnim. To hook up the animation, we simply use a <motion.div/> component and set the style prop.If any of the values change, we’ll see a smooth animation thanks to Framer Motion. There are a few other things we need to do to achieve the effect which isn’t immediately obvious.

What’s the `ffLayer` state?

The effect I wanted to achieve is a letter being pulled out of an envelope so ffLayer is to keep track of the front face of the envelope. The reason we need this is so that after the letter is ‘pulled’ out, it can then slide down over the envelope.The scrollYProgress is a motion value so we can add an onChange handler to trigger the state change 50% though the animation.Once we are half-way though, we change the z-index of the envelope front face so it will be behind the letter.

How does the button scroll cause a smooth scroll?

As a way to showcase the animation, I added <button onClick={() => window.scrollTo(0, 1500)}>Open Me</button> to the envelope to allow for a smooth scroll.This works by scrolling the page down 1500px. Just this alone won’t give us the effect we need. The next step is to make sure we add the following CSS.

html {
  scroll-behavior: smooth;
}

Creating the letter

The letter animation makes use of the same hooks we’re familiar with from before. This time we animate the scale and the Y position.

function Letter() {
  const { scrollYProgress } = useViewportScroll()
  const scaleAnim = useTransform(scrollYProgress, [0, 0.5, 1], [1, 1, 1.5])
  const yPosAnim = useTransform(scrollYProgress, [0, 0.4, 1], [0, -250, -100])
  return (
    <motion.div
      style={{
        ...letterStyle,
        scale: scaleAnim,
        y: yPosAnim,
      }}
    >
      {/* The contents of the letter goes here */}
    </motion.div>
  )
}

Setup styles with CSS-in-JS

The most important thing to achieve the envelope and letter effect are some basic styles before we apply the animation.

Envelope Styles

We set a defined with and height of the envelope and position it on the page. Notice, we always want to see the animation take place in the center of the screen regardless of where the user has scrolled to so we use position: fixed.The front face style is very simple too. It just needs to be the same size as the envelope and have a backgroundColor so it hides the letter while still inside the envelope.

const envelopeStyle = {
  width: "28rem",
  height: "15rem",
  scale: 1,
  position: "fixed",
  top: "10rem",
  left: "calc(50% - 14rem)",
  boxShadow: `rgba(0, 0, 0, 0.5) 0px 0px 150px 10px`,
}

const frontfaceStyle = {
  width: "100%",
  height: "100%",
  backgroundColor: "#debda1",
  position: "absolute",
  left: 0,
  top: 0,
  display: "flex",
  justifyContent: "center",
  alignItems: "center",
}

Letter style

The only important properties of the letter is the dimensions and position.The position is absolute so we can position it within the envelope. The size is also slightly smaller so it looks as though the letter fits within the envelope.

const letterStyle = {
  width: "calc(100% - 1rem)",
  height: "calc(100% - 1rem)",
  top: "0.5rem",
  left: "0.5rem",
  backgroundColor: "#f8efd5",
  overflow: "hidden",
  padding: "1rem",
  boxSizing: "border-box",
  position: "absolute",
}

Where to go from here

Although it’s a silly example, a letter coming out of an envelope, this is a good example to see how to take advantage of the capabilities Framer Motion offers.If you want a more practical application of useViewportScroll, you could do one of the following:

Show a progress bar of how far through someone is reading a webpage.
Highlight headings in a sidebar depending on if they are reading that section or not.
Have elements appear and disappear easily on scroll

The possibilities are boundless, think of some cool ways you can orchestrate animations based on the scroll position.

Resources

What is Blitz.js?

Seth Corker — Mon, 25 May 2020 08:36:39 +0000

What is Blitz.js?

Blitz.js is a new framework that's built on Next.js.It's positioned as a Rails-like framework, it's monolithic and focused on developer productivity while using the modern JavaScript tech you're used to.Although new, I'm watching Blitz.js as I believe it has great potential to refresh JS fullstack development, it looks like a great way to dive in without the hassle of decision fatigue and complicated configuration.

Why does Blitz.js exist?

Web development has evolved a lot over the past decade.There are more libraries and frameworks for JavaScript than ever before but there's been a trend to opt for smaller libraries, decoupling and microservices.These all have benefits but one of the tradeoffs is productivity. Blitz.js is a reaction to this, it want's to bring back the simplicity of the web with modern tooling.It takes some of the powerful tools you use today and packages them up into a nice and easy to work with bundle.

Simplicity

I enjoy the modern web. There's many ways to get things done the way you need to.You can choose the right libraries for your particular project and requirements.One critique of this however, is decision fatigue. With so many options, what do you choose?When starting a new project you will constantly make decisions about each and every library, tool and weight their strengths and weaknesses.

Should you make a SPA or use SSR?
Will you use REST or GraphQL?
How will you manage your state? Redux? MobX?
What view layer do you want to use, React, Vue or maybe Svelte?
How will the project be built? Webpack? Rollup?
Which features of JS do I want to use and which babel plugins do I need to add?

These decisions are before you've written a line of actual application code, it's all setup.It's no wonder beginners can get overwhelmed and web veterans have can get disenchanted with the direction modern web development is going.Tools like Create React App are a reaction to this just like Blitz.js. The benefit is simplicity while maintaining the right to pick and choose.

Small companies

A lot of existing libraries are created for large companies that have different problems to smaller companies.Sometimes it doesn't make sense to adopt certain technologies because they just don't solve the problems small companies are trying to solve.Technologies like GraphQL and frameworks like Relay or Apollo fit together to solve problems which you might only run into at large scale.Blitz.js looks to be your-go to tool until you need to scale.Even then, it's built on other technologies that are proven at scale so the leap might not even be that great.It's a foundation that grows with your needs when you need to grow.

Why am I excited?

The good old days of web development

I started my career as a web developer redesigning and maintaining websites.During the early days I did everything by hand. The HTML was handcrafted, so was the CSS.What little JS which was added was mainly for a sticky header or some mobile optimizations.Once I had a version which was ready to deploy, I'd connect to the server over FTP and copy the files over.Where they simpler times? Probably. Was I more productive than I am today, not really.It may have been simpler but there was a lot of intensive processes around the code.Adding a header and footer to every page was manual, the changes to would require a massive find and replace across every HTML file.I never knew about source control so manual backups had to take place after every change.Over time, I evolved my process and new tools came out to make it easier to achieve.Copy and pasting header HTML was replaced with templating and a build step.I traded some additional complexity for developer productivity.Over time I integrated Gulp and Bower to ease minification, browser compatibility compilation of SCSS.Why am I telling you this? Everything in programming is a tradeoff and you need to find the right tradeoffs for the things you're building.I evolved over time as a developer and my tooling evolved too.Blitz.js looks like a way to bring back the simplicity you remember having with modern tools and the benefits that come with them.

My first fullstack experience

My first foray into fullstack development was Ruby on Rails.The reason I chose it despite not knowing Ruby at the time was developer productivity.I needed to create something I had never done before, I needed a new approach because my cobbled together web tools only took me so far and I'd never worked with databases, an API or CRUD outside of the classroom.Despite the odds stacked against me, I managed to learn and be productive with Rails.It was batteries included and I owe it a lot.It was flexible enough to allow you to get stuff done and opinionated enough that made it easy to figure out the right way to do it.

This was a big contrast to my next job where React powered the frontend, the backend was a RESTful API with no ORM.There were benefits but there were also times I missed the simplicity of Rails.I thought of going back for side projects but I'm too invested in the JS ecosystem, that's where I'm most productive and I don't want to leave it behind. Blitz.js might be the best of both worlds.A different take on Rails for JS. It's Rails but with React built in.

Why does Blitz.js have a future?

The JS ecosystem is vast and powerful, there is great tooling and libraries available to suit almost any need but the challenge comes in choosing these tools, configuring them correctly and combining them while being productive.Blitz.js does this work for you, the tools exist and they've been configured for you.What I think gives Blitz.js a good future is that it is built on what already exists.It leverages other ecosystems to thrive.

Next.js

Next.js is a powerful framework in its own right. By leveraging this, Blitz.js can build on top of this solid foundation and get TypeScript support, routing, code splitting and more for free.As Next.js evolves, Blitz.js can too.

Prisma 2

Blitz.js piggybacks off the work done by Prisma. Rails had a great ORM which I liked a lot, Prisma is step above that which allows for more flexible data modelling and is setup to work well with TypeScript.

CLI

My favorite feature of Rails is the CLI scaffolding.As a beginner to fullstack development, Rails made it easy to generate everything you needed to get an entire working MVC setup.With a single command a model would be created along with a controller and all the CRUD views you desired. The CLI is what brings everything Blitz.js has to offer, together in one easy to use place.

Community evolution

Blitz.js has a manifesto which defines one of the most important tenants, "Community over Code".This is a simple idea but it's powerful, it sets the stage for a constructive community that learns from other communities rather than competing with them.Part of this commitment includes some transparent development practices, there already exists an RFC for the Blitz App architecture.This means you can have a say in how Blitz.js evolves and what choices should be made.

Is it ready for production?

No. Blitz.js still lacks maturity. It's early days so expect the APIs to change a lot.The documentation is limited but if you're brave though, Blitz.js utilizes existing tech so much that you'll probably be able to make something production ready with some extra time and effort.Nevertheless, I'm excited to see Blitz.js grow and evolve - I hope it can be the Rails for JS developers.

Resources

If you're interested in finding out more, take a look at some of the official places down below.

Illustrations provided by ManyPixels

Check out my blog, Benevolent Bytes for more articles on web development and to read What is Blitz.js.

For more about web development, follow me, Seth Corker (@Darth_Knoppix) on Twitter.

React devs, why did you start using React?

Seth Corker — Wed, 15 Apr 2020 10:53:33 +0000

I started using React over 4 years ago because I was interviewing for a job where I would be using it for all new projects. Up until then, I'd mainly used jQuery, Ember and plain old JavaScript.

Today, I still use React and I still enjoy it over the cumbersome mess of trying to build interactive apps with jQuery. I remember hours of frustration finding the root of bugs caused by manually keeping track of UI on the page.

It felt like banging my head against a brick wall, hoping to break through.

As a developer using React today, why did you start using it and what problem did React solve for you?

What's the biggest tech-stack change you've had?

Seth Corker — Sat, 11 Apr 2020 08:31:18 +0000

For the past few years, I've been using C# and ASP.NET professionally. I got used to the way it felt. I became comfortable with the tools and the libraries to use in each situation. I invested in the ecosystem to learn more and be better at my job.

A few months ago, I changed jobs. With a new job came a new tech-stack and it's wild. Today I'm using Python and maintaining a Django app. I haven't used Python since high school and I've never used it professionally until now. If you're familiar with both languages, you may know how different they are.

Python is a joy to read compared with C# code. There are things I miss and gaps in knowledge where Python has evolved over the years. It's new and exciting, I feel like the change has helped inspire me again and take me out of my comfort zone.

What's the biggest tech-stack change in your career and what did you gain from it?

Making Magic in Framer Motion 2

Seth Corker — Sat, 28 Mar 2020 18:12:15 +0000

This article has been updated to reflect API changes in Framer Motion 2.0.x Beta

Framer Motion is my go-to animation library for React. Matt Perry, the creator of the library and its predecessor Pose, has been tweeting about version 2 (still in beta at the time of writing) so I decided to check it out. It has some great new features I can't wait to use when it's released. Until then, let's take a look at one of my favourites - AnimateSharedLayout.

An animation made with Framer Motion using the AnimateSharedLayout component (previously MagicMotion)

What is AnimateSharedLayout?

Framer Motion is introducing a new component, <AnimateSharedLayout />. It allows for animating between components easily. Matt Perry's tweet illustrates a great usage of it here. The code is easy to understand and doesn't require a lot of setup to achieve.

Matt Perry

@mattgperry

🎩🐇In @framer Motion 2, a component can be given a magicId. When a new @reactjs component with the same magicId is added, it will appear to animate from the old one.

It makes stuff like this underline animation as simple as a boolean. Here's the code: codesandbox.io/s/framer-motio…

14:08 PM - 27 Mar 2020

69 518

The magic fits all with a few lines of code!

import React, { useState } from "react";
import { motion, AnimateSharedLayout } from "framer-motion";

export default function App() {
  const [selected, setSelected] = useState(0);

  return (
    <MagicMotion>
      <ol>
        {screens.map(({ title, color }, i) => (
          <motion.li
            magic
            key={i}
            className={`title ${i === selected && "selected"}`}
            style={{ color: i === selected ? color : "#333" }}
            onClick={() => setSelected(i)}
          >
            {i === selected && (
              <motion.div
                magicId="underline"
                className="underline"
                style={{ backgroundColor: color }}
              />
            )}
            {title}
          </motion.li>
        ))}
      </ol>
    </MagicMotion>
  );
}

Code sample from the Magic Motion underline menu demo

Wrap the animation in MagicMotion (now AnimateSharedLayout) and assign a magicId (now layoutId) prop to the components you want to animate between. So let's jump into another example and I'll break it down.

Experimenting with AnimateSharedLayout in Framer Motion

I decided to get a better idea of how this works and see what it can do by making my own experiment. The codesandbox is below to play around with. Click on the dates to show an expanded view.

Calendar animation codesandbox shown in the title card animation

In version 1, this would require a bit more setup to get right and we would be limited to a single component to perform the animation. This new approach gives developers more flexibility as it allows for different components to be used. The transition can then be linked together with a global identifier.

How does it work?

Two components make up the core of the interaction, <ExpandedCard/> and <CompactCard/> they both contain <motion.div/> components with the same layoutId prop set to expandable-card. Let's take a look at the components in their entirety.

function ExpandedCard({ children, onCollapse }) {
  return (
    <>
      <motion.div
        className="card expanded"
        layoutId="expandable-card"
        onClick={onCollapse}
      >
        {children}
      </motion.div>
      <motion.p
        className="card expanded secondary"
        onClick={onCollapse}
        transition={{ delay: 0.3 }}
        initial={{ opacity: 0, top: "6rem" }}
        animate={{ opacity: 1, top: "3rem" }}
      >
        Today is clear
      </motion.p>
    </>
  );
}

function CompactCard({ children, onExpand, disabled }) {
  return (
    <motion.div
      className="card compact"
      layoutId="expandable-card"
      onClick={disabled ? undefined : onExpand}
    >
      {children}
    </motion.div>
  );
}

Code sample from a Framer Motion experiment

The CSS for the two components defines the two states we want to animate between. The expanded card also contains some more information but we animate this separately so it doesn't just appear, instead, it slides in from the bottom.

Transitioning between the two components is as easy as wrapping them in a <AnimateSharedLayout /> component and conditionally rendering the one you want to show. The transition will be handled automgically like so.

<AnimateSharedLayout>
  {isExpanded ? (
    <ExpandedCard onCollapse={collapseDate} day={day}>
      <Content day={day} disabled={disabled} />
    </ExpandedCard>
  ) : (
    <CompactCard onExpand={expandDate} disabled={disabled} day={day}>
      <Content day={day} disabled={disabled} />
    </CompactCard>
  )}
</AnimateSharedLayout>

We store in state whether the component is expanded or collapsed and render either the <ExpandedCard/> or <CompactCard/> respectively. When the component which is currently rendering changes, the layoutId ensures a transition happens between them. The key properties which are changing in the experiment are the corner radius, position, size and background colour.

.expanded {
  width: 10rem;
  height: 10rem;
  background-color: navy;
  position: relative;
  left: -100%;
  top: 150%;
}

.compact {
  width: 3rem;
  height: 3rem;
  padding: 0.5rem;
  border-radius: 1.5rem;
}

The expanded class is re-positioned and enlarged. The shape changes from a circle to a square with moderately rounded corners and from white to navy blue. There is also another trick we use to ensure the date within the card component animates too.

The <Content /> component displays the day which changes colour depending on whether it is in a disabled, collapsed or expanded state. To ensure the transition happens, we assign a layoutId so even though we render different it in two different places, within a <ExpandedCard/> or a <CompactCard/>, framer-motion can handle the transition smoothly.

function Content({ day, disabled }) {
  return (
    <motion.h1
      className="title"
      layoutId="title"
      style={{ opacity: disabled ? 0.2 : 1 }}
    >
      {day}
    </motion.h1>
  );
}

The Content React component

The disabled state is shown here using an inline style but CSS classes handle the expand and collapse states.

.title {
  color: navy;
  font-weight: 800;
  margin: 0;
}

.expanded .title {
  font-size: 5em;
  color: white;
}

.compact .title {
  font-size: 1.5em;
}

CSS for the Content component

Framer Motion handles the colour transition and size change without any additional changes. AnimateSharedLayout is a great addition to this already powerful animation library. It makes complex animations much simpler to implement in React and should allow more fluid transitions on the web which we are usually more accustomed to on native platforms. I hope this has whetted your appetite. If it has, take a look at how to get access to the beta version and start hacking.

How to use the beta version of framer-motion library

At the time of writing, 2.0.0-beta.31 is the latest version. (The article has been updated to work with beat 42)

Viewing the version history of framer-motion on npm

You can specify the version you'd like to use in your package.json like so and start hacking.

{
  "name": "using-framer-motion-beta",
  "version": "1.0.0",
  "dependencies": {
    "react": "16.12.0",
    "react-dom": "16.12.0",
    "react-scripts": "3.0.1",
    "framer-motion": "2.0.0-beta.31"
  }
}

Should I use it?

Framer Motion version 2 is still in beta, although it seems pretty stable it should be used with caution. The API is unlikely to change but don't go building something meant for production right away. I haven't encountered anything unexpected yet but I've only played around with the beta in a limited capacity. If you're interested in playing around with it right now and don't mind the lack of documentation then go ahead. Changes are likely to be minor between now and release and it's great to see what it's capable of right now. If you're looking for stability, stick with version 1 for now and wait for the official release.

If you'd like to delve into more Framer Motion experiments, take a look at these:

Forem: Seth Corker

How to organise React components

Why React is great and why React is terrible

The problem with organising by type

How does it work?

Why it can be problematic

Developer experience and scaling is impacted

What am I missing?

Where do I put it?

Components are movable

Organising components by locality

How does it work?

Why I like this folder structure for components

It’s clear what’s missing

Scaling is easy

Components are movable

Avoiding index.js

Extending this approach

Conclusion

First Code Component in Framer Web

❓ What we'll make

🔨 Why is it useful

🗺️ Where to go from here

GROQ vs. GraphQL?

ABCs for Web Developers

What is this?

Disclaimer

A is for Angular

B is for Babel

C is for CSS

D is for div

Animate Styled Components with Framer Motion!

The core concepts

Turning a styled-component into something animatable

Making your own styled-components and integrating with Framer Motion

References

How it feels to write a web page from scratch in 2020

Hand crafted CSS

Dev tools are wondrous

Vendor prefixes are becoming less relevant

Artisanal HTML

Wait, how do I do this again?

Separation of concerns

Zero JS

You should try it

Page Transitions in Next.js with Framer Motion

What we’re building

Why?

Why Next.js?

Why Framer Motion?

What we need to start animating

About the project

Page transition tutorial

Identify the elements that stay the same

Adding the AnimateSharedLayout to _app

Using layoutId to setup the transitions

Completing the look with motion

Where to now?

Resources

How to animate scroll position in React

What we’re animating in React

How to control animations on scroll with useViewportScroll

How do we use it?

What useTransform does and how to use it

Tip for using the useTransform hook

Breakdown of the letter animation example

The structure of the example

Laying out the scene

Creating the envelope

What’s the ffLayer state?

How does the button scroll cause a smooth scroll?

Creating the letter

Setup styles with CSS-in-JS

Envelope Styles

Letter style

Where to go from here

Resources

What is Blitz.js?

What is Blitz.js?

Why does Blitz.js exist?

Adding the AnimateSharedLayout to `_app`

How to control animations on scroll with `useViewportScroll`

What `useTransform` does and how to use it

Tip for using the `useTransform` hook

What’s the `ffLayer` state?