How Typed is Your Framework?

Rate this content

We are slowly getting to a point, where TypeScript-support is a must-have feature of a framework and not a nice-to-have. But this is not a simple yes or no question. Let's take a look at the different framework areas where TypeScript can help you develop quality applications.

25 min
22 Oct, 2021

Video Summary and Transcription

Today's Talk focused on the importance of TypeScript in preventing runtime errors and its integration with popular frameworks like Vue.js, Angular, and React. TypeScript provides error assistance and typing boundaries between components, ensuring correct usage. It also allows for the creation of generic components, leveraging TypeScript generics to define contracts between unknown properties. The Talk highlighted the use of TypeScript in various scenarios, such as working with React Node, and provided resources for further learning and exploration.

Available in Español

1. Introduction to TypeScript and React

Short description:

Thank you for having me. Today, I want to show you some code snippets and discuss the importance of TypeScript in preventing runtime errors. I will also talk about how typed React is compared to other frameworks. My name is Andreas, and I'm a development leader from Dresden, Germany. Since 2016, we have migrated all our projects to TypeScript and have become great fans. Many popular frameworks now offer first class TypeScript support.

♪ Thank you very much for having me. You cannot imagine how excited I am to be here today. It's fine that the slide is black, it's all good. Hello, everyone, as well to everyone who's watching remotely. I hope you're enjoying the conference.

Before I'm going to introduce myself, I want to show you some small snippets of the code and ask you one simple question. Does this look like fun to you? When we take a look at this, it looks innocent enough. We push it to production, run our code and run into this beautiful runtime error. Uncaught reference error, route is not defined. Of course, those runtime errors always show us the little line where the error happens in our code. So easy enough, we can spot that we just made a small little typo there. So, of course, we fix the typo, call it a day, push the code to production, go into the weekend, and, of course, Saturday morning, the client calls and tells us it's still not working. We ran into another runtime error.

Errors like these are exactly the reason why TypeScript has risen in popularity over the last couple of years. Because, of course, the main promises, those type of problems and errors will never appear at runtime if you're working with TypeScript. So you're going to your tech lead and convince him to convert, to migrate your complete code base all the way to TypeScript. Because maybe it's an older project and you're still working with class components and we're even using legacy APIs, like the legacy StringRefs. So as you can see, this is already TypeScript code, but they are still the same runtime error. Here we are passing a StringRef down there to the div to get a reference to the HTML node and at the string root. And we access this at the top with this.refs.root, but again with the same typo. As you can see, only because we are using TypeScript it does not guarantee that we will not run in any runtime errors. It depends on the framework, it depends on the APIs that we are using how safe we really are. And this is exactly the topic of my talk that I'm going to give to you now. How typed is React really, and how does it compare to other frameworks?

But first, I'm going to introduce myself because I guess most of you won't know me. My name is Andreas and I'm from Dresden in Germany and I'm a development leader at a small agency. And something around 2016, we started off migrating our first project to TypeScript and since then we have been great fans. So every new project that we are starting, no way we are starting with JavaScript, it has to be TypeScript or else we are out. And I guess many of you or some of you are sharing a similar journey. And this rise in popularity has led many of the popular frameworks to add a sentence like this to their documentation. We offer first class TypeScript support.

2. TypeScript in Frameworks

Short description:

TypeScript is a first class citizen in our framework. Vue.js and Angular have embraced TypeScript, offering better experiences. React, while stagnating, still benefits from TypeScript. TypeScript supports us in the basics and helps with errors and suggestions. It can also crash the build pipeline for typos. When using more features, TypeScript allows for typing boundaries between components.

TypeScript is working out of the box. First, the TypeScript is a first class citizen in our framework. Funnily enough, maybe you saw it already, yesterday they released the newest version of the React documentation as an early beta and I searched the docs and so far nothing like that is in the beta documentation, but we will see maybe it will be added at a later point in time. Maybe take a look at the popular frameworks.

A lot has changed over the last previous years. First of all, Vue.js when they announced Vue 3.0, they announced that they have completely rewritten the framework based on TypeScript and they are able to offer a much better experience than with the earlier versions of Vue. Angular as well, even if they started with TypeScript all those years ago, they started actually so early with TypeScript that TypeScript was not yet powerful enough to model all those dynamic features that the framework needs to offer its users. Sadly, on the React front, things have been a bit stagnating. But, this is not a problem at all because from the beginning, when TypeScript made the decision to directly support JSX or TSX, we never had any problems with the TypeScript support, so on that front, even if not much has changed, we can still get the benefits of TypeScript in our language.

In the following, I want to take a look at different areas of the framework that can be supported by the framework. At first, we're going to take a look at the basics. So within one component, you have this logic part where you call functions, you define variables, and you pass these logic parts to the template, and this template is then accessing those variables. But this is only the basics, so this really, it's the lowest level of types of support that a framework can offer. The minimum requirement to really be able to help us as developers is when the boundaries between components are typed as well. So the inputs, the data that is flowing into our components and the output, the events that flow out of it, they have to be type safe as well to really bring us any benefits. But let's start with the basics. First, maybe we are not even working with TypeScript, maybe we're still working with JavaScript. TypeScript can already help us in our framework of choice. Here, we maybe reinstalled the React type definitions into our project. So when we type react.use, we get an auto-complete, we get a suggestion of which functions we want to use right there. Later, we migrate our project and then, we're still in the logic part of our component, but already here, the TypeScript can support us and help us and show us errors when we made a small little typo or used a function that does not exist. When we then want to use this data, this logic in our templates, TypeScript again, wants to help us. So here, we define some number and we want to use it in the UI, in the template part and here as well, TypeScript can help us and give us the right suggestions. And as you see on the right, when we access the function that does not exist, again, we see the error in the editor. One very important part is that we don't only want to see the error in our editor because when we write code, maybe we are too fast for TypeScript in the background when it's compiling, sometimes it takes a bit, maybe you already closed your file, pushed to production or pushed to your pipeline and then we want to be able to crash the pipeline if we still have typos in our project. So the framework has to offer a possibility so that we can run the type checks with the command line tool. Luckily, because TypeScript directly supports JSX, we can just run TSC, the TypeScript compiler and have the errors crash the build pipeline. In the next step, it can get a bit more complex when we want to use more features that TypeScript is offering us. Like right here, we have our component that receives as a prop and a value x, which is either a number or a string. So of course, we cannot be sure which we got in our use case.

3. TypeScript and Component Boundaries

Short description:

TypeScript forces us to check if the variable x is a number before accessing number functions. Vue.js has a similar feature to catch errors in templates. We can now define type-safe logic and access it in our templates. TypeScript helps us ensure correct usage of components and provides error assistance for inputs and outputs.

So when we directly call the toFixed function on x, TypeScript can offer us this help for error and tell us it's all good that toFixed exists on a number, but on the type string, the function toFixed does not exist. So TypeScript forces us to first check if the variable x really is a number. And only then can we access the functions that exist on numbers.

This is a feature that has only been added to the other frameworks quite late actually. For example, here we are seeing the equivalent vue.js code. We have basically the same thing if defining a property that is either a number or a string and we're using it in the template. And we are getting exactly the same error as earlier because vue.js, they found a possibility to compile the templates into real TypeScript code and have the same kinds of errors that we get natively by the TypeScript compiler in React.

Now we have the basics down so we can define the logic of our components in a type safe manner. We can access this logic in our templates and have TypeScript help us all the way. Now let's jump into the boundaries between components. Like right here, we have our component B which receives as an input a value x as a number and it provides an output which is again a number. When we're now using that component on the right, of course we want to make sure that we are using this component correctly. So right here we are passing in a string instead of a number, TypeScript can help us there. Same thing with the outputs, we defined that set x is always called with a number so there again we get the help from TypeScript.

4. React Components and Virtualization

Short description:

React components are just functions, allowing us to access the shape of component arguments. We can extract props using TypeScript helpers and component props. This is useful for defining thin wrappers around components and exchanging components in a type-safe way. Virtualization is a technique to render only visible elements in a list.

A very interesting thing is that these kinds of errors are not supported in all major frameworks. For us React developers it's quite natural that if we define two properties, x and set x, then we have to provide these when using the component but this is not a given in all other frameworks. Now we have the basics down and as I said earlier, especially since the latest changes in the other frameworks, they have really caught up with React on that regard but there are still some cherries on top that React is offering us that the others can't or cannot quite easily give us as developers.

First of all, the great thing about React is that components are just functions. It's as the documentation says, it's just JavaScript. It's beautiful assembly. Like right here, we have our button component. Maybe it's even from a library where we have typed props. The problem is maybe this library does not export this interface as an explicit type, but it only exports the component. But because in React the components are simple functions, we can use TypeScript helpers to access the shape of this argument. We can just use the parameters type, extract the interface and extract the type of the button function, and the parameters type will return to us a list of our parameters that our function expects. So right here in our example, a React component always receives one argument, the props object, so we use index zero to extract the props of our button component. So just because the library author decided to not directly export the type of the button component, we can still access it with parameters. However, right now this only works with function components but luckily the React type definitions export a helper type called component props that we can use to access the props of function components, of class components and of the built-in HTML elements.

So for example, right here we are extracting all properties that the native HTML element is allowed to receive. This is very useful to define very thin wrappers around other components. For example, right here we want a small wrapper around the HTML button component where we are able to pass in another property, an icon. So we are just extracting all properties from the HTML button element and joining with the intersection operator, joining some new properties like here, the optional icon prop. In our component, we can then just destructure our props, pass in the icon and use it in our component some way or another, and pass in the rest props down to the button. And the nice thing is that if for some reason HTML adds another property to the HTML button, this still works and it's still completely type safe. So we don't have to repeat all props that are present on the HTML button, but can just take the props from the HTML button and join them into our prop types. We can also leverage this pattern to exchange components in our applications in a type safe way. So here, for example, we have this customizable application. There we are defining as an argument, we want to receive any component that fulfills the interface of our button component. This way, we could build a framework where the buttons are themable, exchangeable, have different behavior, and users of our framework can just apply their own button component, which will be used everywhere in the application. And we still have this in a type safe way. So they have to make sure that their button component complies with the interface of this button props element. Next, we want to take a look at another great feature that we receive by having the components being only functions. Maybe you heard the talk earlier about virtualization. Virtualization is a technique where you don't want to render all elements in a list but only the elements that are currently visible on the screen.

5. Building a Generic Component with TypeScript

Short description:

We build a component that can be used with different types, ensuring type safety. TypeScript generics allow us to define a contract between unknown properties. This way, we can pass in lists of different types and still receive the correct object in the RenderItem function. TypeScript correctly infers the type of our component. The ASPROP pattern is another popular use of this feature.

And here, we are building a small dummy component that is doing exactly that. We defined the interface here with receiving an item count and an item height. This makes calculation quite easy which elements are currently visible in the viewport, and we pass in a render item, render prop, which we can use to define how each element is being rendered in the UI.

Of course, we then have to make some calculations to calculate which elements are currently visible, we're going to skip that for now, and then we are just iterating over the visible indices and call the render prop. When using this component, it looks currently something like that. So we fetch the data, it's a person array in our use case and we want to use our virtualized list to render those persons to the UI. Here, because we defined that the index of render item will always pass out a number, we are working in a type-safe way. So we accessing an index on the person's list and accessing the field name or age.

The problem is that maybe we don't always have a list available. Maybe it's a lazy loading list where we just fetched the data on scroll, it's an infinite loading list, for example, so maybe we don't have an array where we have all persons available. So optimally we want the API to look like this. Render item now gives us a person object and on the person we can access name and age and no other fields, because only these two exist.

The problem is, when thinking about this naively, we might think that we now have to develop a virtualized list for persons, a virtualized list component for cars, a list component for pets, et cetera. And of course, this cannot be the right solution. So maybe at first we are changing the interface of our virtualized list component to receive unknowns or any props. This way, when using this component, you can pass in a list of persons, a list of cats, a list of animals and it will work. The problem is on the output side of things, render item will pass us an item element of the type unknown.

So we cannot use it to access the fields age and name because unknown does not have any fields. So now we would need some kind of a contract that we can use to connect these two unknown properties. And for this, we can use TypeScript generics. So we define this TitleGenericType variable that we can then use to define that items is of any type with TItemArray. And when used with the type person, for example, then we want render item to give us back a person again. So when using this component, we can pass in a list of persons and TypeScript will know that we instantiated the component with the person type and will receive the person object in the RenderItem function. When we hover over this JSX element, we get this tooltip where we can see that TypeScript correctly inferred the type of our component. This way, we can build a component that can be used with different kinds of types. So with persons, cats, cars, whatever. And we're still being completely type safe when using this component.

Another quite popular pattern that is using this feature is the ASPROP. Maybe you've used it in style components or in motion where you can pass in another component in the ASPROP and want to pass in new properties to this new generic component. So like right here, we have this link component which normally renders just in A-Tag maybe in the UI.


Using TypeScript Generics and React Node

Short description:

We can make use of TypeScript generics to define our component and achieve a nice usability. TypeScript support goes beyond defining types in logic and templates. There are many additional use cases where TypeScript can be leveraged in React projects. It's okay to use 'any' within a module, but never let it out. React node is more flexible than JSX elements as a return type. The error messages from TypeScript types can be challenging, especially with GraphQL and code generation. There is always room for improvement. If you have to choose between 'any' and 'unknown', use 'any' within a module and 'unknown' when expecting external variables.

But right now we want to render it as a button element and we want to be able to pass in an additional icon. And here again we can make use of the TypeScript generics and define our component like that. You can see maybe one of the problems when working with TypeScript a lot. The component code, library code starts to look quite complex but we're achieving a very nice usability for the users of our component.

Like right here for example, we define the type variable T-Component. We add this constraint that it has to be a component type. And then we can say that our link component will receive the S-Prop where we can pass in any component and it can receive all props that this passed component wants to receive in the UI. So now I hope that you could see that yes, TypeScript support is good and all frameworks have the basics down of the TypeScript support but TypeScript support is more than only defining the types inside of our logic of our component, inside of our templates, also between on the boundaries between components but also, there are lots and lots of additional use cases where we can leverage TypeScript in our react projects.

I want to say thank you for listening to my talk, I hope that you have some quite exciting questions for me right now. I wish you a lot of fun at the remaining conference and want to say thank you. Thank you so much.

Would you like to grab a seat? We've got a couple of questions and I'm pretty sure that more questions will be rolling in as we go along. So, one of the first ones, and I kind of like this one because I guess it goes against everything that TypeScript is supposed to offer. Is there ever a good excuse for using the any type in your project? Yeah. There absolutely is. So, the only thing that you really never, never, never, ever must do in your projects is letting an any out of a component. So, it's absolutely okay to use an any within one function, within one module, because maybe the types, you're building a lookup object, for example, where you don't yet know all the fields that will be present on this lookup object, then, just slap an any on that, add the fields later, but make sure that the return type of your function is typed correctly. But within a small module, you can just add an any, maybe write a unit test to be absolutely sure, but it's absolutely no problem to use it within a module, but never let it out of the module, because then it will spread like wildfire. Never let any out, definitely.

Next question, when would you use React node over JSX elements as a return type? So, personally, we almost always use React node, because it's a bit more flexible. So, React node is basically everything that is renderable by React, so, not only a JSX element, but also null, undefined, true, false, strings, numbers, and whatever, so, just a bit more flexible. Nice. And, another question, what do you think is the weakest or hardest part of working with React and TypeScript? I think the hardest part is the error messages that types will give you. Especially maybe one of you, you have experience there, when you're working with GraphQL and write a code generator for your GraphQL types, you receive this massive typed object that, yes, they exactly show you what type of field you receive from the backend, but when one field is missing there in your, maybe you pass it to a component, one field is missing, the error message is just, it's so huge and new developers have, or even intermediate developers, really struggle with identifying where really the error is in this typed message, and this can get really quite confusing, and this is something that still needs improvement, as I say. Always room for improvement. And kind of going back to the question earlier about any, which do you prefer to use, any or unknown. If you absolutely have to, obviously you're never gonna let it get out of the component. So, I'd say within one module, element, function, whatever, I'd say it's fine to use any because then you're just free to do whatever you want with that variable. If you have a case where you're expecting some kind of variable from outside, so you're writing your own console log function, maybe, and users can just supply any value they want, I'd use an unknown, because then I can't accidentally use any fields on this data, because I won't know what data is getting passed in. For example, if I write a log function that just says JSON.stringify, then it really doesn't matter.

Approaching TypeScript and Resources

Short description:

When using TypeScript, it's important to think about all aspects from the design phase and avoid making assumptions. For teams new to TypeScript, it's recommended to use existing libraries with strong TypeScript support. TypeScript and React cheat sheets by Shawn Wang are great resources for learning advanced patterns. Understanding the relationship between input and output types can help in solving complex problems. Unfortunately, we have run out of time for questions, but there are other opportunities to ask during the break and join the Spatial Room for further discussions.

So, I just write unknown there and can be sure that I won't access any fields that don't exist. I think it's also good because it's really actually thinking about all of these things from the design phase and not making any assumptions.

Absolutely. Now, you spoke at the beginning about often times there are many people moving from JavaScript over to TypeScript, and how do you recommend approaching TypeScript to a team that is new to use it or has never used it before? So, I'd say, I think Mark Erickson from React, from the Redux team, always makes this distinction about being an application level developer and a library developer. And using TypeScript at the application level is really quite comfortable because you get the autocomplete, you almost never have to specify the types yourself, types that can infer many types. It only gets really complex when writing your own libraries. So maybe I'd say for a team that is mostly of new TypeScript developers, I'd say, use existing libraries, like React Query, like a form library that already has strong TypeScript support so that you won't have to write those library typings for yourself at first. But you can always do that later, of course.

And TypeScript is becoming much more widespread, right? But obviously, there's always new people who are getting started. What are the best resources to go to for people who are coming from, what are the best resources for people to go from basic TypeScript skills to start using some of those advanced patterns that you talked about? So I'd say one really good place is are the TypeScript and React cheat sheets that Shawn Wang has published on GitHub. And other than that, I always recommend, Kenzie Dots has written a blog post, sync state, derive state, and don't sync it, or something like that. And I think this is something that you can really bring into your type, thinking about types as well. Because when you have a type for the type of data that is returned by your API, for example, and you want to map this type to form fields which have a changed field, a touched field, dirty field, whatever, then you have to recognize that this new shape is completely dependent on this input shape, and that you can somehow probably map this input type to this expected output type. And once you recognize that, then you can start looking for solutions of how you can achieve this mapping and learn these more complex pattern on the way. Because that's how you learn new things by solving problems.

Thank you so much. That's all the time we have for questions today, but I can see there are so many more questions. Walk up over and ask him some of your questions during the break that we have after. And also remember there'll be a Spatial Room where you can also join in virtually and have a chat. Can we all give a massive round of applause for Andres.

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

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.