Swizec Teller

A few days ago Kiran B sent me a challenge via Twitter DM: How can I make a drilldown piechart?

Here’s a fun problem for ya: How do you get the CSS from a rendered React component? Right-click, inspect element, see it in dev tools. What about programmatically?

Markdown is all the rage these days. A simple text format for rich documents, you see it everywhere from GitHub issues to Slack messages.

The other day I was dealing with some laggy UI on a project and discovered React.memo as a way of fixing it. I don’t know how long React.memo has been a thing but it’s new to me and it’s amazing.

This is a story full of wonderful new possibilities, beautiful codey things, and components clean as the mountain air. All thanks to custom react hooks.

I watched Ryan's talk 90% cleaner with hooks last night, Dan's and Sophie's talk announcing hooks this morning, read all the docs, and watched Twitter like a hawk. Hours of research condensed into the next 200 words because I love you.

A sample video from my upcoming course on #reactjs and #d3js

Playing around with ReactVR, part of research for my new React + D3 book and course.

Tweaking our main component so that it saves stuff to localstorage was cool and all, but we can do better: A middleware approach that ties into our state library.

Need to preserve some user state across sessions? Here's a quick and dirty way that works really well. Dump the important parts of your data store to localstorage on every change.

How should you think about persisting your state? What happens when a user refreshes the page? What if they want to come back a year later and continue where they left off?

We've tried 8 different libraries. There's many more out there. What's the point? Are they really THAT different? Nah. They all do the same things in largely the same ways. Pick the one that strikes your fancy best.

Constate, what a neat little state management library. Code compact, state immutable, everything neatly organized. Love it

A conceptually fascinating library, Govern gives you state management built from React-like components that return state objects instead of JSX.

Bey is a new state management library that takes the best concepts from many worlds. Really cool

David K. Piano's XState is a brilliant idea: A library that helps you reason about your state as actual finite state machines AND EVEN DRAWS THEM OUT.

Unstated, state so simple it goes without saying. It really does. This might be the simplest easiest to grok solution I've ever seen.

mobx-state-tree is amazin!. Fixes just about every I ever hadwith building large scale MobX apps.

Same app, 2 state management libs. Redux is super explicit, MobX fits in one file.

You know how to use MobX, but do you have a good mental model for how it works? Perhaps it feels like magic?

Learn the basics of using MobX and build a silly example to see how it works.

MobX is wonderful. My first love when it comes to React state management.

Here's a few tips and tricks I learned about Redux over the years.

Redux with its actions and reducers and elegant store is great. But what makes it really shine are thunks. Thunks are great.

So what does Redux actually _do_ when you do your reducers and your actions and connect things to the store?

So you know WHY you'd wanna use Redux and when. But how?

You've heard of Redux haven't you? It's great and everyone's using it. But why? When? Does it always make sense to reach for Redux?

Your redux or mobx or vuex store is a mess. There's too much stuff in there. So what went wrong?

Your redux or mobx or vuex store is a mess. There's too much stuff in there. So what went wrong?

Your state is a state machine. That helps you think about it. Values are circles, actions are arrows.

Learn all about state management in modern webapps.

So you've built an amazing React component. It's self-contained, does great things, and you use it all over.

You'll soon realize that dealing with your whole app when all you wanna do is build the perfect button is annoying. So build your components in isolation first, then use them in your project.

Plus a lesson about polluting your low level components with context.

Build simple forms with React controlled components and keep your API declarative.

A question everybody asks: How do I decide what's in my component? When should I split it up? How many abstractions should I build?

When something goes wrong, React turns your whole app blank. You can fix that with error boundaries.

React portals let your component control any part of your app as if it was its own child element. Pretty neat.

Make your users happy, keep their codebase consistent, support both patterns.

You can think of them as dependency injection or as inversion of control. The point is that you pass a component into a component and it lets your consumer define how something gets rendered.

High order Components let you wrap any component in a new component. This lets you share functionality between different components in your app. In this video we build a simple clickLogger to show how it works in principle.

You build components with the linux philosophy. Do one thing and do it well. 👆Then assemble for bigger things. Higher order components, render props, function as children, and composite components take a different approach.

React lifecycles, they seem absolutely crucial, but really you'll use them for loading data and not much else. Sometimes for 3rd party library integration or making declarative animations.

You should never ever under absolutely no circumstances ever need to use direct DOM manipulation in a React component.

React will yell at you, if you render a list and don't give each element a unique key. But does it really matter?

Styled components are my fav approach to styling React. Best balance between normal CSS and css-in-js.

CSS Modules are not my favorite, but they're pretty much the only option when you have a bunch of existing CSS that you want to make better.

The style prop is great. It's there by default and it works. You should use it for one-off styling overrides or your app is gonna get unruly.

Styling is hard. There are many ways to do it. Do you go CSS, do you go css-in-js, which css-in-js do you choose?

The new React 16.3 context API. Why to use it, when to use it, how to use it. All in 2 minutes 20 seconds and 150 milliseconds.

Yesterday we said that props flow down and callbacks fly back up. Today we're putting that into practice with some code.

How do you share state between components? With React (and Vue) we like to keep our dataflow unidirectional. That means we hoist state to the least common denominator, pass it down via props, and change it back up with callbacks.

React comes with a full event API. It's great. No more addEventListener, no more memory leaks. But there's one bit that's hard 👉`this`

Your UI is an expression of state. Manipulate the state, change the UI. Never worry about the rendering.

Both state and props are just JavaScript values that you use when rendering JSX. So why do you need both?

We're building towards a chat app 💬

Some still debate it, but I love how JSX lets you get in there and get your hands dirty right with the stuff your code is meant to be outputting. Like a top chef 👩‍🍳 gently massaging a steak. 🥩

React, Vue, Angular, or whatever. Components are the future and you should learn how to think in them. Here's why.

React can make your D3 amazing. Want to animate 20,000 elements with React? I'll show you. Want to build a complex dataviz? You'll know how. Want to write maintainable dataviz components that you can reuse in any project? I gotchu, fam. This talk shows you everything I've learned about creating reusable and maintainable graphical components over 3 years of hammering away at the question: 'Jeez D3 sure is hard to learn, how do we make this easier?'

Swizec Teller talks about how components are the future of web development.