Testing Frameworks, Mobile Frameworks, and Browsers Love Developers and Testers

Rate this content
Focusing on being where your users are isn't as difficult as you think. A lot of groups out there will tell you that their tool is the best and that even though none of your users use that browser or mobile setup it is fine. In this talk, David will talk about all the differences that come up, why browser vendors are even telling folks not to focus on browser engines or virtual doms, and how the setup of development environments is simple to set up these days.

By ignoring the love that is being pushed to developers and testers through the work being done there can be tests that are passing but your users are failing to use your application! Don't worry, David will have the real world examples to show you how broken things are :)

27 min
07 Dec, 2023

AI Generated Video Summary

Today's Talk covered various topics including testing frameworks, browsers, and the challenges faced in testing complex systems. The importance of improving testing setup and productivity was highlighted, along with the principle of least surprise and the need for framework upgrades. The Talk also discussed the different browser engines and their unique features, as well as the benefits of sharing ideas and approaches within the software development community. The session concluded with insights on browser testing and the use of tools like Playwright and WebKit.

1. Introduction to Testing Frameworks and Browsers

Short description:

Today, I'm going to talk about testing frameworks, mobile frameworks, browsers, and how the people behind them love developers and testers who use their products.

♪♪♪ Hi, everyone. My name's David. And today I'm going to be talking about testing frameworks, mobile frameworks, browsers, and how each of the people who work on those love developers and testers who use their products. The reason why I know this is, as Nathaniel said, I've been kind of in the industry for a while. I've spent nearly a decade working on Firefox. I've been doing browser automation for nearly two decades. And so every time I see these things and come to these conferences and see what people are doing and showing, all I see is kind of the love that they care and want to improve everything. And I want us to kind of care about it. I want everyone in this room to go, actually, it's nice to see that they care.

2. Challenges in Testing and Simplifying Approaches

Short description:

Testing is hard. The systems we're working against are incredibly complex. We've got browsers, web apps, and multiple layers through the entire system. Numerous people have tried to simplify testing with terms like the testing pyramid, unit testing, and integration testing.

And so we're going to start with something I think is kind of a tree. Testing is hard. Whenever we look at how we, like, want to do our jobs, we start with testing and we go, actually, you know what? Testing is very, very hard. People build careers out of it, right? And they still go, I have no idea what I'm doing. And it's okay.

And the main reason why testing is so hard is that the systems we're working against are incredibly complex. We think about JavaScript. It's an asynchronous language. We've kind of been doing this. But whenever we think about testing, we think sequentially. We want to go from this step to this step to this step. So years and years ago when I started my career, there was callback hell. And you tried to do it and you hoped that things would run in the right time. The language has improved and it's got much, much better. But then we've got other things that kind of get in the way. We've got browsers. We've got web apps. We've got everything from multiple layers through the entire system that we've got to test. And we think about how we go about doing it and we go, actually, this is really hard. But, we've had like numerous people think about how we approach these problems. And they've tried to simplify them as they go along. And they've come up with kind of cool terms like the testing pyramid, unit testing, integration testing and so on. And I'm going to break it down. Because I think it's important that sometimes words matter. Sometimes I don't think they matter so much.

And so like with the unit testing, this is where I think people get a bit too fixated, but they've tried to break down the problem into something small. And it's a small test. Because sometimes people can't do it at a unit level. And we've got these integration tests where we test our contracts. And this is where we start to see some of the kind of real love that people have.

3. Testing Tools, Frameworks, and Browser Complexity

Short description:

We get tools like Mocker and VTest that allow us to test in JavaScript. Testing front-end frameworks is challenging due to their complexity. Different browsers and mobile browsers add to the complexity. The Chromium team's changes to Headless browser show their care for developers. However, frequent upgrades can be frustrating.

We get tools like Mocker and things like that have kind of grown, and newer tools, VTest, that have come out to allow people to do it. Testing in JavaScript when I started my career was a lot of just manually clicking, making sure that things worked as we anticipated. And it wasn't that easy.

And then we've got cool tools that are coming out that allow us to kind of think slightly bigger, but not as big as an end-to-end test. And we've got those component tests. We've seen the market exploding with people trying to test their front-end frameworks, which are really hard to test because they're complex. They've got their own complexity built in.

And then we've got these medium to large tests, as I like to call them. And the medium to large tests is, you're at least starting up a browser, but you're not doing a full end-to-end test. And then we've got our end-to-end tests. And so it's got all this complexity. And then you throw in different browsers, right? I've only just shown Chromium variations here, but you've got Firefox, you've got Safari, and then you've got mobile browsers on top of it. And this complexity is something that everyone starts thinking about, but when it comes to the case of actually solving it, improving it, doing that work, it's very hard. But there's bound to be someone who cares and wants to do it.

But we've got all this complexity. So we've got our frameworks, we've got browsers, and sometimes browsers are not always the browsers that we expect them to be, right? At the beginning of the year, the Chromium team said, oh, by the way, Headless is not what you think it is. Headless is a totally different browser in Chrome. So all your tests that you've been doing, thinking you've been doing the right thing, maybe it's not actually true, and we're sorry about that. But we fixed it, right? So, sorry about that. So now, not only have you got Chromium variations, Headless browser that you're thinking about, and you're trying to improve your tests, and it's not going the way you want. But this is a first sign that the Google team actually care about us. They've seen the problem. They've gone, actually, this is causing more problems than we care for. So let's go fix it. And this is another sign that our developers love us.

But then, we go straight from them loving us to them hating us again. Upgrading every four to eight weeks, right? When I started at Mozilla, the year before Firefox 3.6 had been released, I am that old, and we were six months out from Firefox 4 being released. Mozilla decided to have this wonderful all hands group where the whole company gets together. And at that stage, Mozilla was about 350 people. So we were small.

4. Shipping Chromium and Increasing Release Frequency

Short description:

They invited a Googler over who announced that they would be shipping Chromium every 12 weeks to accelerate the pace of the web. Internet Explorer had given up, while Firefox was growing. The Chromium team recognized the need for speed and has since increased their release frequency. The eight-week release cycle avoids holiday periods to ensure smooth operations.

They invited a Googler over. The Googler gave a talk to the whole company, and he said, by the way, by the way, we're going to be shipping Chromium, because Chrome was new on the market. We're going to be shipping every 12 weeks. The web's not moving fast enough. We need it to move faster. Internet Explorer had kind of given up. And they were kind of just doing what they needed to at a bare minimum. Firefox was kind of growing, building things. And then the Chromium team were like, yeah, we need to do this faster. And it's only got faster since. The eight weeks is normally around Christmas time or kind of July 4th, when the U.S. teams need to have a break, and they don't want to be shipping then, because if something goes wrong, someone's going to have to work through the holiday periods.

5. Improving Testing Setup and Enhancing Productivity

Short description:

Tooling nowadays allows you to easily set up a new project, including devices and browsers. Puppeteer, Cypress, Playwrights, Nightwatch, JS, and WebDriver I-O have all focused on simplifying setup and improving the testing experience. Frameworks like Reacts now provide a standard way to set up projects, making it easier to get started in the JavaScript space. These improvements aim to enhance productivity and address the challenges of working with asynchronous languages.

So, I've talked about a bit of love from the developers, the Chromium developers, but where's the love for the testing community? Like, where are we seeing those things that kind of make our lives easier, better, faster, more productive? And where are we seeing those items? And we see them with tooling nowadays that is kind of allowing you to like, I need to set up a new project. How do I do that?

So, setting up devices, setting up browsers, right? I've been working on Selenium for about 16, 17 years, right? In one form or another. In that time, we never said, gave you the tooling to kind of download a browser, set that up, mostly because kind of making sure that was consistent everywhere was hard. And open source projects are mostly run by volunteers. There are a few exceptions, but setting those up was hard, but we tried to do everything else in the meanwhile. So, we worked with the W3C and got drivers and we standardized everything and got those into place. And then we got setting up the dependencies. I'm sure you've all seen like with component testing, we want to make sure that you have everything you need. But frontend frameworks have their own specialties. So, it's all about kind of download this, download this, not knowing when to do it.

Puppeteer famously started this with like, actually we'll download the Chromium for you. We'll make sure you can download, run on your first go. You couldn't do that with Selenium, not unless you already had a browser and you knew how to start up that browser. But there was a bit of complexity there. We've seen it grow with Cypress and Playwrights, Nightwatch, JS. I work on that now. WebDriver I-O, they've all gone actually, let's set up everything and improve it. So, they might not tell you that they kind of care for you, love for you, but their actions are starting to show it. And we've got to the stage where we can improve things.

So, in this case, like MPM and Nets, we see it with Reacts and other projects nowadays, where you can just go, I would set me up a project. You could do it. So, the picture on the right, if you can't see it, it's fine. But the last three lines is like, do you want to do end-to-end testing? Do you want to do component testing? Do you want to do mobile web or mobile app testing? And then you answer a couple of questions. You tell us where we're going to run it, and we go run it. And we make sure everything's in place. We give you example tests. This has now become a standard way for frameworks to set everything up, because getting started in a JavaScript space is hard, because we think sequentially, and we try to do everything sequentially. And we try to solve these problems in a language that's asynchronous and doesn't always work sequentially in the way we want it. And so it tries to improve these things. The other thing that's kind of trying to be improved along the space is the principle of least astonishment.

6. Principle of Least Surprise and Framework Upgrades

Short description:

The principle of least surprise is important. Framework upgrades can break tests, causing frustration for users. Upgrading small parts through tooling should be possible to ensure confidence and progress.

Or I preferred the principle of least surprise. So when you get something, you should intuitively know how to use it. If you work on it, like if you go to a mail client and you want to send an email, it should be obvious that there is a compose button or a new email button, right, things like that.

If you're working in an API, you should be able to kind of just go do this, dot, do that, dot, and it should just allow you to move it on if you wanted it that way, or you just kind of go, I think this is how I need it. I need to pull this information out. And it should be intuitive to do that.

Where some frameworks have started failing down, and this is mostly when it comes back to how Selenium never allowed you to download and always forced you, other frameworks were like, we'll download it for you, is that upgrading those browsers nowadays means you have to upgrade their framework, which then can cause other problems, but it's not necessarily because they don't love you, it's that their lovers could be shown in a different way. And so sometimes upgrading the framework can break your tests. I know I've seen this before with Puppeteer users. They were like, I'm stuck on a very old version of Puppeteer because every time I upgrade it, my tests break. I just can't handle that. I don't have time to fix my tests. And so you should be able to, through your tooling, whatever, be able to upgrade small parts, have the confidence and move on.

7. Browser Engines and Frameworks

Short description:

Browser engines don't equal browsers. Different browsers like Brave, Opera, Vivaldi, and Edge have their unique features. Selenium Manager helps update drivers for Chrome, solving the pain of compatibility. The Chromium team created Chrome for Testing to provide a standard way of tracking bugs. Frameworks like Nightwatch.js set up simulators and emulators for mobile testing. Scaling on mobile and desktop browsers both have their challenges, but frameworks and tools show care and love for developers, and most of them are open source.

And this is where, kind of, it's a bit of a hobby horse of mine at the moment. Browser engines don't equal browsers. If you think back to the Chromium slide earlier, we had six different Chromium versions there, right? If I go speak to Brendan Eich, who's the CEO of Brave, he will tell you one or two things that's the same as Google Chrome or Chromium, but Brave is unique. Same with Opera, Vivaldi, Edge, right? They all take their different things. So how do we go about solving this? So in the Selenium space, which I spend a lot of time in, we've got tooling like Selenium Manager. This is how the Selenium project is trying to show you that they care, is that you want to update your drivers for Chrome because Chrome driver has to use the Chrome debug protocol, which changes with every version of Chrome. And you need to update that. What if we just took away that pain, solved it for you? The other thing that people have, that we were seeing, is that, like, the Puppeteer team were getting frustrated with the way people were raising issues. This bug is happening with Puppeteer in Chromium. And they would go, well, I can't reproduce this in Chrome. And so what they did, the Chromium team, was they created Chrome for Testing. And Chrome for Testing is to stop you using Chromium in your testing environment because it's not meant to be used as a test browser because there's no way to go from I've got this bug and track it all the way back to the commit that caused that bug. Because things are changing so fast in that code base that it's nice to have a standard way to do it. So Puppeteer, Selenium, things like that, they use it. And it's come through collaboration, improving what we want, that people start caring. And then it comes down to the other side of it, right? Shrinking desktops is not mobile. It's a bit controversial for some people, but it's true. And the main reason is how operating systems render web pages. They get complex, things like that. If you spend some time with a Chromium developer who's working on Android, or Firefox engineer working on Android, or Safari engineer working on iOS, it can be hard. But the way frameworks are starting to show people that they care and love for you is that we see this hard problem, we'll set it up for you. So one of the projects that I work on, Nightwatch.js, it sets up simulators and emulators for you if you want to test on mobile. And it's not relying on Appium to do things if you care about just the web. Because Chrome driver, Gecko driver, Safari driver, they work well with mobile browsers. So let's use mobile browsers. I will give you one thing, scaling on mobile is hard. But scaling up on desktop browsers is hard too, just in a slightly different way. Maybe a less expensive way, but it's still hard. And so people are giving you their love and giving you the frameworks and the tools. And all of most of this is for free nowadays, thanks to open source.


Sharing Ideas and Framework Approaches

Short description:

One of the benefits of being an MC is I get to ask a question first. Are there any ships that you see that just enter the station, leave the station, then come back around again, that maybe we should just start just putting them in place permanently? The JavaScript space seems very fickle sometimes. The old guard frameworks are still growing. The uniqueness of the web brings something always moving forward, not necessarily going in a circle. We've got a couple of questions coming in. The first one is asking about a different framework. What do you think is different between the Nightwatch team's approach compared to other front end end-to-end frameworks like Cyprus or Playwright?

I think one of the things that would be awesome for people in this, like around the world, is to share their feature ideas. I think I would like this or that. This is the pain points I'm having regularly with your framework. There's a lot of noise that comes into a lot of frameworks and projects. But when there's someone going, hey, I love this idea, could you help me make it? I'm pretty sure every project that you use would be willing to help. So share your ideas, because sharing your ideas is you showing your love back.

And with that, I've come to the end of my talk. Thank you all. So yeah. One of the benefits of being an MC is I get to ask a question first. A question that I've kind of been wondering is, like you said, you've been in, especially browser automation for over 20 years, right? So you've been here for a while. You've seen a lot of ships come. You've seen a lot of ships go. Are there any ships that you see that just enter the station, leave the station, then come back around again, that maybe we should just start just putting them in place permanently?

I, not really. I think the interesting thing that is happening is that the JavaScript space seems very fickle sometimes, right? And, but when you look at it, some of the things that are always there, the kind of the old guard, are still there. They just might not get the publicity that they were getting, say, five, 10 years ago. And so kind of like if you just went on pure sentiment, people will tell you that like, oh, Cyprus and Playwrights are growing and they're doing this. They are growing and they're fantastic tools, right? But at the same time like the old guards, Lenium, things like that, they're still growing like 25% quarter on quarter, right? And so I don't see things like that. The things that I have seen are kind of how people approach the problem. So sometimes it was like, oh, we can just inject JavaScript into the page. That'll be good. And we started with that originally with Lenium and kind of went away from it. Cyprus then brought it back. And so it causes some problems, but it doesn't. But it's the uniqueness of the, kind of the web brings, there is always something moving forward, not necessarily going in a circle. Yeah, totally. Always moving forward, I like it.

Okay, so we've got a couple of questions coming in. The first one is asking about a different framework. So what do you think is different between the Nightwatch team's approach compared to other front end end-to-end frameworks like Cyprus or Playwright? This is a cheeky addition to the question.

Testing Frameworks and Browser Testing

Short description:

Nightwatch and Playwright speak through the backend of the browser, making it more realistic. Headless testing is not recommended for CI/CD pipelines as it may miss bugs that occur in specific browsers. Using headed browsers as much as possible helps avoid surprises and track bugs. When working with server requests, the testing pyramid is a useful concept.

Why is it better? So, the way kind of like Nightwatch and WebDriver are kind of core philosophies, be where your user is, right? So if you're going to test, do component tests, make sure it's in a browser, not using jsdom, because like that actually causes other problems. And it's like that Chromium versus Chrome problem that can kind of come up and you have these differences.

The thing that I think kind of like Nightwatch is, personally, I think Nightwatch is better than Cyprus because Cyprus uses like, the way it speaks into the browser is using older technology like the Selenium RC. And if you write any JavaScript in a page, you're bound by the sandbox in the browser because it's a security system, right? It's trying to keep everyone safe and it's not necessarily designed for automation where the way like Nightwatch and Playwright do it is that it speaks through the backend of the browser and go, hey, can you manipulate these things for us? And then it's more realistic. And so in that case, I think it's really good. I think there's a lot of similarities between like Playwright and Nightwatch and especially with the work that's going on in the W3C for like WebDriver Bidi to standardize some of those basic ideas so that Mindwatch can improve as it goes forward and be standard.

Can headless replace? No, I don't think it can. I've been in the camp that was trying to tell people when people moving to headless, same with Richard Bradshaw from Ministry of Test or ex-Ministry of Test was that like headless is not where your users are. Like it's great if you're locally developing and you don't want to see browsers popping up all the time, right? Like that can be annoying. And so it's cool. But like the minute it goes into your CI CD pipeline should be where your users are, same browsers, whatever. And you have a matrix and you just build and test through it. And you should do that as much as possible so that you can catch bugs, right? So like my favorite like browser engine versus browser bug was one where a couple of years ago, IndexedDB was broken in Safari, right? Like really, really broken. But if you were testing and like playwright with WebKit, you would never hit that bug because WebKit didn't have it, right? And then iOS Safari didn't have it either. But it was only on desktop, right? And so you had this weird bug that your CI CD would have been passing. And this goes against to me, the principle of least astonishment or least surprise, right? Like you shouldn't be getting surprises like that. And there's no way to track it back. So I'm very much use headed browsers as much as possible, but I do understand there's trade-offs, right?

And we're working on browsers and someone asks, especially with the way the web works, like, we're gonna have requests from the server. So should we have mock requests from a server or not? And why? I think the testing pyramid here comes in very quickly.

Testing with Playwright and WebKit

Short description:

If you were testing with playwright and WebKit, you would never hit a bug that only occurs on desktop. The principle of least astonishment suggests using headed browsers as much as possible. When it comes to requests from the server, the testing pyramid suggests using mocks for component tests and avoiding them for end-to-end tests. The balance lies in having quick feedback loops and not relying on mocks everywhere. Chrome for testing is expected to stand the test of time, providing a deterministic browser experience while still keeping up with updates through tools like Puppeteer and Selenium Manager. There is no time for more questions, but David will be available throughout the day and in the speaker's discussion room.

But if you were testing and like playwright with WebKit, you would never hit that bug because WebKit didn't have it, right? And then iOS Safari didn't have it either. But it was only on desktop, right? And so you had this weird bug that your CI CD would have been passing. And this goes against to me, the principle of least astonishment or least surprise, right? Like you shouldn't be getting surprises like that. And there's no way to track it back.

So I'm very much use headed browsers as much as possible, but I do understand there's trade-offs, right? So. No, totally, yeah. And I love the path of least astonishment. I will be using it again. In the future. And we're working on browsers and someone asks, especially with the way the web works, like, we're gonna have requests from the server. So should we have mock requests from a server or not? And why? I think the testing pyramid here comes in very quickly. Like when you've got your end-to-end tests, don't use mocks, but if you're doing component tests, do mocks, right? Like put everything in. Make those tests as fast as possible because you really wanna fail as fast as possible, right? Like ThoughtWorks decades ago, when they brought out their CI, the pipelines, they were like, yeah, builds should take no longer than 10 minutes because people like get distracted, right? Like mobile phones nowadays, people are like, oh yeah, it was cool building, let's do this. And it's like, oh wait, I've wasted an hour, right? Like having those quick feedback loops definitely have mocks and then kind of, but it's a balance. Don't do it everywhere. No, totally.

All right, we have time for one more sneak question, which is especially about the test of time. Do you think Chrome for testing will pass the test of time? Is it not better to be where your user is, which in my opinion is kind of the point of your talk, right? Yeah, so I do think it's gonna stand the test of time, right? Like when it comes to testing, we need, I'm trying to think of the right word here. We need to kind of make sure that our tests are deterministic. That's the way I was trying to think of, right? Chrome for testing allows for determinism, but you can still, it's going to be the same Chrome that ships, but they kind of have, they've taken the auto updater out and then they, so you're using what your users are and now you don't have the auto updates, but then tools like Puppeteer, Selenium Manager, things like that, they should be updating those as things go along. So you're kind of keeping where your user are, but you've also got a deterministic browser on your system. Now, totally. All right, we don't have time for any more questions. However, you will be able to find David throughout the day. And also he will also be at the speaker's discussion room later on. So definitely walk up and say hi and ask any other questions that you have. But let's give him one more round of applause. Thank you.

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 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 Summit 2023React Summit 2023
23 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
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
I'll dive into the internals of Nuxt to describe how we've built a TypeScript-first framework that is deeply integrated with the user's IDE and type checking setup to offer end-to-end full-stack type safety, hints for layouts, middleware and more, typed runtime configuration options and even typed routing. Plus, I'll highlight what I'm most excited about doing in the days to come and how TypeScript makes that possible not just for us but for any library author.
React Summit 2022React Summit 2022
23 min
Let’s Talk about Re-renders
React is a fantastic tool to implement complicated applications fast, we all know it. But are they going to be fast when implemented fast? Let’s talk about re-renders and their danger in react: how easy it is to make a mistake, why some small mistakes can have a huge downstream effect, and how to avoid and prevent them.This is a deep-dive type of talk, that focuses on why React components re-render, what kind of performance impact it can have, and what to do about it

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
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 Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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
Prerequisites- 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
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. 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.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced