Stories and Strategies from Converting to TypeScript

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

TypeScript is great, but migrating an existing app to it can be a pain. Codecademy took multiple existing React apps and converted them to TypeScript. We'll cover how to make those kinds of conversions successful from both cultural and technical standpoints.

This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.

FAQ

Josh Goldberg is a front-end developer who has previously worked with Microsoft and is currently on the web platform team at Codecademy. He is also experienced in converting projects to TypeScript.

Before transitioning to TypeScript in early 2019, Codecademy's main front-end app consisted of about 2,000 files primarily using React and Redux. There was also a separate design system that was used as a proof of concept for TypeScript.

The decision to transition to TypeScript at Codecademy involved understanding the team's needs and goals, promoting the benefits of TypeScript to enhance code stability and bug reduction, and generating enthusiasm among team members for the new technology.

To facilitate knowledge sharing during the transition to TypeScript, Codecademy utilized internal presentations, pairing sessions, and identified 'area experts' and 'cheerleaders' within the team to help spread understanding and enthusiasm for TypeScript.

Codecademy started by converting a minimal number of files to TypeScript to ensure compatibility with existing infrastructure. They adopted TypeScript as a syntax and build time checker without disrupting existing JavaScript code. Over time, dedicated pull requests were used for converting specific areas to TypeScript.

Typestat is a tool developed by Josh Goldberg that automatically applies deducible TypeScript conversions across multiple files. It helped streamline the process of converting Codecademy's codebase to TypeScript by automating many of the changes.

The TypeScript conversion at Codecademy started on April 2, 2019, and took approximately 259 days, concluding on December 17, 2019.

Key lessons from Codecademy's TypeScript conversion include the importance of automating repetitive tasks, preparing a style guide for consistent coding practices, separating TypeScript conversions from runtime changes, and celebrating milestones to boost team morale.

Josh Goldberg
Josh Goldberg
20 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses the process of converting to TypeScript at CodeCademy. It emphasizes the importance of encouraging adoption and knowledge sharing within the team. The Talk also highlights the seamless integration of TypeScript into the existing infrastructure and build system. The strategy for converting to TypeScript involved using dedicated pull requests and automated tools. The speaker shares tips on automating changes, setting up a styling guide, and celebrating victories. Resources for learning TypeScript are also mentioned.

1. Introduction to Converting to TypeScript

Short description:

Hello, and welcome to stories and strategies from converting to TypeScript with me, Josh Goldberg. To start off, hi, I'm from upstate New York. I'm a front end developer on the web platform team at code academy, previously Microsoft, and I'm a cat dad. Starting off, where was CodeCademy before TypeScript? Let's take a step back all the way to early 2019, a simpler time. We had a main front-end app, which at the time consisted of about 2,000 files of react and Redux, a few more files in a separate design system, which itself was converted to TypeScript as a proof of concept, and most team members had really only vaguely heard of TypeScript.

Hello, and welcome to stories and strategies from converting to TypeScript with me, Josh Goldberg. To start off, hi, I'm from upstate New York. I'm a front end developer on the web platform team at code academy, previously Microsoft, and I'm a cat dad.

My wife and I have a few cats. They're very cute. All the stuff in this presentation is available on my website under the slides link under this talk at joshuakgoldberg.com. This presentation does include several looped animated images. If those are distracting for you, I would recommend viewing them in PowerPoint, which allows you to pause them.

As for an agenda, first, we are going to talk about code academy in 2019 before we made the jump to TypeScript, how we made that decision to jump to TypeScript, some of the techniques we used for knowledge sharing on the team, technical details of what we did in order to make that jump, and then some of the learnings we got at the end throughout the process, things that you might be able to use in your conversions, I hope. Good stuff.

Starting off, where was CodeCademy before TypeScript? Let's take a step back all the way to early 2019, a simpler time. We had a main front-end app, which at the time consisted of about 2,000 files of react and Redux, a few more files in a separate design system, which itself was converted to TypeScript as a proof of concept, and most team members had really only vaguely heard of TypeScript. There wasn't a big topic or knowledge point on the team. The team itself was pretty small. It was only around 20, maybe 30 engineers at tops. Most of the people didn't really have TypeScript experience and there was, as with any engineering team, ongoing work around features and bug fixes.

So how did we do it? How did we make that switch to TypeScript? First, we made the decision that we wanted to do it in the first place, and when there's a will, there's a way, but there has to be a will. Any architectural shift should have the informed support of its constituents. I think a lot of people, especially those who are new to a team, make the mistake of immediately trying to jump to conclusions and push an agenda, send out proposals, which a lot of the time is a mistake just to do that immediately. It's a good idea to soak in the experiences of being a developer on the team, talk to people, get a feel for what the real issues are, and then use that to inform your decision making around what to push and how. Don't get me wrong. I'm not trying to devalue coming into a team with a fresh perspective and trying to get people to understand and listen to that perspective. That's great. That's commendable. Teams should absolutely be open to you coming in with fresh ideas, but those fresh ideas and perspectives are much more likely to succeed if you validate them with those around you, if you can convince people of their validity. So don't be a brat. Definitely talk to people before trying to push them to do things. If you do want to push people to do things, I highly recommend make some kind of hype train for it. If there is some switch you want to make, say a TypeScript, you want people to feel it. They should be excited in their bones.

2. Encouraging Adoption of TypeScript

Short description:

This is awesome. This is going to make my life happier and better, the code is going to work, it's going to be awesome, I want to do it. That's the feeling you want to encapsulate with perhaps some of the larger decisions you want to push on the team. Part of the way we did it was by encouraging people to think about how TypeScript helps their existing goals, always a good idea.

This is awesome. This is going to make my life happier and better, the code is going to work, it's going to be awesome, I want to do it. That's the feeling you want to encapsulate with perhaps some of the larger decisions you want to push on the team.

Part of the way we did it was by encouraging people to think about how TypeScript helps their existing goals, always a good idea. My favorite image from the evangelism phase of our TypeScript version at the very beginning was us advertising it as part of the bug acquisition funnel, as we call it, or the antifunnel. Not drawn to scale as there is no reliable scale here. No one part of this, pyrethod or peer review or whatnot can truly prevent all bugs, but put together, they can help reduce bugs and crashes on the sites. That was a big part of the team charter at the beginning of 2019, something we wanted to get better at, stability, not having bugs and annoying quirks. TypeScript is one of the core features of TypeScript, and it helps you find bugs early.

3. Ramping up the Team and Knowledge Sharing

Short description:

Once we decided to do the thing, we needed to ramp up the team. We identified two archetypes: area experts and cheerleaders. Area experts can introduce best practices, explain TypeScript, and save the team from obvious pitfalls. Cheerleaders, even with less experience, can act as guinea pigs and help spread the new technology. It's recommended to have at least one or two cheerleaders per team area and at least two area experts for validation and idea exchange.

So, once we decided to do the thing, we needed to ramp up the team. Knowledge sharing, as they call it. This was especially valuable before we made the decision where we wanted people to understand what it meant so they could meaningfully contribute to the conversation. We identified roughly two rough archetypes of people on the team. First off, you had area experts, someone like me who's already really excited about and knowledgeable with TypeScript. I may say so. They're the type of person you can use to clue the team into the technology, to introduce best practices, explain it to others, set up the right learning materials. They're the person who can save the team from themselves in that you can stop the team from making the really obvious pitfalls that you know from having done it before. Also useful and very valuable on the team are cheerleaders, people who might not have as much experience with, say, TypeScript, but are still really excited about it and want to push it and agree with the push. These are the people who can act as guinea pigs, who will try it out, your early adopters or beta testers, as they call them. They can help spread it among the team much more effectively than you because there are a lot of them, oftentimes, if the decision is exciting and new. So I recommend, try to get at least one or two cheerleaders per team area so they can spread the joy of the new thing amongst the team area. At least in Codecademy and many other companies I've seen, product teams tend to talk with each other a lot. So if you can get at least one person into that mix, that's very useful for introducing a new technology. For area experts, at least two is useful because if you only have one, they don't have a peer who can really validate what they're doing, at least from prior experience. So it's useful to have at least two who can bounce ideas off each other.

4. Knowledge Sharing and Code Changes

Short description:

Part of the knowledge sharing for us was through internal presentations, including groundbags, static analysis in JavaScript, and lightning talks. Pairing sessions with frontend-focused team members were also valuable. Keeping code changes minimal and starting with converting a few files ensured a smooth transition without disrupting the team.

Part of the knowledge sharing for us, once we identified area owners and cheerleaders, was internal presentations because no one does anything until there's a talk explaining the general thing, the spirit of the team's movement to it. We held two groundbags, which your team might call chalk talks or lunch talks or some such presentations.

The first was static analysis in Javascript. It was a general introduction to the concept of taking a look at the file without running it and figuring out what's wrong or right with it. And honestly, we didn't even talk about TypeScript that much. It was mostly about existing tools we already were using to get people into the right frame of mind, pretty earliest ones mostly.

After that, we have the really exciting talk, when I was happy about TypeScript, which was specifically about what TypeScript is and what the features it provides that we would use would look like. We also participated in the team's existing lightning talks, which were a series of a few people talking every week, about five minutes of, whatever, random topics. These were particularly useful for the more esoteric topics for TypeScript that might be interesting or cute but not entirely useful for most people, trying to decide to use it or onboard it. Presentations are really useful because people can look at them after the fact and kind of rehearse and go over the stuff.

The most valuable, I think, individual interactions we had were pairing with people because no one really learns anything until they're forced to do it, at least my experiences. And generalization was a useful one. At least for me, if I haven't written a language yet or I haven't used a framework, I don't really understand it until I do. So I scheduled at least one pairing session with every frontend-focused member of the team which was at the time about a dozen, a little more. These sessions we would pair off who was coding in TypeScript and who was supervising. It did not scale. I would try to do that now that the team is above 50-60. That would be really painful. But at the time, it was useful and I think it was one of the more pressing and salient ways to get people onboarded to TypeScript. Highly recommend, especially if you can scale it out with more area owners.

As for the technical details, the literal code changes we made, we kept to as few as possible. And this is a strategy I would highly recommend for any TypeScript conversions. You don't want to start off with a multi-thousand file PR that converts everything into the sun. That's really easy to break and really hard to adjust for merge conflicts. So we started off with just converting the minimum infrastructure integrations with just a few files, converting to TS or TSX, just to make sure it would work. This was good for a couple of reasons. To start, the initial PR was not disruptive to the team at all. We didn't have to pause deployments or anything to get through. We also just didn't change a lot of people with it. No one was disrupted by it.

5. Introducing TypeScript into the Infrastructure

Short description:

We were able to introduce TypeScript seamlessly into our infrastructure, as most of the tools we used already had built-in support or easy integration. Babel, our test runner and production builder, had a TypeScript preset that worked like magic. ESLint, which I'm familiar with, also worked great with TypeScript. And the best part was that Prettier supported TypeScript out of the box without any configuration needed.

We were able to wait to introduce TypeScript to people until the time was right until we could pair with them or they were already more comfortable with the ideas. And the infrastructure honestly wasn't that big of a shift in this pull request. Pretty much everything we used already had a basic TypeScript inclusion either built in or something you can get online pretty easily. Our test runner and our production builder, Justin Roepack, respectively, each had dependency on Babel for compiling code, and Babel has a really nice TypeScript preset, Babel preset TypeScript. So we just went with that, and it worked magically. ESLint has TypeScript ESLint, a project that I sometimes contribute to, so I was pretty familiar with, and that also worked great. ESLint runs take a little longer for us because we bring in the type checker, and that's fine. It still all works. Amusingly, Printier doesn't even have a configuration step that we needed to use. It just auto-magically supports TypeScript out of the box. That was my favorite thing. We didn't have to do anything for that. It was great.

6. Introducing TypeScript into the Build System

Short description:

We introduced TypeScript into the build system with ease of adoption in mind. We only used TypeScript as a syntax and build time checker, without disrupting engineers with legacy code. While we didn't enable the no implicit any setting initially, we later converted files into null implicit any. However, we did enable strict null checks from the start.

Once we introduced TypeScript into the build system, we prioritized ease of adoption rather than sudden, quick, get everything into TypeScript. So we tried not to be too disruptive to people. We explicitly only used TypeScript as a syntax and as a build time checker. We didn't involve it in checking JavaScript code or existing things that weren't TypeScript. We didn't want to disrupt engineers with messages around legacy code that wasn't yet meant to be TypeScript. So there was no need for us to check JS, as the compiler option is called.

We also didn't turn on the very useful, no implicit any compiler setting, unfortunately. It's just hard in a mixed TypeScript, JavaScript code base. If a file imports from a JavaScript file, and you want to convert it to TypeScript, then you have to convert all its dependencies sometimes in order to get those proper types set up. And that's just a pain. We ended up using a similar process later on to eventually convert files, piecemeal into null implicit any.

On the bright side, we did have the ability easily to turn on strict null checks from the start. Very simple concept, not considering null and undefined to be assignable to other types. And it was very useful. So yay, we got that from the start. Beautiful.

7. Converting to TypeScript Strategy and Tools

Short description:

We used dedicated pull requests to convert to TypeScript, focusing on specific areas and involving engineers based on ownership. These pull requests provided a great opportunity for learning and knowledge sharing. I also developed a script to check the language of old commits, which helped us track the conversion progress. The conversion took 259 days, prioritizing comfort over speed. One of my favorite tools, Typestep, automatically applies conversions across files, making the process more efficient. It's open source and can generate TypeScript representations of prop types.

As we went over time, we took a strategy of dedicated pull requests, for the most part, to convert to TypeScript. Occasionally, a team member would get excited and convert something to TypeScript as part of an existing PR, but for the most time, it was just convert area to TypeScript. That allowed us to target specific areas and focus those pull requests just on TypeScript, which made it a little more clear what the changes were. In most cases, or many cases, few to none actual runtime changes. And it helped us understand which engineers to pull in based off of areas of ownership.

This was also a great opportunity for learning for most of the team. Where in each of these pull requests, we explained all the new, potentially confusing even pieces syntax with pull request comments, we're adding a Type here because, etc. Then when people would review the pull requests, they would almost instinctively have to read these comments which was quite nice. So highly recommend dedicated pull requests as a post pairing way of helping knowledge share.

Later on, I wrote a quick little script that would run Git checkout on each of our old commits and check out all the JS files versus the TS files to see which ones were which language. As you can see, over time, it prints out the percentage growth which was pretty nifty. We started the conversion on April 2, 2019, the day after our April 1 joke release which was a fully functional law code course which is a programming language based off of Internet use and cats, one of my favorites. The conversion ended up taking us about 259 days until December 17th which is fine. Had we wanted to, we could have prioritized moving faster but we wanted to optimize for speed. Sorry, for slowness, comfort over speed which is something I highly recommend. Don't assume you have to get to Tashcript immediately. It's likely you can convert some of your code base, high value areas, sooner as a way to ramped up for later.

My favorite technical part of it was typestep, which is a tool I wrote that automatically applies deducible or obvious conversions in mass. So across many files when possible. For example, if a React component declares its prop types with the properties package, you can sometimes most of the time automatically create a TypeScript type or interface for that just by looking at the file. It's kind of involved as a tool. It's still early stage, got a lot of bugs, but it's open source. Highly recommend looking at it if you want to use something like it for your types of conversions. It took a lot of hours to write, but it's saving us a lot of time to this day for our conversions. So I'm pretty pleased with it. I can probably give a full-length talk, but we don't have the time or the focus of this one. This is an example though to reiterate, if you use prop types, we could read your file in, write a script that parses the text into understanding what that prop type is, it's a list of props and for each of them what the type is. And then you could print out back to the file the TypeScript representation of that. It's a little trickier for components that don't declare their own prop types. You have to use the type checker to find all the references to the component to see what are the types and names of all the props provided across all those references, and then combine them together, which is something Typestat does.

8. Automating Changes and Setting up Styling Guide

Short description:

So again, a lot trickier, but still doable. Definitely automate everything and anything whenever possible. Set up a styling guide and learn preemptive questions. Don't convert and change at the same time. TypeScript engineers have this phobia of writing the word any because they think it makes the code less good.

So again, a lot trickier, but still doable. So think of the edge cases and observe Typestat if you're interested. Anyway, we learned a lot and I was very pleased with the process. So I'd like to share that with you now, if that's okay.

To start, definitely automate everything and anything whenever possible. Whether it's a really complex setup like Typestat or just a quick little bash or Node script you write to do the obvious 70% of the work. We relied on this for the vast majority of the changes. My favorite PRs, the most smooth ones, were generated with Typestat for 80 to 90% of the work, and then we touched them up by hand just to make them correct. Double check. I mean, why would you do stuff when you can write a script to do it for you? Also, just from working with engineers, I highly recommend setting up a styling guide and learning what questions people would ask preemptively. Questions like, should you use an interface or type? How do you declare React props? What does x common confusing error mean? That stuff is gonna get asked. It's gonna get asked repeatedly and angrily and early on, so be proactive. Talk to people ahead of time and figure out what is the stuff that you really need to cover that they're gonna ask you repeatedly. A style guide is a great way to answer a lot of these questions and have an FAQ section at the end. We definitely learned the hard way and sorry if you are a Code Academy user in 2019 and we broke this site or added a bug for you.

Don't convert and change at the same time. Any large sweeping PR that changes a whole area of TypeScript is a hard thing to review and it's especially hard if you also introduce run time changes to it. So I highly recommend keeping those separate. If you see a change you really want to make for TypeScript, just jot it down, save it for later. Resist the urge. Just be even just compassion for your code review or someone who now has to go through your PR and QA changes in addition to perhaps even learning TypeScript. That's a hard ask. A lot of the engineers, especially around TypeScript, don't like taking shortcuts. They don't like intellectual shortcuts. I should say. They don't like doing things the wrong way. TypeScript engineers have this phobia of writing the word any because they think it makes the code less good. Maybe you just have to any cast, like we were using Redux, which is fine. Redux on its own is a beautiful, very type system compatible system. But when you have all these integrations, like we do, Redux actions, doggos, thunks, it becomes really hard to type out.

9. Final Thoughts and Resources

Short description:

It took us literal months of work to get on the same typings version for Redux due to interconnected dependencies. We still any cast a lot of our Redux code in TypeScript. Celebrate your victories and make a big deal out of converting to TypeScript. Check out TypeScriptland.org and CodeCademy.com for resources on TypeScript. Thank you for listening!

It took us literal months of work in the background to get just on the same typings version for a Redux because of all the weird interconnected dependencies. And we're still any casting a lot of our Redux code in TypeScript because we just don't have a time or interest in getting it 100% right. So just any cast, it's fine. The choice between any casting and not converting to TypeScript should be pretty clear that you just any cast and save it for later. Opinions.

Lastly, definitely celebrate your victories. We spent a little office budget on this cake and it was a very fun little morale thing of, oh, we did something great. We converted to TypeScript. We finished. And it was back in December. It helps signify to the team when you do something cute and memorable at the end. I highly recommend make a big deal out of it. If the hype train, as you might have called it, finishes its trip, celebrate it landing into the station for some analogy. Ironically, I think the cake was actually vanilla at the end.

Anyway, a few resources that might be useful for you. The TypeScriptland.org website. Shout out to our friend, Orta, is really good. It has a lot of great docs, explains a lot of good stuff around TypeScript. It can help guide you as a new implementer, experienced user, as a converter. We actually ended up writing a course on TypeScript, which I helped co-lead in the inception, CodeCademy.com, learn TypeScript. I highly recommend, I'm a big fan. And then each of the integrations that I mentioned, Babelius Lynch's webpack has its own guide to using TypeScript because it's so popular. So highly recommend going to those. Anyway, thank you for listening to me. I have been answering questions in the chat as they come up. And you can always tweet at me or see my contact info on my site, both of which are joshuakagleberg. Thanks.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.