Scaling Components Across Multiple Frameworks


React provides a great ecosystem for React developers, but challenges often arise for multi-team organizations who get to pick the technology of their choice. As teams and projects scale, and technologies change over time, being able to provide a universal component library as a design system for an entire organization proves to be difficult.

Stencil was created to help address this issue, most notably for Ionic, which is a UI library for mobile app development using web-technologies. In this talk we’ll walk through how Ionic is able to create an Ionic React library, using custom elements (web components) as the lowest level. Using the Stencil compiler, the Ionic team is able to generate various bindings for each of the frameworks, such as React, Angular, and Vue.

The benefit of this allows the design team to focus on maintaining one codebase, while the Stencil compiler does the heavy lifting to generate the various output targets. Additionally, end-users of each framework binding get to interact with their traditional component model they’re familiar with. React developers use @ionic/react no differently than any other React component, and the same goes for Angular and Vue.

25 min
14 May, 2021


Sign in or register to post your comment.

AI Generated Video Summary

The Talk discusses how Stencil, a low-level compiler, helps generate and maintain reusable components that work across different frameworks. Stencil enables the creation of self-contained applications by relying on existing web APIs within the browser. It allows components to work in different frameworks without maintaining multiple code bases. The speaker highlights the usefulness of web components and how they can benefit different use cases. Stencil solves the problem of maintaining one code base while working everywhere, making it worth exploring for those in similar situations.

1. Introduction

Short description:

Hello everyone, my name is Adam Bradley, and I'm the Director of Open-source Technology at Ionic, and today I'm excited to talk with you about something that has helped us scale our UI library to many different frameworks. This is a React conference, and in order to scale your components to different projects, the answer is, well, you just use React.

Hello everyone, my name is Adam Bradley, and I'm the Director of Open-source Technology at Ionic, and today I'm excited to talk with you about something that we've been working on that has helped us scale our UI library to many different frameworks.

So this is a React conference, and in order to scale your components to different projects, the answer is, well, you just use React.

So, alright, thank you for attending. Now that we know how to make components work across every single one of your web apps, across your entire organization, because as we all know, for the last 30 years, every single web app has only used React. So thank you for attending.

2. Challenges with Different Frameworks

Short description:

Many large organizations use different frameworks and libraries, and it's important to have a consistent look and feel across all web assets and software. Design systems like Google's Material Design aim to provide a consistent look. To ensure your component library is used by different teams, follow their framework's best practices and guidelines. Challenges arise when using CSS libraries within JavaScript frameworks, but Stencil helps build components that work naturally in different frameworks.

Alright, so I know I didn't fool anyone there. There might be this assumption that an organization is only on one tech, but what you see here is really closer to reality, especially as time goes on and tech changes. This talk is more for developers that are building components within organizations that fit within this category.

The reality is that many large organizations use many different frameworks and libraries and even different versions of these frameworks. Organizations are made up of numerous departments, and within each department, you can come across many different software teams. These teams handle a wide range of anything from content websites, web apps for both mobile and desktop, native apps for iOS and Android, and it goes on and on. And usually, each team gets to choose the framework that they'd like to work with.

So, while teams are choosing the software that works best for them, we very quickly run into some issues managing components with a consistent look and feel. And because different projects are started at different times by different developers using different frameworks, we often run into a lot of problems. It's common, but more of a requirement, really, that an organization creates a design system, basically being able to have a consistent look and feel between all of their web assets and software.

And here are some of the most well-known and widely used design systems. The most notable, I think, would have to be Google's Material Design. But those were just some of notable design systems that look great. The list goes on and on. While not all of us may have some cool fancy name for our UI libraries, or at least not yet, many have the same goals, and that's a consistent look and providing a well-documented UI library for various teams, both inside and outside of your organizations, to be able to use. And something that we've heard devs say many times is that they've created a design system and just expected other teams to start adopting it. But they quickly hit this wall, because other teams simply aren't using the same framework.

So if you want your component library to be used by different teams, then it's best to follow their framework's best practices and guidelines. This means you should be able to provide them components that already work in their framework. And a common theme is to use CSS-only libraries. And then each framework builds a layer on top of that common CSS library. This includes libraries similar to something like Twitter Bootstrap, but rather a custom CSS library for organizations. Now challenges with using CSS libraries within JavaScript frameworks is that the moment that the HTML structure changes or a CSS class change, basically all of those implementations no longer work. And there's this large risk here with trying to depend on a certain version of CSS libraries. This is where the idea of Stencil was first introduced.

And before I get too far, I really want to say that Stencil is not attempting to replace frameworks, or even act like a framework. React and all the others do an excellent job already. Instead, Stencil is a tool to help build components that work naturally in each of the different frameworks. It's to help developers create components that need to work in as many disconnected projects as they can. And to do this, it uses a common component model that all frameworks are built on top of.

3. Working with Multiple Frameworks

Short description:

For a component to work in all frameworks, there needs to be a common layer that each framework interacts with, which is the DOM. The highly standardized document-object model is used by React, Angular, Vue, and other frameworks. The custom element spec allows the creation of components that can be used in different frameworks. Stencil, a low-level compiler, enables the generation of generic components that work across frameworks, including React. Stencil has minimal runtime and relies on existing web APIs within the browser, such as the ConnectedCallback method. By restricting components to browser-provided APIs, Stencil enables the creation of self-contained applications. The goal of Stencil is to maintain one core version of Ionic while supporting multiple frameworks.

So the big question is, but how could that even work? How can one component work in all of the frameworks? So for a component to work everywhere, then at some level there has to be a common layer that each framework interacts with. And no surprise here, the common layer is the DOM, the document-object model. This is the guts to how web pages and webex actually render and update our browsers.

React, Angular, Vue, all of them interact with HTML elements and text nodes to render their components. The part that's often missed is that all these frameworks render apps in our browsers because of the highly standardized document-object model, which is being used by billions of devices as we speak. And I can't even begin to imagine how many times the DOM has rendered a document since the beginning of this slide. Each framework stands on top of this common API, and the cool thing is the DOM can also be extended at the lowest level, which allows us to create components that can be used in each of these frameworks. This brings us to the custom element spec. It's a standardized API that's already built directly into today's browsers. And actually, it's been available without polyfills for a few years now. The ability to have a common low-level component starts with a custom element spec, and it's quite powerful in its ability to execute custom JavaScript for individual components within the DOM. The moment that a defined custom element hits the DOM, whether it's from document.createElement, innerHTML, using React Angular review, or whatever, when that element hits the DOM, the browser will execute the custom element's JavaScript. With that ability alone, Stencil is able to tap into the idea of generating a generic component that can work in all frameworks. And yes, despite a lot of the confusion out there, React can work great with custom elements. The part of passing data to these elements, like passing arrays or objects, is where Stencil Compiler is able to auto-generate the bindings for that, to help solve that problem. And no, I'm not even coming close to saying this is a replacement for React. But rather, I'd like to show how we've been able to build a React component UI library that can also be used in Angular in view, or with no framework at all, by using a common component, and the Stencil Compiler.

Now, relative to a full framework like Angular, React, or Vue, Stencil has very little run time. This is quite similar to Svelte, where components are generated by a compiler and only with the code that they need. And Stencil is also similar to Preact in that it heavily relies on existing web APIs already within the browser. However, one of the largest differences is how... The largest difference from a traditional framework is letting the browser actually notify when an element has been added to the DOM or when an attribute has changed. Now, Stencil components will extend the DOM's HTML element. And because of that, we're able to take advantage of existing APIs baked directly into the browser. And probably the most useful one here would be the ConnectedCallback method. With these features alone, Stencil components are able to manage themselves and really act as their own self-contained application. Beyond that, we've purposely restricted our components to only work with APIs provided by the browser. So to circle back to the original reason why we created Stencil, it was so we could maintain one core version of Ionic while also shipping Ionic React, Angular in View, and whatever comes next. Ionic is a mobile focus UI library for the web. But I don't really want to focus too much on Ionic too much here.

4. Maintaining Reusable Components with Stencil

Short description:

Stencil is a build time tool that helps generate and maintain reusable components. It allows components to work in different frameworks without maintaining multiple libraries and code bases. Stencil generates framework bindings from a common component model, enabling the creation of self-contained custom elements. These elements can be wrapped with framework bindings to create framework-specific versions without the need for additional code bases.

Rather, I want to review our requirements we have as maintainers of the library. It has over 100 components, and we face many of the same challenges as any other team out there. The fact is, frameworks, libraries, and best practices continue to change underneath us. However, the components themselves have stayed relatively the same. Sure, we update the design, we fix bugs, we handle issues, but that alone shouldn't require constant rewrites of each component.

If there's one thing I really want to make clear is that Stencil is a build time tool. It's a tool to help us generate and maintain reusable components. The problem Stencil is solving for Ionic is allowing our components to work in many of today's frameworks, but without having to maintain multiple libraries and different code bases for each of the frameworks. And an added benefit here is that we can also easily adjust to tomorrow's frameworks, or when one of the frameworks has a major break and change. And we can do this all without having to rewrite the component yet again.

A big challenge is that each framework handles assigning and reading properties differently. So while it's extremely well documented on how to assign a property to a React component, the internals of how that work under the hood is completely different to how it works under the hood for Angular and Vue. This is where Stencyl steps in to generate these framework bindings from a common component model. So let's dive into some code and create a progress bar component using the standard component model, and then we'll generate that into the different bindings for each of the different frameworks and show how to use that in each of the different frameworks.

Okay, so let's dive into some code and create a simple progress circle component. So here we're setting the custom element tag name, inlining this style, since this is a simple example, but usually you'd import a CSS file instead. And this component has three properties, size, stroke, and percent, and they act as both properties and attributes on the HTML element. And lastly, we have a familiar render function that returns JSX. Now, I'd love to use a standard templating language here, but the problem is that there's no such thing as a standard templating language, at least there isn't yet. And if we use another custom templating language, we're back to using just another framework. So today, the closest thing we have to standard would have to be JSX, and I think many of you would probably agree. So what we get is a self-contained custom element. Within the Dev Inspector, you can see that it changes around its attributes, and because it changes those values, the render function will execute again. And the same goes for editing the elements' properties. So this component works independently of any app structure and handles itself. This is the part that's really powerful, because now we can wrap this custom element with framework bindings and ship a framework-specific version of this component. But while also not having to maintain an additional code base for every single framework. And this is an example of the stencil config file, where we're able to have the compiler generate numerous output targets. In our case, we're having it generate source TypeScript files in the package's directory for all of React, Angular, and Vue outputs. But it's also generating just vanilla custom elements, and it's creating README markdown files.

5. Component Usage and Framework Bindings

Short description:

The left side shows the internal auto-generated component, and the right side shows the result of that component and how a React developer would use it. With Ionic Angular, we provide Angular components and not custom elements. Angular developers import Ionic and use it in their template just like any other library. The custom element spec has been extremely powerful for Stencil to build framework bindings and ship Ionic in each of the frameworks.

So the left side shows the internal auto-generated component, and the right side shows the result of that component and how a React developer would use it. They would import and use these components no differently than any other React component. So for example, the JSX tag name is in Pascal case, which is just the expected norm for it to use with React components. Whereas a React developer, I'm sorry, with an Angular developer, they'll expect these component tags to be dashcased.

With Ionic Angular, we quickly realized that we needed to provide our users with Angular components and not custom elements. This is how Angular developers would import Ionic and use it in their template. It doesn't matter that the components are actually using component custom elements. To Angular developers, they're using Ionic no differently than the rest of their libraries. This includes inputs, form controls, host listeners, and all the other Angular APIs. And I'm not trying to convince everyone to hand-code custom elements instead of React or Angular, but I certainly can show how that custom element spec has been extremely powerful for Stencil to build framework bindings so that we can ship Ionic in each of the frameworks.

6. Component Styling and Optimization

Short description:

The most challenging part about a component is its styling. Shadow DOM has been great for Ionic, but there are constant improvements and changes to avoid breaking changes. Between Ionic v4 and v5, there was a major design update. Stencil can generate various outputs and apply heavy optimizations. TypeScript is used to gather metadata and apply optimizations. With Stencil, a json file can be generated that includes metadata about every component in the library.

Now we talk a lot about JavaScript patterns in each component model, but honestly I think the most challenging part about a component is its styling. Just like having to find a common denominator for the component model, we also need to land on a styling that works everywhere, too. Luckily, the web standards has us covered here again, and shocker, it's something called CSS.

Now from what I've seen out in the wild, there's this love it or hate it aspect of Shadow DOM. I think the big discussion is that Shadow DOM is great for some things, but it's not the end-all solution for every single component problem. And in my experience, Shadow DOM has been great for Ionic especially since many apps depend on it and develop against our API. At the same time, we're constantly making improvements and changes to Ionic, but avoiding large, breaking changes in HTML structure and CSS classes. This is a challenge Ionic has since we're used by so many external projects.

A stand-alone app, on the other hand, that isn't sharing components doesn't have the same use-case as something like your design system. Think of the past major version updates for a CSS library. If the HTML structure ever changed or CSS class name changed, then its framework implementations often broke. Between Ionic v4 and v5, there was a major design update to closely follow material design in iOS. What I'm proud of here is how the many components had a major rewrite at all levels. But the user wrote these components in their apps no differently between v4 and v5. There wasn't specific HTML or CSS classes that they needed to change.

And stencil output targets go beyond just framework bindings. Using the same idea, the compiler can take information from each component and build various outputs. For example, it can auto-generate documentation and component data. It can also create components that can be pre-rendered on Node.js. The compiler is able to apply heavy optimizations after static analysis. And it does this by TypeScript walking the AST of each component. Every bit of metadata is then used to customize the run time and allow the run time to only use what it needs. And not only is it able to apply optimizations, we can use that information to auto-generate docs. The source of Stencil components uses TypeScript, and under the hood, TypeScript has many great features, one of them being custom transformers. In the before custom transform, we're able to gather useful metadata about each component. In the after transform, we can take that metadata and apply some optimizations to both our run time and user components. And there's no shortage of great doc-site generators. First one that comes to mind is DocuSource. With Stencil, we can generate a json file that includes metadata about every component in the library. This includes documentation for props, attributes, events, listeners, CSS variables, and many more.

7. Closing Remarks

Short description:

You cannot go wrong with choosing React. It's an excellent choice for app development. Stencil solves the problem of maintaining one code base while working everywhere. If you have a similar use case, Stencil may be worth exploring.

So you're free to take this auto-generated data and plug it into any system, or you can just have Stencil auto-generate readme files, which work great inside of GitHub or npm. So to close this all out, you really cannot go wrong with choosing React. It's an excellent choice for app development. But what Stencil is solving is a little bit different. With Ionic, we wanted to maintain one code base, but work everywhere and be able to adjust quickly. If you have a project that has a similar use case, then a project like Stencil may be something to take a look into further. I want to thank you for your time, thank you for having me, I had a blast. Hopefully you try out Stencil and let us know how it goes. Thank you.

8. Web Components Survey Results

Short description:

The audience survey results show that 45% of them have heard of web components but haven't tried them yet, while 20% have tried them and plan to use them in production. This positive feedback indicates that people are recognizing the value of web components. Despite the historical tension between React and web components, the speaker aims to highlight the usefulness of web components in their talk and how they can benefit different use cases.

So let's see, we have asked our audience, what is your experience with web components? And 45% of them is the winner. They have said heard of them, but haven't tried. But do want to. And the runner up with 20% tried them and planning on using them in production. What do you think of these results? I think that's pretty positive. That's actually a lot higher than I thought it'd be. So that's cool, that's cool to see that people are kind of seeing the value of it and things like that. So I think that's a good, positive feedback. Yeah, that's always nice to hear that you made an effort to build something and people want to use it, of course. Yeah, right. Yeah, I know. But this is pretty cool because, you know, traditionally React and web components are usually, you know, button heads. And however it played out, you know, how a certain dev rel has happened for the two of them, it's been interesting. But what I tried to do in the talk was kind of, like, see past all that and try to just lay out, like, how it's been useful for us and how we use it and things like that. So hopefully people can also kind of see, like, how our use case helped us out and it might be able to help out their use case, too.


Using Stencil for Different Use Cases

Short description:

For a company doing React development with a self-contained web app, going all in on React is an easy choice. However, if you're creating a UI library or a design system with shared components, Stencil is a better fit as it allows for future-proofing and versioning. Stencil is particularly useful for large organizations and for scenarios involving micro front-ends. It enables the building of logic in different frameworks while maintaining consistent components. The next question is about the compatibility of Ionic and other web component-based frameworks in a micro front-end architecture where each integrated front-end app uses a different version of Ionic. The speaker acknowledges that this can be an issue due to the global nature of Custom Elements.

Yeah, well, talking about use cases, that's a nice bridge to our first question, actually. The question is from Frazili Shchalkov. And the question is, do you think it's still valuable to use stencil in the use case where a company's only using one framework, so probably React in our context, for all of their front-end projects? Can you give an example that proves why it's still valuable? Yeah, that's a tough one to answer because that's, like, trying to, you know, predict the future of what framework will be around for the next 20 years or something like that. And so I think if this was 2012, we'd all be saying, well, Angler.js is the way to do things. That's the best framework that everyone's using. My entire company uses Angler.js, so let's go all in on it and let's do everything with that. But as you know, times change, and React came out and Vue came out, and none of it got spelt, so it's difficult to predict the future, which is a lot of why we created Stencil for ourselves was that Ionic needed to keep adjusting. You know, and I guess I go over this again and again inside of the presentation. So because we had to keep adjusting, we needed to go to the lowest level of a element, you know, and that's just a custom element. And so through that, we're able to adjust for the future, you know, and able to adjust things like that. So for a company that is only doing React development, like if you're doing just a Web app, you know, with three other developers, and this is a self-contained Web app, and it's not sharing any of the components with any other Web app, things like that, then I think it's an easy choice to go with all in on React, because it's really not the same use case of what Stencil's trying to solve, whereas if you're trying to create a UI library, a design system that this Web app's going to use, the one that the marketing team, you know, in Europe is using, the one that the sales team in America is using, if there's all this shared components, that's where Stencil's a better use-fit for that, because then it's more future-proof in that you can adjust, like all these different components can stay to a certain version. There really is no version when it comes down to it. The compiler has a version, and a compiler can do different things, but for the most part, those components aren't versioned, and that's a good thing, because you don't know if they're using Backbone and they're stuck on Backbone, or if they could be using the latest React 25 or something like that. It's a tough one to answer, and I think it really comes down to your use case and how you're going to be doing your components. In our case, if it's something like a design system, then a design system for a large organization, then I think Stencil is a good choice for that. Yeah. I think that kind of tears it down for me. I was talking to Adam a little bit before, and the use case where I was trying to sell it to the company I was working at at the time is that we were working with a lot of micro front-ends. So it's one big web app with micro front-ends. They all used React. The whole team used React. But we don't know if we still are going to do that in five years, right? So maybe in five years you want to create one of these micro front-ends in Svelte or whatever new fancy framework comes out by that time. Then it would be really easy because they just have to build the logic, but all the front-ends, like the components, are there. And that's what I think really is the power that people can use Stencil for by being kind of future proofing themselves. Yep, exactly. Yeah. Awesome. The next question is from Zandro. Does Ionic or any other web component-based framework work in a micro front-end? When each integrated front-end app uses a different version of Ionic, the web components are global so they may overwrite each other. Yes, that is an issue with Custom Elements is that window.defineCustomElement is a global.

Clashes and Framework-specific Binding

Short description:

There can be clashes if there are numerous versions of Ionic in an app, but the most recent one will be used. While there may be concerns with custom elements, it is not a Stencil problem but rather a platform problem. The future with Stencil may still require framework-specific binding steps. Ionic initially considered being all Web Components but realized the importance of framework-specific features and decided to support them based on the needs and preferences of each framework.

So Ion-button is there's only one Ion-button that can be registered to that window. So yes, that is an issue. If you had an app that had numerous versions of Ionic, that's where there would be a clash. I will say that I think it's the last one wins, so you could have a couple of them register. The last one is going to be the winner, or maybe it's the first one. I forget. Either way, there's not going to be an error. It's going to use the most recent one.

One thing we do specific with Ionic is put a lot of time and effort into making sure that we're just fixing bugs, we're improving things like that, we're improving the design. But the API itself, the properties, attributes, things like that, aren't changing. So speaking for Ionic, you know, I think that would be safe. There's always, you know, the challenge of breaking versions between the different things like that. But, yeah, I think that's a valid concern with custom elements and what things could happen. But also, you know, you don't really want to have many of the same design systems, many different versions of the same design system running on the same webpage. Hopefully not, but I guess once your company and thus your project grows and you have overlap of teams and the team members leaving, extra team members coming, then it can get tedious to maintain, I guess. Yeah. Yeah. And I do know that they are addressing this in the standards, but it's just nothing that's used today. Okay. So we'll have to wait for that problem to be fixed. But that's not a Stencil problem. That's a platform problem.

Next question is from Alex. Is there a future with Stencil where we don't need to have the framework-specific binding steps? Web Components seem so promising as a write-once-use-everywhere solution for our components, but it still seems like we have ways to go before it's really easy to get going with them, specifically talking about the page with React.

No, I do think it's going to be a ways yet until you can go without them. One thing that we did start with Ionic Angular when we first started this project around 2017 was that it could be all Web Components. It wasn't even going to have the Angular bindings. And we started with that during development, and we quickly realized that people are going to be expecting the output decorators and input decorators and having NG model work and all the Angularism things to actually work as they expect. And so that's where we kind of decided we can't just go all in on Web Components entirely because people still want to use Angular how they want to use Angular. So it kind of comes down to each of the frameworks and how much they are willing to adopt it.

Benefits of Custom Elements and Stencil

Short description:

A custom element is just a div with callbacks that can be hooked into any framework. Stencil allows adjustment to framework improvements and changes without altering components. Ionic developers can maintain their components without making any changes for years.

Luckily, a custom element is really just an element. It's just a div that has callbacks for the most part. And so we can hook into any framework because they're all using the same DOM. So, yeah, I do think there's going to be a ways yet. But that's kind of the point of Stencil was that we can adjust to all of this. So like as Angular keeps improving or Angular keeps reducing sort of their footprint of what they're using, what they're not using, we can just keep adjusting the compiler. And then for us as Ionic developers, we're not having to change your components at all. We're still just maintaining the same one four years ago.

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
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 Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick
easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data
use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time

React Summit 2023React Summit 2023
24 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Workshop Free
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
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.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Workshop Free
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 Summit 2023React Summit 2023
171 min
React Performance Debugging Masterclass
Workshop Free
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 🤐)
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Workshop Free
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

React Summit 2023React Summit 2023
152 min
Designing Effective Tests With React Testing Library
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents
- The different kinds of React application tests, and where component tests fit in
- A mental model for thinking about the inputs and outputs of the components you test
- Options for selecting DOM elements to verify and interact with them
- The value of mocks and why they shouldn’t be avoided
- The challenges with asynchrony in RTL tests and how to handle them
- Familiarity with building applications with React
- Basic experience writing automated tests with Jest or another unit testing framework
- You do not need any experience with React Testing Library
- Machine setup: Node LTS, Yarn