- The speaker discusses the importance of accessibility and how it can be difficult to learn.
- They share a personal anecdote about realizing the value of accessibility when dealing with different-sized currency.
- The speaker talks about the tendency to rewrite code when introducing new technology, but highlights the challenges and drawbacks of this approach.
- They emphasize the benefits of adopting new technology, such as recruiting and job satisfaction.
- The speaker warns against the pitfalls of rewriting entire features and the problems it can cause in terms of understanding and bug fixing.
- They suggest a different approach using React, starting with rewriting small components and gradually incorporating them into the app.
- This iterative approach allows for bug fixing and feature additions without disrupting the entire codebase.

- The speaker discusses the process of rewriting an app in React, starting with fixing bugs and gradually rewriting sections of code.
- The speaker mentions the possibility of switching to a different technology in the future.
- The speaker demonstrates converting a section of a Backbone app to React and discusses the advantages of using React.
- The speaker encounters some technical difficulties but eventually successfully converts the section to React.

- The speaker discusses how React handles passing information between components using props and functions
- They explain how React can handle actions and information flow more efficiently than traditional methods
- The speaker mentions the challenges of implementing GraphQL and Relay in existing applications
- They highlight the benefits of using React Router in migrating towards React in existing apps
- The speaker introduces the concept of data dependencies and how React Router can work seamlessly with Relay
- They mention the use of Async Props in React Router for handling data loading and rendering
- The speaker provides an example of implementing Async Props with Flux for data fetching
- They demonstrate a real implementation of Async Props with loading indicators and dynamic rendering

The speaker discusses the issue of slow servers causing flashing screens and proposes a solution using React. By saving old props and rendering them again, the speaker demonstrates how to handle asynchrony in React and provide a smooth user experience. The speaker concludes by encouraging the audience to migrate to React and have fun doing it.

The speaker emphasizes the importance of accessibility and shares a personal anecdote. They discuss the challenges and drawbacks of rewriting code when introducing new technology, while highlighting the benefits of adopting new technology. The speaker suggests an iterative approach using React to gradually incorporate new components into the app. They discuss the process of rewriting an app in React and mention the possibility of switching to a different technology in the future. The speaker demonstrates converting a section of a Backbone app to React and discusses the advantages of using React. They explain how React handles passing information between components and mention the challenges of implementing GraphQL and Relay. The speaker highlights the benefits of using React Router in migrating towards React and introduces the concept of data dependencies. They provide an example of implementing Async Props with Flux for data fetching and demonstrate a real implementation with loading indicators. The speaker proposes a solution using React to handle asynchrony and provide a smooth user experience. They conclude by encouraging the audience to migrate to React and have fun doing it.

Your front and back ends are already successfully in production but you don't have to miss out on the productivity that React brings. Forget the rewrites, this is brownfield!

I've actually never been on this side of the world before, so it's been a lot of fun.

My talk today, don't rewrite, react, get it?

I was going to talk about accessibility, and that's what was on most of the schedules.

As I was preparing that talk, I didn't have anything new from what I had talked about at Mountain West JS a year and a half ago.

So if you want to see what I was going to talk about, go find that video on YouTube, Mountain West JavaScript 2014.

It was great talk, and I care deeply about accessibility.

In fact, My wife hears me talk about accessibility so much that when I bought some Euros, I got them, and I went to fold them up and stick them in my pocket like I do U.S.

Dollars, but you can't really fold them all together because they're all different sizes, right?

And my wife goes, well, what if you were blind?

Now I can tell which bill is which and it makes a whole lot more sense.

So anyway, don't be like Ryan Seacrest and try to high 5 a blind guy.

Consider what the world is like for them and study up on accessibility and learn how to do it.

I know The great irony is that accessibility on the web is really inaccessible to learn, but you can do it.

This was 1 of my applications a while ago.

We had this requirement to draw a, to paint a white line on the edge of the road because our users were confused about where the edge of the road was.

And so we wanted to put a white line on it so it was more clear.

And I got to this branch and I thought, who put this branch here?

I bet if I touch it, the whole road will explode.

I'll just draw my line around it and then I'll keep writing my code.

You see that code and you're not sure why the branch is there.

It seems ridiculous but let's just leave it alone.

I bet if I bring React into this, I could get rid of all those branches And then I could draw some straight lines.

And so you go to your team and you say, you know that big feature that everyone's afraid of touching and we keep just drawing the white lines around it?

And this is the approach that I had taken in the past before I got a hold of React, to try to bring new technology into my stack.

And there's a lot of benefits to bringing new tech into your stack.

Number 1, it's new tech, so it's more fun.

A lot of people think that this is not a valid reason to adopt new tech, but it's great for recruiting.

When you're interviewing someone, and they ask, okay, what's your stack?

And you say, well, the back end is Rails 2.3 and the front end is, it's, there's a lot of jQuery and then there's another folder that's mostly backbone, then there was this bit where we did CoffeeScript for a little while, and then there's another folder that's got some Angular stuff in it, and then this other team is doing some member stuff, and, you know, the interviewer is like, or The interviewee is thinking, sounds fun.

Then they interview somewhere else, and they're like, oh, yeah, it's all React, top to bottom, and GraphQL.

People get excited about that, and they want to take that job more than another 1.

The products matter to a lot of developers, but I've learned that there are a lot of us out there that really do not care what we're building.

What we care about is the tech that we get to use.

I feel really silly because I'm the opposite and I care about the product a lot.

So historically, we get a new piece of tech and we say, okay, let's rewrite this feature.

And that feature's got a lot of different screens in it.

But unfortunately, when we start that rewrite from the top, all those blocks just went white, right?

Like this is not shipped code, and none of those features are there anymore.

And we start at the top, and then we get 1 of the little features over on the side done.

We start working on this 1 over here and we have no idea what is happening in this code.

And all of a sudden we learn that there's a bug somewhere below that section.

And we're thinking, OK, should I go fix that bug in the current code, like what's shipped out there?

I can't really deal with it right now because I haven't figured out the view above this.

And so I can't get down to that lower 1 and fix the bug in the rewrite.

And then product comes to you and says, hey, we want a feature over here.

And you're thinking, oh, but I haven't, like I'm not there yet.

I'm still trying to figure out the other 1, and I've got to fix that bug.

Should I go add that feature to the old code?

Do I quit working on this really confusing 1 and start working on this to get that new feature in?

And then they want a feature down here, and you're like, oh, no, that's a feature in the code that I still don't understand what's happening.

I think they're triggering events on document and then subscribing to those events in like 8 other files, but I haven't quite figured that out yet.

So you're sitting in sprint planning and this is your team all excited because we're using all excited because we're using React.

The rest of the company, however, is like, hey, friends, it's on fire.

Why are you pausing and taking a picture?

I love this from a mixonic, he's a well-known developer in the Ember community.

Some people, when confronted with a problem, think, I know, I'll use a long-lived branch.

Now they have 2 problems and a blocked team.

We had this thing that we called draft state and We worked on it forever and we weren't shipping anything Then by the time you ship it this is how everyone feels about the rewrite Very disillusioned very upset if you don't Castro was not what I thought he was.

You can look this guy up and learn about that.

So you ship, but nobody's, no one's excited anymore.

You're all actually really bummed about this rewrite.

And while we know that the tech underneath that we just used is better, when we go to try to pitch like, hey, that went really great for us, the developers, we'd like to go and rewrite this thing now.

And your team is, no, we're not doing that again.

You should be able to iterate to new technology just like you can iterate to new versions of technology.

If you're going from a 1.0 to a 2.0, people care a lot about giving you a really great upgrade path.

Being able to go from no.0 to 1.0, you should be able to iterate to that.

So with React, you can actually take a very different approach to this problem.

Instead of coming in from the top somewhere, let's come in from the bottom.

Let's find the tiniest view that makes sense to rewrite in React.

For me, in 1 of our applications, it was the profile form.

It would make a request to the server, save your profile, and then it would redirect you to your profile page.

So I went ahead and I rewrote that little form in React.

That evening it went out onto master and then out to production, and we had React in the app.

And then you rewrite the profile show page.

So we had the form in React, and now we're going to display that information in React.

You write it, You commit it, you ship it, and now it's out there.

There's no big, great rewrite that's going on that's making everyone grumpy and blocking your entire team.

If we find a bug over here in the app, well, we can just go and either fix the bug or use that as a great opportunity to rewrite that little piece in React as we fix the bug.

Or not, just go fix the bug in the old code.

And then we continue on up the tree and someone wants a feature over here in the app.

Stop what you're doing, go over there, add a feature, add it in the old code, it's fine.

And then you just keep climbing up the tree.

And every time all the siblings are rewritten in React, you can combine them.

React's component model makes composing code together so simple that when you get to this point where you've got this handful of views that are all siblings and then the parent that's putting them together, it's really easy to just turn that parent into a React component and then grab these other ones you've already built and then compose them together until eventually you have your entire app rewritten in React.

And then we can start changing these blue dots to purple ones in 3 years when something else is cooler than React.

React 2.0, React 3.0, something else might be more interesting, and you could this very same thing again.

Let's see what this looks Let's see what this looks like in a real application.

I say this all the time in our trainings when I talk about this app.

What good is a JavaScript event if we don't talk about TodoMVC?

You can see when I reload this, we get a nice flash of information that is a clue to you.

In Backbone's defense, it also has this characteristic where you can climb up the tree.

Aren't you so glad you have Webpack now and Browserify?

Someone asked me at a training, if you had to pick between React and Webpack as like the technologies that came out in the last year or 2, which would you pick?

Probably React, but it would be a really hard choice for me.

Because all they have is bread in France.

I did find some air conditioning in the fancy speaker place.

Okay, so down here I can click on these links and move things around.

And then I could clear all the completed things.

This little footer to me seems like a really nice section of my app to remove from Backbone and redo in React.

So let's see just how quickly we can do this.

So over here, I have added my footer component, which is a React component.

They've got this stats template that they use down here in render.

Let's just take a minute and look at this render method.

After you've been doing a React for a while, this render method is like really strange to think about.

We're saying if we've got some length of to-dos, let's go and grab some elements and call methods on them.

Inside of render, we're going to manage the state of instances over time.

Let's go find 1 tiny piece of our template and let's change that little piece inside of there to some other HTML.

Now let's select some things and manually manipulate their attributes and Otherwise let's hide some stuff and then let's make an assignment inside of render.

If you call this.set state in a React render you get an error because we're rendering, we're not changing state.

So anyway, this code leaves a lot of bugs so we're excited to bring React into here.

So I'm going to hang on to the footer here.

And bring my footer up, grab the actual DOM node.

All we need in React, all we need is 1 element that's already in the page and we can start rendering with React.

Let's make sure that I have my footer in the page somewhere.

But I prepared my talk at 2 in the morning.

And I need to bring in the JSX transformer.

Don't actually use this thing in production.

Actually, I think it's going away completely.

I've got some quote unquote server rendered stuff going on.

Those of you who are watching on the video, you might notice I'm sweating bullets, but it's 1 of those to-do items.

Oh, I already, I found it, I need to get back.

So I'm going to grab this template out of here.

Oh, now I've lost everything, because I saved.

Okay, so now my next task is to find the old template stuff and switch it over to JSX.

And I got this little if, so let's say completed, yes.

And now I like to touch these templates as little as possible when I'm converting from somewhere else because if I mess with the template, I'm going to have some regressions And I want my team to be excited about switching things over to new technology.

So I can say completed equals this.props.completed.

And then I can say, what was the other 1?

If we come back over here and look at our app view, we pass them in to our component.

And actually, I believe it's on app.footer.

Oh, I actually did delete my oh, now I know what you were telling me.

So I prepare, like, my tasks that I need to do for our trainings and conferences, and then I get all the help from everybody else, and so I don't have to write a whole lot of my own code, and it works out really well.

APPLAUSE The actions aren't happening, though, right?

Backbone is still handling that kind of stuff.

So when we want to get information down to a component in React, we pass props, right?

And when we want to get information back up from a component, we pass a function in as a prop and call it from the component.

So I can come up to my view and quit handling this really hard to follow delegation stuff.

You may have an action that's way high with this kind of event delegation and you don't know where it's coming from.

So instead of handling an action from a template somewhere else completely, we're going to have React do this.

And now I come down to my React app and I say on clear completed.

Actually, I can just say this.clear completed.

So Inside of my backbone app, I've got this function that's going to be called and it will clear everything up.

I train on React for a living, just trust me.

And now I can click this here, and the action gets handled in React, and then it sends the information back up to the app.

So what I really love about React when you're iterating to it, you can come in at the bottom, and then From there, it's all the same principles that apply to any react app They apply to iterating to react to get information to your component You send props to get information back out from your component you send functions and then you call them back up So that's pretty cool Okay back to this If I were to go at my old job, I'm really excited about GraphQL.

I think It's obviously the right answer to building UI and the data needs that we have there.

However, I know that if I went to my team and said, hey, we started using React and it's really cool.

You guys would love it if you ever worked with it.

It'd be really nice if our backend could speak GraphQL now so that we can build these new features.

We can't do it until we have a GraphQL back end.

They're going to view you like a couple of clowns, front end people telling me how to build my servers.

So I'm very excited about GraphQL, but it's going to be kind of hard to get there for a lot of teams.

Brownfield applications, however, you'll need to, that's awesome that we just learned that we can iterate toward it as well.

And so then you think, all right, I'll build my own like cache in the front end because I don't get to use Relay because I don't have a GraphQL back end.

Man, Sometimes, sometimes it's just not quite worth doing everything amazingly well and having like these really robust client side caches.

Sometimes you really just wanna make Ajax requests to the server and save things.

And then once that finishes, do something else.

That's part of iterating to React is making some of these trade-offs.

React Router used to not work very well when it came to iterating toward React in an existing app.

Michael's going to talk a whole lot more about React Router tomorrow, and a lot of the great things that we're doing there.

But 1 of the newer things in the 1.0 API that I'm excited about is you can treat the router as a pure component.

You can get some properties that you need for its initial state and hand it to it and then it will match all of the views and render for you.

But it doesn't necessarily have to set up a listener on like the URL.

You can just hand it information if you can figure that out yourself.

So if you've got some other router and you want to iterate to React and you want to bring in the nesting that React router gives you, you can use some other router that's already in your app and all we need from you is a path name and a query, then we can have this thing called a location.

You can run that with your routes in that location, and you'll get back some initial state.

You'll learn why that's async for Michael tomorrow.

And pass that initial state in, and it will just render as though it was listening to the URL even though it's not.

So you can use React Router as you migrate toward React in your applications.

The other thing is data dependencies, right?

We're all really excited about relay and we're excited about GraphQL and Falcor is very similar.

This idea that you can define, that you can co-locate your data dependencies with your components.

And this is an idea that's very, very appealing to me.

And the router, fortunately or unfortunately, is right in the middle of this problem.

Because you get your dependencies most of the time from the URL, you have some sort of parameters, what group am I looking at, what user am I looking at, which assignment am I grading?

Those kinds of questions come from the URL.

And so another thing that we wanted the router to be able to do was to be able to let you plug in data abstractions to React Router.

Especially, Relay was the main push for this.

We wanted to be able to have the router work with Relay seamlessly.

So, we've got a few new spots in the router to handle this kind of stuff.

And we're actually shipping a little thing called Async Props.

You can find it in lib, experimental, Async Props.

This allows you to add some static methods to your components.

It hands you the parameters that came from the URL, the user ID, the assignment, and a callback.

It's not backed by any language like JSON graph or GraphQL, just some simple callbacks.

And so, you have your URL, you can go and fetch that URL, and then just callback with an object of properties.

And what's going to happen is async props will pause routing while this is happening.

I hope I have a minute to show how that works, because it's really cool.

It pauses routing, waits till these props load, and then it renders.

So down here I don't have to do any like if this.state.loaded or any of that kind of branching.

I know I'm going to get props right off the bat.

It's also great for testing, because now when you want to unit test 1 of these, you can just throw some props at it and go.

You don't have to stub out a bunch of Ajax requests.

Now to make this happen, in your route config, we have this new property called create element.

So the router creates the elements for you so that we can get some properties in there like the parameters and the query and all that.

See all ReactEurope transcripts on Youtube

Ryan Florence - Don't Rewrite, React! at react-europe 2015