Application State Management is one of the hardest parts of building and maintaining React Applications. The number of options you have is numerous and the reason is that it's just such a hard problem with so many nuances and trade-offs. One thing that makes application state management harder is when we aren't thoughtful about how that state is organized and categorized in our app. There are different kinds of state and they require different approaches for management. When you try to treat all app state exactly the same is when problems come into play.
Let's talk about what some of those categories are and how we can drastically simplify our application code and improve our app's performance by thinking about and organizing our state differently.
How do you level up? How do you jumpstart your learning when getting into something new? Nobody has more than 24 hours a day, so how do you maximize the impact of your limited time?
In this keynote, I'm going to tell you a bit of my own story, and some tips and tricks that I've learned so you can be as productive as you can be at learning new things and solidifying that knowledge so it's there when you need it.
We want to make sure that when we ship new code, our users can use the application. The best way we've found to do that is to write automated tests that run before we deploy a new version of the app. But if our tests aren't doing exactly what the user will do, then how do we really know that things will work when users interact with our apps? Let's rethink what it means to ship applications with confidence and what it takes to get there. With improved tools and practices, we can be more certain that what we're shipping to our users will work the way it's intended.
JS@PayPal (internal conference)📺
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear by the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase by applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.
One of the things I love about React is how easy it is to encapsulate UI code into a component. I love this because it makes reuse of those components easy. But is it easy? I've made my fair share of components that had to accept a bunch of props to handle a growing list of different use cases resulting in a complex render function full of conditional statements and a confusing API for people using this "reusable" component. Eventually it becomes too much and I had to make a new version of the same component to handle slightly different use cases. Lots of code/bug duplication there because my reusable component wasn't reusable enough. There are patterns that have emerged in React that allow you to promote code reuse without sacrificing the simplicity or flexibility of the component. In this talk we'll go over 5 of these patterns that will make your React components more useful.
JS@PayPal (internal conference)
In October, the React team announced a new feature coming 🔜 to React called "hooks." In this talk we'll go over what this feature is and why this feature is necessary. We'll also see a real-world example of an application that uses React hooks.
Awesome! You've made it big! You've published an open source project and people are actually using it to make the world a better place. Achievement unlocked! Great job! But wait... what's this? An issue? Oh, it's just a bug. Pretty quick and easy. Fixed, released, done, #likeaboss 😎. What's this? A PR? How cool! Wait... That's not quite right... Oh, a question! Cool! And another! And another... eh... and another... Uh oh... You think you've just sold your soul to this project.
You start an open source project to scratch your own itch and suddenly other people start using it and they need your help. This can easily start eating up your time big time and before you know it, your kids/dogs start feeling neglected.
I've had to deal with this in a few projects and I've learned a thing or two about work/life/oss balance. I have a few tricks that help you make the project manage itself a bit more while still being friendly and helpful to users of the project. Let's chat.
What kind of world do you want to live in? The world of Open Source Software is supremely vast, and it's growing. We can't sit idly by, coding alone in our closets with an attitude of "if you want something done right, you have to do it yourself." We don't want to live in a world like that. The community we want to build around OSS requires intentional effort to maximize the happiness of everyone involved. And the rewards of working toward that goal are serene. I'd like to personally welcome you to the open source community. Bring your distinctiveness and help to make our world a better place.
For the last few years of using React, we as a community have been trying to solve the hard problem of application state management with React when we already had one all along. React itself is a state management library.
You can use features and practices that have been a part of React for a long time and it will change the way you think about state management for your React apps. In other words: you probably don't need Redux, MobX, or any state management library other than React. Let’s explore how that’s possible and why you might want to think twice before reaching for an abstraction.
In this talk, we’ll explore some of the gotchas of using hooks, why those things are problems, and how to think about hooks so we develop an intuition for how to use hooks while avoiding the pitfalls.
This is basically the talk version of my blog post Testing Implementation Details.
There's a lot of chatter about React Hooks. They really change the game, but they are also a totally new mind-bending approach in some cases. In this webinar, I'll go over what React Hooks are, why they're useful, and demo what you can do with them.
Let's talk about contributing to open source. In this talk, we'll go through the process of contributing to an open source project on GitHub.
Can Vue use Render Props? Does React have a concept like Directives? Can Angular go Renderless the way the young 'uns do? All my developer friends in that other framework keep using words I don't understand. Help! Join Kent C. Dodds, Isaac Mann and Divya Sasidharan as they demonstrate UI component patterns that are common across React, Angular and Vue. Consider this your language primer before a trip to a foreign framework land. You'll see that we're all talking about the same concepts, even when we use different words.
React Suspense is coming and it's going to be awesome. It's currently in alpha and you can play around with it. In this talk we'll focus on the fundamentals of how React Suspense works.
In this talk I teach React from scratch in a single
index.html file with no magic up my sleeves. We start with
introducing more of React's APIs.
Learning React can be confusing. React is a library, but even more than that, React is an ecosystem of tools that you piece together to create a program. This is a powerful property of the React community, however that ecosystem can be frustratingly distracting when you're a newcomer trying to get your feet wet. The key to avoiding this frustration and confusion is to learn React (and its ecosystem) in the right order. In this talk, we'll go over what that order is and give a roadmap so you can have a vision of where you're going. Let's learn how to React!
JS@PayPal (internal conference)
The open source community and ecosystem have made me a better software developer and helped me develop better software. I get to see how other people work. Other people get to see how I work. It encourages me to put forth my best effort, think critically about the software I'm creating, and ensure it has great documentation. It's also easier to develop software in an isolated environment like an open source project. In this talk, we'll see how open source can help improve your skills and improve the software that you create. This makes you a much more skilled, marketable, and gives you work that you can share with the public and contribute to the open source ecosystem.
Building things so they work well in isolation, then piece them together to make the full application makes building applications easier. One thing that really helps with this kind of strategy is to open source your stuff. In this talk, we'll take a look at an existing application, identify a good candidate component for open sourcing, and then go through the process of creating an open source project for that component and add it as a project dependency. By the end that component of the application will be easier to work on and contribute to and we'll also have it open for the rest of the world to contribute and improve the software which once had bugs that were just as private as the original project repository.
Automated tests are an important part of raising your confidence when releasing software. They can speed you up or slow you down depending on how you write them and which form of testing you focus your test writing on. In this talk, we'll cover the value of automated testing and where your efforts should be focused to strike the best balance of confidence and effort.
Customize babel without configuration or ejecting from create-react-app
The Abstract Syntax Tree. It sounds a lot worse than it is. It's actually quite simple and enables some powerful tools. BabelJS uses it to transform your code from ES.Next to ES5. ESLint uses it to lint your code. And with a knowledge of how it works, you can extend these and other tools to do some mind bustingly powerful things. Prepare to be amazed by ASTs!
I no longer care about: specificity, CSS linters, CSS preprocessors, vendor prefixing, removing unused CSS, finding CSS dependencies and dependents. I now care more about: whether it's fast enough, whether it's small enough, whether it's familiar enough. These are some of my trade-offs. Because I use CSS-in-JS. I've made trade-offs because I write HTML-in-JS. Despite these, I still do it, because the cost is minimal enough, and the benefit is great enough. Let's tell stories, talk use-cases, explore trade-offs, and inspire more innovation to make the CSS-in-JS trade-offs less trade-offy.
JS@PayPal Summer 2017 (internal conference)📺
The more code you have, the more problems you have. One of these is the ability to learn the code. Code often has
logic to handle edge cases which can distract a new contributor from the core logic of the code, making it
the more you send over the wire to the browser, the slower it goes. This is due to network latency primarily, but
also parsing, evaluating, and keeping relevant variables in memory.
With a really interesting technique called program slicing, we
can build tools to help to mitigate some of these problems. In this talk, I'm going to give you a peek at a tool
I've been working on called
slice-js 🍕. I'm super excited about the implications for a project like this!
I hope you're excited about testing! We all know we need to get testing better, but it can be really hard to know how and what to test. We'll learn about the four inputs to React components (user input, props, data, and context) and how to test for each of them. You'll discover that if you slightly modify the way you're writing your components, you can make them much easier to test. We'll be using the new super fast, simple, and feature full Jest testing framework with enzyme and snapshot testing. I hope you like code. You're gonna see some here!
BYU AIS club Value Added Forum
ES6 Modules have been standardized and many have already started using them. They have a lot of benefits over CommonJS, AMD, and Globals. Unfortunately, there are many ways to deal with modules with this new syntax and it can be a bit confusing. In this talk, we'll explore the different ways you can use the new syntax and when you'd use the different methods. We'll also investigate what's going on at a high level. Buckle up for a firehose of ES6 information.
"Feel free to submit a pull request." For some, this is a welcome invitation, but for many developers, pull requests are intimidating, discouraging them from contributing to the community. Kent Dodds demonstrates how easy and fun it is to create a pull request as a first timer. To open source newcomers: You, open source newcomer, can be a valuable contributor to the open source community. We need you here. We want your input and contributions. But getting over that initial hump of contributing can be a real challenge. I call this the first-timer's dilemma. You want to contribute, but you don't know how, or you're afraid your pull request (PR) won't get merged. You'll learn that it's less frightening and easier to get started than you think, as you become familiar with the common patterns and processes you need to understand in order to contribute to an open source project. To open source project maintainers: You, open source project maintainer, are the lifeblood of the open source community. Developers power open source. The more people finding, reporting, and fixing bugs or adding/removing features the better. You have the power to help newcomers overcome the first-timer's dilemma. You'll see what challenges first-timers often face and how with just a few extra minutes of your time, you can help tear down these barriers and make your project more friendly to contributors (including first-timers). Whether you'e new to open source or a pro, Kent will help you as we strive to make the open source community more open and friendly.
Knowing what and how to test is almost more difficult than actually writing the test. If you write only end-to-end tests, you'll struggle with reliability and speed. If you write only unit tests, you'll struggle with surprising bugs integrating things together. In this ignite talk, we'll take these concepts away from code for a moment to see how we would test a wheel. Prepare for an enlightening, entertaining 5 minutes 😀.
Setting up test coverage reporting with ES6 and Karma
Angular 2 is built for huge web applications that stand the test of time. To accomplish this, Angular 2 utilizes the latest and greatest web technologies like ES6 modules/classes and Web Components. Come get a preview of what this looks like with egghead.io instructor Kent C. Dodds as he live codes an application using the pre-release alpha version of Angular 2.
Moxee will create tests for you which will ensure that no injectable function is requiring anything that the module doesn't provide on its own (or via one of its dependencies).
Angular 1.3 brought a sweet new directive to the table called ng-model-options. It gives you more control over how your model gets updated and is very easy to use. Get a quick intro and start using this today!
ReactJS is an amazing View library that promises (and delivers) high performance, composability, and maintainability. AngularJS is an amazing MV* framework. Tons of shops have adopted and totally bought into AngularJS for their entire frontend application. They're loving it, but some are finding that as these applications get bigger, they can become unwieldy, unperformant, and difficult to reason about. Many of these problems can be solved by doing things better with angular, but not all of them. In this talk, we'll go over why you don't need to re-write your whole application to get some of the wins of React and that it actually is quite easy to integrate the two. We'll talk about where it makes sense to bring in React to an existing Angular codebase and how it works well.
AngularJS is one of the most popular frontend frameworks out there right now. If you haven't tried it yet, prepare to be amazed! Here's what we'll cover:
To my classmates at BYU📺
I believe that people are so much more productive when they don't need to use the mouse to click on something. One implementation intended to help with this is keyboard shortcuts. Unfortunately, these are limited to the number of sensible keys and key combinations and can be difficult for users to discover, remember, and use. Normally, only super users will ever use them. The goal of genie is to address the problems with keyboard combinations. Genie is a simple library to emulate the same kind of behavior seen in apps like Alfred (for macOS: alfredapp.com). Essentially, you register actions associated with keywords. Then you can request the genie to perform that action based on the best keyword match for a given keyword. This allows a user to type what they want to have happen and select from a list of the best matches for what they typed to perform an action. Over time, the genie will learn the actions more associated with specific keywords and those will be come first when a list of matching actions is requested. Check it out at github.com/kentcdodds/genie
If you're not careful (especially with your ng-repeats) your watch count in your app can grow pretty quick. This isn't a problem itself, but its what that does to your digest cycle. Lots of watchers makes your digest cycle take longer. In my talk, we'll talk about what Angular 1.3 is doing to help solve this problem, the problem their solution presents, a solution to that problem, and what can be done for pre-Angular 1.3 code.
This was an impromptu talk while we were waiting for the actual speakers to come, so I'm not on the schedule.
Cookies and sessions are the traditional way to keep track of user state on the server, but it can bite you later.
JSON Web Tokens (JWT) is a stateless way to deal with users. I'll show how to use
$httpInterceptors to make
this easy as pie. :-)