⌘/ctrl + f
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.
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!
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.
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.
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.
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
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.
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.
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!
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!
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… I think I’ve just sold my 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 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.
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!
Our industry has a problem. We have a "talent shortage," so we're loading the industry with new developers from various bootcamps, but they're having trouble finding jobs because many companies are unwilling to hire and train them. So these new developers are left to themselves to try and find ways to develop the skills they need to be "marketable."
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:
We'll be following through a repository hosted on GitHub. There's a branch for each concept, so you can play around with the code and then catch right back up with the next branch. So come on, and let's learn AngularJS!
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. :-)