JS Nation

JSNation 2022

The Future of Performance Tooling

♪♪ Hey, folks. My name is Adi Osmani. I'm an engineering manager working on the Chrome team at Google. And today we're going to talk about the future of performance tooling. You may know me from the intranet for posting about DevTools features and talking about performance. But I've gone through the pandemic the same way that everybody else has. It's been a long pandemic. There have been a lot of folks recently announcing they have new jobs. I too am excited to announce my new position. It's the fetal position. I've been in it for some time. I'm probably going to remain in it right after this. The last two years were a good dry run. Now, as I mentioned, I tend to talk a lot about things like JavaScript and JavaScript bundles. But today I wanted to take a step back and focus on user experience. Now, users often experience web pages as a journey. And there's a few key moments to it. There's, is it happening, is it useful, is it usable, and is it delightful? Delight can mean making the experience more pleasant through adding things like animations. Now, as I mentioned, I love sharing DevTools tips. And one thing a lot of folks don't know is that DevTools actually has an animation inspector built in. Here it is in action. You can use it to modify the timing of animations, delays, duration, and so much more. Here it is working against a page transitions app by Sira Drasner. I love the animations inspector. It's one of my favorite features. Now, sometimes folks will ask, well, are there efforts to bring such APIs to the platform? Jake Archibald had a great talk about a new page transitions API. And here's a cool demo of it built by the community. So we have a shared element transition here. We're clicking on a URL. It's taking us to a page. We're going back and you'll see that both the URL bar is changing as well as giving us these beautiful animations. Now, there's a lot of work left to do to support things like page transitions in the animation inspector. But we can already see things like being able to play back these animations and see all of the different kinds of motion we are adding to our pages. Really powerful stuff, and I love it. So onto our main question. What does the future of performance design look like? What does the future of performance tooling look like? Now, I think it's three things. I think it's user-centric, actionable, and contextual. Let's start off with user-centric. Now, in the last few years, Chrome has talked about the importance of focusing on user-centric performance metrics, such as the Core Web Vitals. Now, the Core Web Vitals are three metrics. They're largest contentful paints, first input delay, and cumulative layout shift. This covers loading, interactivity, and visual stability. Now, these are great. We recommend checking them out using real-world data in the field or in the lab. But there's a lot more that we can do to bring how we think about performance closer to the user experience. Now, there are probably a set of core user journeys that you care about on your site these days. This isn't something that lab performance tooling or the tooling that we use on our laptops has really fully acknowledged just yet. Instead, we focused on things like initial page load performance. This continues to be really important, by the way, but it's a story we've told in a few places, like in Lighthouse and in DevTools. But we're evolving our understanding of user experience all the time. Now, if you look at the Core Web Vitals metrics, some of them are already thinking about that post-load performance, including things like layout shifts that might happen after the initial page has settled. Your largest contentful paint can change. And there are so many factors that play into here, like whether you're an MPA or an SPA, like do you have a soft navigation? Are you prefetching or prerendering? What's your caching strategy? A lot of nuance here. And so I would like us to think about user flows. Now, a user flow is a series of steps a user takes to achieve a meaningful goal. This is one of the best definitions out there, and it's by Alexander Handley. Now, a user flow usually begins at a user's entry point into an experience, and it ends usually in them completing a particular task, like completing a signup or placing an order. Here are a bunch of different examples of flows. You could be doing things like trying to purchase a product, going through the phases of finding what you want, customizing it and so on, until you add it to your cart and check out. You could be onboarding. You could be trying to create things or cancel a plan. Now, the way we've thought about measuring the performance of these types of experiences is usually by slicing them into URLs. So we'll say, well, what's the page load performance of step one, of step two, of step three, rather than reasoning about them in the aggregate or in the whole, the way that a user experiences them. And I think that there's an opportunity to do something to bring this much closer to what the user feels. I'm happy to share that we've added support for user flows to DevTools and Lighthouse. This is a big deal. We've been working on it for some time, and I'm really excited to walk you through it. It all starts with the DevTools recorder. So here's the recorder that allows us to measure performance across an entire journey. I'm going to start off with an add to cart flow. I've got our commerce experience. I'm browsing categories. I'm adding some things to my cart. Maybe I want to use the search feature to find a T-shirt. So we're going to do that. We're going to customize some colors. Then we're going to proceed to our checkout. Now here I can hit stop, and you'll see that all those interactions were captured by DevTools, including the selectors that were involved. I can now replay that flow. I don't have to go and tell each member of my team to do it themselves. I can hit replay. It's going to go end to end. And there we go. We've checked out. I can measure the performance of this flow. So we've got a measure performance button here. It's going to replay the entire flow, generate a trace of the end to end experience. And here we have it. We're in the DevTools performance panel, and I can zoom into any part of that experience I want to optimize. We can also export flows to Puppeteer in case we're writing tests. And we want those tests to also reflect what we're doing. So here I am. It's generated me a Puppeteer script. We can also use these Puppeteer scripts with Lighthouse for some bonuses. So in this case, I'm using a Lighthouse feature. It allows us to annotate things like time spans and snapshots. And via Puppeteer, I'm able to get this new report, this flow report. This allows us to visualize all of those different steps and see audits for parts of the experience that might need a little bit of work. Now in Chrome Canary, we've continued iterating on this support. The recorder panel now also allows you to import and export user flows, including using JSON. This addition makes it really trivial for you to be able to commit your user flows to your GitHub repo, share it with members of your team, share it with QA. And it's going to be really powerful for your sharing story. You can also do things like edit user flows for their selectors and timeouts, just in case things take a little bit longer than you might expect. Also in Canary, we have Lighthouse panel support for flows. So you can select a time span, you can hit start time span, and begin interacting with that experience. This is the first time we've allowed you to interact while Lighthouse has been running. So you can interact with this experience, you can customize your product. And then when you're done with the part of the flow you want to measure, you can hit end time span. This will go and it will generate you a part of that flow report. And we can use it to discover things such as, do I need to do a little bit more work on my cumulative layout shift? Because maybe there was some layout shift that happened during my interactions. This is really powerful. You can find it in Canary, and we hope you'll find it useful. Now, another question we had after working on flows was what if you could use flows with other tools? I'm happy to share something very experimental, very exciting. I love using WebPagetest, and the WebPagetest team put together a handy DevTools recorder to WebPagetest scripts repo that you can check out. So let's say that I've exported my flow to a cart.json file using one of the previous steps. I can use this with this script. This is what the output kind of looks like. It's not that interesting, but we're just going to skip ahead. And let me show you what this enables. We can paste this into our WebPagetest run, and now I can reason about my entire user flow. I get performance insights for my navigations, for my clicks. I get film strips. I can see the visual page load process for any of my steps. I'm able to scroll down. I'm able to use any of the great WebPagetest waterfall features for understanding bottlenecks. All of this is really, really great and gives us a step towards tooling interop, which I'm really excited about. Here, for example, we can see we've also got features like the WebPagetest videos, which I love using. Now, another question that we ask ourselves is what about cross-browser testing of flows? Maybe you know where we're going with this. So Cypress.io is a user-friendly test automation tool for end-to-end testing. It's great for things like UI testing, regression suites, integration, and unit testing. Now, the Cypress team has a special new package that can export Cypress tests from Google Chrome DevTools recordings. Let's say we take our cart.json once again, and I want to run it with Cypress. I'm going to use the recorder conversion package on my cart.json. Let's go ahead and say we've got that done. We're going to now run Cypress. Let's see what happens. So npx cypress open. It's going to open up a Cypress window. I can select a browser here. So I'm going to select Firefox. Our users.spec.js is the converted Cypress script. And here I am with the flow I recorded using Chrome DevTools, and it's playing back my whole flow in Firefox. This is so cool. I'm able to go to all of the different steps and sequences that were involved in this flow. I can debug, you know, what cross-browser might be working well or might not be working well. And it's just really powerful that you get this kind of cross-browser interop almost via such tooling. It's really, really cool. Now, if you happen to have a Cypress account and you have an API key, you can do things like use record to persist your flow recording to your Cypress dashboard. So here's an example of that. I am going to just go and show you something I did earlier. Here we've got our add to cart experience, and we can see what we just, you know, we're demoing. Here is a video of that experience. I can share it with others. I can play it back. I get the same kind of Cypress experience I would get if I was custom, you know, creating these flows myself. So really, really powerful stuff. I hope you'll check it out. Next up, we have actionable. Now, I mentioned earlier that I was excited to announce my new position. This is also kind of how I look when I'm looking at performance traces in DevTools a lot of the time. I love DevTools, by the way. Now, when people often look at the timeline, the performance panel, they find it daunting. They almost want to cry. I sometimes cry when I'm looking at the performance panel. Did you know that there are something like 17 muscles that get activated when you're crying? 17 muscles. It's great for fitness. Yeah, I've been doing some of that during the pandemic, too. I'm not going to lie. Now, when you're looking at the performance panel, you've often got a lot of data here. Here we've got a long task. And if you've ever wondered why time to interactive isn't great, it's often because long JavaScript tasks are keeping the main thread busy. Now, a good piece of life advice is if JavaScript doesn't bring users joy, thank it and throw it away. I'm pretty sure this is from a Marie Kondo special. She didn't say, in fact, say JavaScript. But I think this is good kind of evergreen advice. Now, we've been doing work to try and making sure that tools like Lighthouse are as actionable as possible for the web vitals. And if you haven't checked out Lighthouse recently, we've got all sorts of audits that can help you do things like identify your long main thread tasks or what your large layout shifts are. And we try to make this experience quite visual and try to pinpoint exactly what DOM nodes you might want to pay attention to. Now, we talk about interaction readiness quite a lot. And I wanted to talk to you about input responsiveness for a moment. So what is responsiveness? Responsiveness means understanding how quickly web pages respond to user input. Now, this can mean things like when I try to open the menu on a website, how long does it take before anything actually happens? Or if I'm trying to add something to my cart, how long does it take before I can actually see that my item has been added? These are all important steps in a user flow. Now, we've been working on a new interaction readiness metric. And we call it Interaction to Next Paint. This is a new experimental responsiveness metric. It measures runtime responsiveness, full interaction latency, and includes things like taps, drags, and keyboard input events as well. The way this differs to first input delay is that it measures the whole input latency from when a user interacts until they actually see a visual response, not just the initial delay on the main thread. In the lab, total blocking time is a pretty good proxy metric to be looking at. We find it correlates pretty well with Interaction to Next Paint. One of the nice things about this is that it's automatic and out of the box. Interaction to Next Paint is a field metric primarily and can vary depending on what interactions a user is making. This is one of those reasons it's great to use things like user flows, because it lets you know what the key interactions are. Now, what we find is that 70% of users have an experience that's terrible where responsiveness is concerned at least once a week. This is really, really a big opportunity for us to do better, especially given that UX research says that ideally it's 100 milliseconds you should be looking at for expected input latency. And we find that on desktop, users load twice as many pages if they experience good responsiveness there. So lots of reasons to be optimizing for these metrics. As these metrics have been rolling out, we've also been able to share more concrete guidance. So for example, if you're using React 18 and you wrap your UI in suspense boundaries, you can make hydration non-blocking, because it happens in slices instead. This can improve things like your total blocking time. And I'm looking forward to even more concrete guidance for optimizing metrics like total blocking time and IMP coming out before long. Now, we've been working hard on introducing IMP to many of Chrome's tools, starting off with PageSpeed Insights. So the first thing I'm going to show you is a new feature called Fast Crux. This gives you instant access to field data. You'll see that I just hit Analyze. This isn't sped up. And you've got instant access to field data. And we'll then progressively load in your Lighthouse diagnostic data so you understand where you can improve. So IMP is already in PageSpeed Insights. Next up, we have Lighthouse, where we've got that time span mode. I'm going to interact with one of Google's more interactive experiences, Google Flights. And here, I'm going to show you that I'm performing a number of interactions. I've sped this up a little bit. And we're going to end our time span here. And what this gives us is a Lighthouse report that's inclusive of interaction to NextPaint. We can scroll down, and we can see that we have a brand new audit called Minimize Work During Key Interaction. This includes our input delay, processing delay, presentation delay, as well as all the other audits Lighthouse typically gives you for reasoning about long tasks and JavaScript performance. Finally, we've worked on tools like the Web Vitals extension, which I know a number of folks like. This also now has interaction to NextPaint. Now, on the debugging performance side of things, people have been using the Performance Panel for years and years. And it actually started out in a place where it was a little bit simpler. Over time, we added flame graphs and the ability to reason about call stack depth. But it trended a little bit towards tools that browser engineers used for performance debugging. Could this be better? We've got a preview of something we've been thinking about. So I'd like to introduce you to the Performance Insights experiment. This is available as a preview. We hope you'll check it out. And feel free to share feedback. And finally, we have contextual. Now, we introduced a feature called Stack Packs, which allows Lighthouse to display stack-specific suggestions. We know that a lot of people are often using frameworks or CMSs when they're building things out. And so we've been hard at work making sure that Lighthouse can start to give you slightly better context if you're using a modern stack. Here's an example. So in an application that's using Next.js, rather than just saying you should be using a modern image format, we'll tell you that you should be using the Next.js Image Optimization API to serve modern formats like AVIF. Rather than telling you to just lazy load your images, we'll tell you to use the Next.image component, which defaults to loading equals lazy. Really powerful stuff. Really great contextual stuff. We'll also do things like tell you when you should maybe be considering splitting your JavaScript bundles using React.lazy, or using a third-party library like Loadable Components. Now, a parting thought is that improving performance is a journey. There are lots of small changes that can lead to really big gains. Step one might be an outline. Step two is definitely not this. You're not going to suddenly solve all the world's problems. But you might end up similar to where I usually do with performance, which is step 1.5. It's fine. It's a result of iteratively investing in improving your user experience over time. And you'll eventually get to something closer to this. But this is actually OK. It's still pretty. Users are going to thank you for an improved performance experience at the end of the day. So I hope you got some value out of this talk. I think that the future of performance tooling is user-centric, actionable, and contextual. I've been Adi Osmani. Thank you so much. Thank you so much.


Addy Osmani

DevOps.js

DevOps.js Conf 2022

pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript

Hello, my name is Zoltan Kochan and today I'm going to talk about pnpm, which is a fast disk space efficient package manager. Before that let me introduce myself, I'm Zoltan Kochan, I was born and raised in Ukraine, I currently live in Ukraine as well, for now I'm safe. I work remotely for Bit, Bit is a company that helps developers to component based development. Before Bit I worked for JustAnswer for 9 years and in the meanwhile, since 2016, I'm constantly developing and maintaining pnpm. Before talking about pnpm let's briefly talk about other JavaScript package managers. The most popular Node.js or JavaScript package manager is npm, which is the official package manager of the npm registry. It is shipped by Node.js and in the past npm had a lot of issues, like it was slow, it was undeterministic, it was giving funny results sometimes, so some alternatives were created. One of the alternatives was created by Facebook, you probably heard about yarn, which is the second most popular package manager after npm. It is now maintained by the community and it did solve a lot of the issues that npm had in version 3 and I think version 4. Since then in v2 yarn has switched to use plug and play by default, so even though it does support classic node modules installation, now it prefers and recommends to use plug and play, which many love and many hate. I personally think it's a cool feature. And yarn is currently shipped with the latest version of Node.js through the corepack tool. And the third most popular package manager is pnpm. It is a completely indie project, it was created by open source contributors to fix the issues of npm version 3, at the same time as yarn 2. pnpm is not a new project, it exists since yarn exists basically. And now it is supported by bit, because I work at bit and pnpm is heavily used in the bit CLI for package management. And pnpm as well is shipped with Node.js through the corepack feature of Node.js. If we compare these package managers by popularity, obviously npm is currently the most popular one, then yarn and pnpm is the less popular, even though pnpm came out at the same time as yarn. But of course Facebook had a lot of marketing power to make yarn very popular at the start. However, even though pnpm is less popular for now, it had a big spike in popularity last year. So in 2021 pnpm was downloaded three times more than in 2020. And we have a lot of big tech companies that already use pnpm, so even Microsoft uses pnpm in some of its projects, and the TikTok frontend team uses pnpm. So pnpm works really well and is production-ready for sure. Let's see what makes pnpm unique. So when you install a dependency with npm or yarn classic, all the sub-dependencies are hoisted to the root of node modules. As you may see in this example, even though only express is in the dependencies, all those other packages are also hoisted to the root of node modules. On the contrary, pnpm is only put in express to the root of node modules. So even though cookie is not a dependency of your project, importing it will work. This is a dangerous situation. Your package will work locally fine and it will even work when you install it as a dependency. But what will happen if a new version of express comes out and cookie is not in its dependencies anymore? Your package will break. pnpm prevents such mistakes. With pnpm your code has only access to packages that are declared as dependencies of your project. But how is pnpm able to create such an isolated node module structure? In this example you see express is a direct dependency and cookie is a dependency of express. As you can see only express is placed to the root of the project's node modules folder. And cookie and actually that express inside node modules is just a symlink to a folder inside the.pnpm folder. This works because when searching for dependencies the node.js resolution algorithm is using the real location of the package as a starting point for searching its dependencies. The real location of express is inside the.pnpm folder. So node.js will search for cookie in the dedicated node modules folder which is at.pnpm express at 4.17.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. Let me show you a quick demo. So I have an empty project. I run pnpm add express. Installation is completed. Let's see what we got here. Okay, so ignore this. This is something we hoist by default to fix some issues. These types, but you can see that express is only hoisted. And it is a symlink. The relocation of express is here. And here are, in this folder, also all the other direct dependencies of express. So you can see here cookie. But cookie is actually a symlink to a dedicated folder, isolated folder for the cookie dependency here. So actually cookie is here. And this is a symlink to cookie. Like also this, this is also a symlink to this folder of the accept package. So this is the relocation of accept. And these are the dependencies of accept. So you can see that each package is in its own isolated folder with its own dependencies. Let's return to the slides. pnpm has also very, very good monorepo support, thanks to its superior node module structure. The hoisted node module's directory structure is even worse in a monorepo. In a monorepo, when a hoisted node module's layout is used, all dependencies of all projects are hoisted to the root of the monorepo. Hence, projects have access even to dependencies of other projects. So in this example, there is a monorepo with two projects, foo and bar. foo has one dependency, dep of foo. As you can see in its packages.son file. And bar has also one dependency, dep of bar. So if a hoisted node module is used, both dependencies are hoisted to the root of the monorepo. So foo has access to the dependency of bar. And bar has access to the dependency of foo. If you accidentally require the dep of bar in foo, this code will work locally. But foo will break when installed as a dependency outside of the monorepo. So this is even worse than in a single project scenario. Because in a single project scenario, it might break in the future, but in this case, it will break after the first release of the package. With PMPM's isolated node module structure, projects have access only to their own dependencies. So in this example, we have a monorepo. PMPM creates a single.pmpm folder in the root of the monorepo. And projects of the workspace link only their direct dependencies. So both foo and bar have access only to their own dependencies. So you may ask yourself, why is NPM not using the same approach? Well, actually it will, because they work on a settings to support a PMPM style node module directory. But the reason they don't use it as a default is because some tools don't support symlinks yet. Like for instance React Meteor. And many packages, also many packages in the ecosystem are basically broken because of this hoisted node module's architecture. And they rely on undeclared dependencies. PMPM actually has a solution for these cases, because PMPM is actually able to also create a classic node module without using symlinks. And with classic hoisting, just set the node linker setting to hoisted and you have a workaround. PMPM also solves the disk space usage issue. If you have many Node.js projects on your computer, you may have noticed that node modules consume a lot of your disk space. PMPM solves this issue by using a content addressable storage. A content addressable storage is basically a storage that saves files under hash code, which is calculated from the content of the file. So you can see in this example there is actually a code file in different versions of the same package. But even though they are different versions, the code file is the same. It has no changes. In this case, this file will have the same hash in every package, so a single file will be created for it in the store. So even though you have three packages, you save this file only once, in one place in the disk. Every file in node modules is just a hard link to the content addressable storage. Actually, on systems that support it, not hard links are used, but copy-on-write files. Probably on Macs and some newer Linux file systems. These files don't consume additional disk space, they are just references to files in the store. It means that if two projects on your computer have the same file in node modules, in both projects that file will be linked from the same place on the disk. You won't have two copies of the same package. You will just have hard links to the global content addressable store. As a result, dependencies in new projects consume a lot less disk space than with npm or yarn. Now let's talk about... Oh, I have one slide mixed, no problem. So why other package managers don't support the content addressable store? Actually, yarn has added support for a content addressable store as well, but for now it is an opt-in feature. I think in the next version, before they plan to make it on by default. Now let's talk about why pnpm is so fast. In most cases, pnpm is faster than npm and yarn, but why is it so? npm and yarn install dependencies in stages. At the first stage, all the packages are resolved. Then all the packages are fetched from the registry. And when all packages are fetched, the dependencies are written to node modules. On the other hand, pnpm runs the installation stages separately for each dependency. So while some packages are still being resolved, others are already being fetched. And later on, some packages are written to node modules, while some others are still being fetched. This makes pnpm incredibly fast, faster than other package managers. So you might ask why other package managers don't do the same. Actually, some of these speed optimizations are possible only thanks to the unique deterministic node module structure created by pnpm, inside the.pnpm folder. Some of these speed optimizations are possible thanks to the usage of the content addressable store. And some of the optimizations make the code of the package managers hard to understand, so it's a trade-off. If you choose to make these optimizations, it will be harder to contribute to your package manager. The last feature I guess I want to talk about is that pnpm is bundled to an executable. So you may use it on your system, even if it doesn't have Node.js pre-installed. And then you may use pnpm to install Node.js and switch between different versions of Node.js. So basically you can use pnpm instead of nvm, nvs or volta. So which package manager should you use? It depends. You should know about every package manager. You should know about the features of pnpm, yarn and npm. All of these three package managers are mature, are used by big tech companies, have many contributors and are reliable. So you really need to learn what features they provide. And on each project probably you should pick the one that best fits your needs. Thanks for attending my presentation. Of course visit the pnpm website to get more information. Follow the pnpm.js Twitter account and follow me on Twitter as well. Thank you. That was pretty interesting. Loved all the details that you shared. So thank you for that. So you asked the question, how are files from the content addressable store linked to Node modules? And the results are in. So 63% people say using symlinks while 38% say hardlinks. So what do you say? It's something that many people by mistake think that we use only symlinks, but in reality we use both symlinks and hardlinks in pnpm. And specifically for this purpose, for linking files from the content addressable store, we use hardlinks. It's important. We can use hardlinks or we can copy files or we can use copy and write files. But we cannot use symlinks for this purpose because it will break Node.js resolution algorithm. Cool. So 38% of you all got it right. It's hardlinks. So just to expand a bit on it, maybe if you would like to give a short difference between symlinks and hardlinks for the audience. Yeah. So a symlink is basically just a reference to another place on the disk. So basically if a Node module is symlinked, Node.js resolves this location to the file location to the real location of the file. So when it is searching for the dependencies of this module, it's searching from the real location of the file. A hardlink is different. It's basically another file with its own location. So you can have many hardlinks on the disk at different places. For Node.js, it is like separate files. But these files are pointing to the same location on the physical disk. So these files do not consume additional extra space on your disk. Cool. And that is how you make the sequence efficient. Yeah, correct. That's perfect. So let's take some questions from the audience. So we have a question. How difficult is it to migrate the codebase from Yarn to PNPM, for example? If it's just a single package repository, then it's really easy. There is an import command. So you can just run pnpm import and it will convert your log file from Yarn log to pnpm log yaml. And you just need to remove the Yarn file and commit the new log file. And then maybe update your CI scripts from Yarn install to pnpm install, from Yarn run to pnpm run. In most cases, all you need to do is just change Yarn to pnpm and it will work as a drop-in replacement. For a workspace, you need to change how you list the package globs. So Yarn uses a field in package.json and pnpm uses a separate file, pnpm-workspace.yaml. That is the biggest, like almost all of it. It's really easy. Okay. And pnpm as well. In most cases, all three package managers are compatible with each other. Cool. So you heard him. It's not difficult. It's easy. So you can try it. Okay. I had a pretty question. What's the full form of pnpm? What does it stand for? So this name was actually invented before me. The first maintainer of pnpm was Rico Stacrus from Philippines. And it is just performant npm because the first version was faster, like 10 times faster than npm at that time. That's why. That's amazing. That's amazing. So I wanted to ask a question, like how does pnpm like works on computers which might have multiple drives or multiple file systems? So how does this everything works on that? Yeah, so the drawback with hard links is that a hard link can be only in scope of one disk. So you cannot have your content addressable store on disk C and your project on disk D if you're using Windows for instance. So in that case, pnpm creates separate storage for each disk. So if you have projects on disk C, you will have a store for those projects in project C. And if you have project D, you will have a separate store for those projects. Or alternatively, you can use one store, but if the store is on disk C, then on disk C, hard links will be used to that store. But on disk D, files will be just copied. So you won't have the benefits of this space efficiency. That is interesting. Yeah. Thank you for this answer. I do not see more questions, but for the audience, if you still have more questions, you can always ask them in the Q&A channel. And you will get the answers from Zoltan there. And we do not have any speaker room for Zoltan. So yeah, make sure that you ask the questions in the Q&A channel. Thank you once again, Zoltan, for joining us today for this terrific talk and also for answering these nice questions. Thank you so much. Thank you. Thank you for having me.


Zoltan Kochan

React Advanced

React Advanced Conference 2022

Building Figma’s Widget Code Generator

Hi everyone, I hope you're having a lovely conference so far. My name is Jenny and I am an engineer at Figma. I'm based in Leeds in the UK. So for those of you that didn't know Figma had a product team in Europe, now you know. And welcome to this talk on Figma's widget code generator. We're going to be using it to build a FigJam widget and then talk about how it was made. On my screen now you can see FigJam. This is Figma's online collaborative whiteboard tool where I can do things like add a post-it note, I can do some drawing and most importantly for this talk I can add a widget. This can be seen and interacted with by everyone that is in the file, which at the moment is unfortunately just me. And they aren't just restricted to the existing widgets. So to make FigJam files as fun and as flexible as possible there is a public widget API, a component based API quite similar to React which allows you to write your own widgets. And that's what we're going to do now. So I've got, if we go into Figma design, I've got my design for my widget here. It's just going to be a simple voting widget with a button here that you press to vote and that will increase the number of total votes so far and then put your little profile picture into a circle and line them up all along the bottom for however many times you voted. And then also I've got a code editor on the other side and this is the code for what my widget project looks like. Again it's super simple. I'm going to write all of my code in code.tsx and I've got a package.json file with a couple of scripts. The one that we want is watch. So if I run that now, npm run watch, it should start my widget running, put all its compiled code into code.js. And if I go back into FigJam, I can run my widget by going widgets development simple vote. And there we go. It says, hello, I am a widget, which is what the widget function is returning. And I can add some exclamation marks to this and they'll update in real time. So hopefully this widget code is quite familiar to you. It looks just like React using JSX components and some specific Figma layout tags. So I can have an auto layout, I can have a text, I can have a rectangle and loads of other components that are just like things you can create in Figma. So if we go back to our design, if we wanted to start coding this from scratch, we'd have to go through and look at our simple vote layout and see that it's a frame with auto layout set. So we'd have to start adding an auto layout and then we'd have to look at the properties in that auto layout, like the gap of four and put this in as spacing. And you can see it would take quite a long time. So earlier this year, I helped as part of our biannual maker week to create a widget code generator plugin. And if we run that, this is available to everyone on Figma community. So if you just Google Figma's widget code generator, this is something you can install yourself onto your Figma app. But if we run it here, and I'll just minimize this window, run it and click on the thing that we want to get the code for. So our simple vote widget, you can see it generates all of these components for us with a layout that looks pretty similar to the layout of the layers in Figma. And we can copy all of that and paste it into a text editor. It's complaining about avatar, so we'll just comment that out and come back to it in a minute. But if what we've got is a function called simple vote. So if we take this simple vote component and then use it inside our main widget code, go back to BigJam, it's starting to look quite like our design already, isn't it? We've got the gradient, we've got the text, it's all laid out in the right place. But we're missing the pictures along the bottom. And that has probably got something to do with the thing that I just commented out. So if we put it back, it's complaining that it cannot find avatar. And this is because in our design here, frame six, seven, and eight, these are all instances of a component called avatar. And instead of doing this inline and just writing out the code three times, what we want you to do is go to the avatar component and get the code for that and put it into your file just like we did with simple vote. So now we've got a function for avatar and these instances are a bit happier. And if we go back to FigJam again, if you've got really beady eyes, you'll be able to see that there are three faint white circles. That's because they're outlined in white. If we change the outline to red, just so we can see where the circles are, there we've got it. We've basically got our widget. It doesn't do anything though. So we need to add an on click to this button. So when you click it, it will add you to the list of voters, increase that number and put your picture along the bottom. Okay, so in simple vote, how we're going to do that is by storing some state of our voters. You probably recognize this from React. Instead of saying use state, we're going to say use sync state, which is part of the Figma widget API, give it a name and start it off as an empty array. Because this is a TypeScript file, I'm also going to give it a type that I know is going to be user. And then we want to update this voters array when someone clicks on the button. I'm going to make an on click function. And when they click, we want to get your profile as the person who's voted because that's going to let us get your profile photo. And to do that, we can say voter is Figma.currentUser. And Figma here is a global object that is provided in the widget runtime that lets us get things like the current user and loads of other information about what's going on in the file. So now we've got this voter. I know that this voter can sometimes be null. It probably won't be, but just to protect against that, I'm going to say if we don't have a photo, voter, don't do anything. And if we do have a voter, we're going to set voters, get our original list and add our new voter to the list. And our on click is useless if we don't put it anywhere. So we want it to happen when we click on this button, which we can find in the layout because it's called vote button. And all of these tags can have an on click attached to them. So I'm going to put that on click on there. And then we also need to use the voters array to update the number here. So previously where it's had three hard coded, instead we're going to use voters.length. So it's gone back to zero, which is good. And if we click on this button, it will increase every time we click. Nice. But the avatars along the bottom are still staying as three. That's because they're still hard coded here. So instead of this hard coding, what we want to do is map through our voters. And each time we get a voter, we want to return an avatar. Now we've got three. When we click it, we've got four, five. And as well on these avatars, they need to get our photo from user profile. So I'm going to pass in to this. We're going to say it's going to take in a photo URL. Photo URL, again, this could be undefined. So just to keep TypeScript happy, let's set this to an empty string. Avatar at the moment doesn't take in photo URL, but because it is just a function that we've copy pasted from the code generator that takes in props, I'm going to extend these props and say it takes in a photo URL, which is a string. In the design on this component, we can see that it's got an image fill here, which is my very nice little stickman drawing. And this image fill translates to here in the properties and it expects a URL as the source so we can just pass that props photo URL in as the source. And there I am. And we no longer need the horrible red border. We can go back to a stylish white. And if I keep voting, there's more and more and more of me. And we've got a working widget. We can add loads more to it if we want. So for example, like I said before, our avatar component, because it takes in props of the type of its top level frame, in this case, which is just a frame, we could add an on click to this avatar. So when we click on it, I'm removed from the voters. I actually made a remove function earlier. So you wouldn't have to painfully watch me go through how to do a splice on an array. If I add this remove vote here, we don't even need to add an extra prop to avatar. We can just pass it straight in as an on click. If I spell it right, it should remove the vote. It does need to take in an index because it's removing something at a certain index of the array. So we'll just have to update our map to also pass along the index. And now it doesn't happen straight. When I click on my avatar, it will delete me. So if I accidentally vote too many times, I can remove some votes again. Nice. And I promised at the start that we'd go through a bit how this widget code generator works. It is written as a Figma plugin. So it's running in an iframe, in a sandbox with a runtime, a JavaScripty runtime given to it by Figma. And similarly to the widgets, this is using the public Figma plugin API. So there's a whole website full of API reference and everything you'd want here. It's all documented and just waiting for you to build your own plugins with it. It can both read from and write to a Figma file. And like the widgets, it uses this Figma global object that's provided at runtime for you to access everything on the file. But we're not going to go through all of this API documentation together. You can do that in your own time if you want. What I'm going to show you is something fun that if we open the console in the Figma Electron app and get rid of all of the information it says at the moment, what we can do is type Figma and get access to this global Figma object here. So we've got loads of stuff. We've got metadata like the active users. That will be me. We've got functions to create things. We've got functions to access all the styles in a file, all the components, all the images. The world is your oyster, really. If we use one of them, we can say Figma create rectangle. And it's created a rectangle in our file. We can say Figma create ellipse. It's created an ellipse. And then we can also inspect these things in the file. So if we select this and then say Figma current page selection zero, this is one I've done before. Selection is an array, so we just want to access the first thing. We can inspect all of this. So anything that you can access in the Figma graphical user interface, like the auto layout information, the spacing, the width, the fill, the children, we can get all of that via the plugin API. So if we go into children, we can see it's got the frame node, the rectangle node, and another frame node, and drill down right to the bottom in there. And you are probably starting to join the dots here between the information given to us by this plugin API and the generated widget code. It really is that simple that basically we have taken the properties given to us by the plugin API. We've changed some of the names to make them a bit more React-like. So for example, clips content false has been converted to overflow somewhere. Yeah, overflow visible, clips content false. We've got rid of any defaults, mapped them to use the correct tag. So if it's a frame using auto layout, we've mapped it to auto layout, and then added a HTML front end and created a plugin. One thing that is potentially interesting is instances. So like we spoke about before with avatar having its own function and not being defined in line, if we look at frame six here, this is an instance. And this will come through as an instance node and have a main component on it. Main component, which is how we got the name of the thing to use for its instance tag. So main component, and it is an instance of avatar. And then what happens from this Figma design once we've generated the declarative component code, what we've got here, when it's run as a widget in the widget runtime, we'll basically map it back to a canvas node, back to something like we saw in the plugin API, which is why we can get a nice one-to-one mapping on things like gradients or SVGs or things that otherwise could be quite tricky. And this is also why widgets aren't just for FigJam. You can also run them in the design file. Widgets, development, simple vote. Here is our simple vote. And I can interact with it here in the design file. And it looks exactly the same. Cool. So yeah, this widget code generator, like I said before, is available on our community if you want to use it. And thanks for listening. If you enjoyed it, please, please go ahead, make your own widgets, make your own plugins, share them with us, and reach out to me on Twitter if you've got any questions. Thank you, everyone.


Jenny Lea

Understand Your Codebase to Innovate Faster

How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. How to use the Power BI to make your business more secure. So that's giving you my, or perhaps Sourcegraph's perspective in terms of how we can improve developer efficiency by helping people understand your code base more effectively. So, in terms of preparing for this talk, I was thinking about, you know, I've been in sort of software development technology for some time. And I was sort of thinking about the sort of the, I suppose the big changes over the last, well, 10 years, probably more than 10 years, that have occurred and how they're relevant to software development and how we actually deliver software applications, and how we can actually accelerate that process. So there here's my list of five, your list may be different. So, you know, open source software, you know, when I started in software development, essentially, you know, the APIs, libraries you had available to you were essentially the ones that shipped with the operating system, or came with the development tool or platform you'd invested in. Now we have libraries from, obviously, front end, we're at a React conference, of course, to back end in terms of providing databases, search tools, you know, many, many libraries, and perhaps the challenges in terms of deciding what library or framework you wish to use. And of course, there have been big changes in terms of how people go about building out software applications. So we sort of gone away from sort of the kind of big bang approach of sort of the kind of waterfall type of methodologies where we, you know, we capture our requirements, you know, that which takes some time, you know, I worked for some time for a research company, we did a lot of work for large government organizations, we suspend huge sort of requirement documents that we had to either read or prepare. So we've moved to a more sort of iterative approach, we'll be sort of smaller chunks in terms of in terms of the capabilities we want to deliver. And that's great, because it allows us to essentially shrink that loop between building and delivering applications or capabilities, additional functions, and getting feedback from our stakeholders, or clients, customers. So a much more sort of iterative, fast based approach. So essentially, you know, allows us to actually correct direction much earlier in terms of the lifecycle of a particular application or solution. And of course, you know, the move to cloud where we're, you know, again, from a software perspective, you no longer have to worry about getting ahold of infrastructure or networking as sort of kind of a base level, where you can actually go out and get someone to deliver you a database service, or provide middleware on demand without having to actually worry about how to configure or deploy or manage it. And obviously, then in terms of again, that's providing additional building blocks, in terms of actually building and delivering software solutions. And, you know, I perhaps sort of actually say there's a parallel between sort of cloud computing in some sense and open source software. Again, they're kind of fundamentally about sort of providing additional building blocks to allow software developers to sort of focus on their business problems, their business functions and capabilities that actually, that way they can really add value to their customers. And the last two in terms of continuous integration delivery can very sort of align to sort of agile development. Again, the focus is in terms of testing, which you've kind of frequently delivering software, or delivering and deploying software much more rapidly, again, shrinking that loop, but also enabling us to actually test on with smaller changes, getting additional feedback more quickly. Ideally, when you do run into problems, that sort of set of changes that you perhaps have to evaluate in terms of finding the root cause is smaller. And then finally, in terms of service based architecture, so we've got sort of big change in terms of changes in terms of how we actually build software from an architectural standpoint. So from sort of client server to three tier to these sort of multi-service type of applications. And again, where the goal is to improve or increase encapsulation and decouple applications from application logic. So again, making it much easier potentially to make changes within our code, because your changes have less impact or limited impact on other services, etc. Because you're sort of sitting behind some sort of service based API. And that's relevant in terms of front end applications as well, where there's sort of a perhaps a move to sort of allow people to create sort of micro front end applications again, where we have a set of composable application components, which we can sort of stitch together very easily. So I'd say, you know, obviously, all of these changes, initiatives, obviously, have had a sort of an impact in terms of how fast, how quickly we can actually develop software. But if we actually sort of think about the software development lifecycle, it's not sort of one big loop. Many people sort of tend to think of it as essentially an outer loop and an inner loop. So the outer loop is essentially, you know, the releases, the projects, the sprints that we're actually undertaking. So it's more of a sort of a team effort in some sense. And I probably argue that in terms of the five changes we had above is, whilst they definitely actually improve that sort of development lifecycle, they're more focused on that outer loop. Certainly in terms of you think about agile development, continuous delivery. I mean, that's their sort of square in terms of trying to improve the efficiency of that outer loop. But they have benefits in terms of that inner loop. And the inner loop is really around what you're doing as an individual developer. So, you know, OK, I have to make some change to you. I have to add a new capability. I have to fix some problem that appeared within our sort of test suite. There's an incident and I have to investigate that. Or I'm trying to sort of remove some form of technical debt within an application or set of services. So that's really the focus in terms of the actual sort of individual developers when you actually get to that sort of, you know, you're actually writing the code. You're actually closer to the source of the code. And of course, what we all want to do is basically sort of ensure that, you know, we're as efficient as we can within that inner loop. You know, once we have a great understanding in terms of the task ahead of us, once we have some kind of full context, we can really sort of, you know, we understand the tech stack that perhaps dealing with at that point in time. We can be kind of very efficient, very productive. So, you know, we know exactly what we're doing. We can get away. We're in front of our ID and we can actually write our code, test it, iterate and do it in a sort of a kind of a very efficient manner. Obviously, there are challenges in terms of and I suppose the key challenges people face is essentially, you know, interruptions in terms of that, in terms of that flow where you have to sort of switch context. So, you know, most organizations have you, we have sort of planned interruptions where we have, you know, we have meetings in terms of to update people on progress. But we have interruptions in terms of people asking us questions, other members of our team asking us questions. And of course, you know, there may be things we don't understand. You know, we don't have full context. We don't have full understanding. And we have to then go away and actually try and sort of fill in the gaps with our knowledge in order to achieve the task we're looking at. And really, it's in terms of, you know, how can we actually minimize those interruptions so everybody sort of has context and sort of has that sort of kind of, you know, kind of fast flow in terms of how they're writing software. So, you know, it's one of a sort of a cartoon that one of my colleagues pointed me out. So in terms of in terms of actually how we think about how we how we write software in terms of sort of another sort of talking about that that inner flow. So, you know, obviously, when we're writing software, we have some sort of blue sky thinking, you know, we're thinking about how best to write this method, what this class is going to look like, how can it encapsulate, how can we make it make our code easier to read, easier to change, for example. And that's that's great. But the reality is often actually we spend a lot of our time actually trying to understand what before we can actually actually be productive. And obviously that might be really basic stuff like trying to understand something about the language or tech stack you're involved in. I mean, I can remember kind of fairly early on in my career, a real challenge, you know, one of probably my most stressful time I had was actually working on an options trading system. It wasn't core part of our business, but every now and then I would be shipped off to a basement in Zurich or Frankfurt, and I'd have to sit there on a Sunday trying to fix this trading system that had suffered some sort of failure. And I had to get it working by Monday. And the code itself was relatively complex, but actually the changes I had to make were very, very simple. But I could only make those very simple changes once I had a full understanding in terms of what was causing this problem. So I spent my time trying to sort of understand that code base so I could actually make a small change to actually get the system up and running. And that's essentially the reality for many of us. We live in an age of software. Essentially, everything is driven by software in some way. Therefore, there's a huge demand to actually iterate and improve our software solutions, which leads to basically there's a lot more code out there than there used to be. We have many more developers and there's additional complexity. And in terms of if you look at the studies from people like Microsoft, this one's actually from Stack Overflow. In terms of from a development perspective, people spend 75 percent of time trying to understand their code rather than actually writing the code. So, again, really what we ideally want to do is actually sort of kind of change those metrics so we can actually get up and actually write code more effectively. So how can we help people understand their code more easily? Well, this is essentially from a source code perspective, kind of essentially our goal. How can we help people get context, get understanding more quickly so they can spend more time actually writing code? So how do we do that? Well, essentially what we do is we have a universal search platform. And essentially what that allows our customers to do, our developers who are using this platform, is it allows them to actually search across all of their code. So all of their repos, kind of regardless actually from what code host in terms of they're using for source control, but their front end repos, their back end repos, the different services that comprise their application. So they can actually get a better understanding of, you know, help them answer questions essentially. So, you know, how is this service implemented? How is someone using, who else is using this particular component? Who else is using this function or API call back to the back end? How do I use it? You know, helping people actually, you know, get that sort of more complete understanding in terms of so they can actually sort of carry out their development, actually deliver actual application code. So I'm just going to dive into give some really simple examples of how we might use this platform. Now, I'm not a React developer, but if I were, and so for me, what I can do with Sourcegraph, I can actually do some very simple queries. This system here we're looking at actually has about 2 million GitHub repos indexed on it. So 2 million public GitHub and GitLab repos. I know that Formic is a React library. So I can actually just do a very, very simple query to find out where that occurs within my code base. I can actually maybe do a slightly more complex query to actually see, actually a real query in terms of see where it's imported. So which code is actually important that that library within my code. In this case, we're doing a very simple regular expression query to actually show where in that code that occurs. If you want to dig down and actually see, look about, look at specific React functions, again, very simple queries. But again, immediately give me information about my code base in terms of where I might want to go to actually find information about how someone's actually using that function. Of course, from a React perspective, this is very basic. But of course, at that point, it allows me to actually then dig into the code. I can actually now start to look at the other sort of symbols that are defined within this code. So essentially now we're going from not just pure search, but also actually more towards sort of your actual capability you'd expect within your IDE in terms of code navigation. The key difference here is that we're actually doing providing sort of simple navigation across all of your code, not just the repos that you have on your workstation, your laptop that you're using within your IDE, but code that is perhaps lives outside of your teams or code that you don't need to touch very often. So, again, it's allowing you access to that code both in terms of search, but also in terms of code navigation. And in terms of React, we actually use React within Sourcegraph in terms of our UI. Actually, one of the things we did about 8, 12 months ago now was actually change actually how we use React. So we were actually using class components rather than function components. So, again, in this case, what I can actually do is search within, again, this is across all of these sort of 2 million repos, search across where we're using function components. But what we do with Sourcegraph is not just provide the search, not just provide the code navigation, but also allow us to use search to power other capabilities. So in this particular example, we were migrating from one code pattern to another. So what we can also use search to do is actually show us how we're actually tracking, how we're actually monitoring that particular migration. So a code pattern migration in this case. But it may be in terms of how we're actually adhering to best practice in terms of ensuring our code has relevant metadata, or how we're migrating from one library version to another across our code base. So what we can do, because we have all the code, all the commit history that we can search and index, we can actually start to actually create time series views on that code base. So in this particular case, we're showing how the migration from our UI in terms of from a class component to a function component. So essentially, what this is giving us is basically a view in terms of our changing code base. It allows us, if we're sort of responsible for that particular initiative, allows us to actually perhaps make decisions. Is this going as fast as we want? If it's not, why is that? What actions can we take to actually change or impact the rate of change for this particular initiative? And finally, one of the other things we can use search for is actually to help us actually automate changes across our code base, across many, many repos. So in this case, what we're doing is we have a script, essentially, and we're essentially using that script to find out which repos we need to change and then defining a set of steps to actually make those changes across all those code bases. So automating change across multiple repos and then allowing us to actually monitor how those changes are, how those changes are progressing through the relevant CI pipeline and review process. So the goal really is to allow, from a developer perspective, allow us to use a tool to help us actually allow us to focus on higher value work and perhaps more basic kind of code refactors that otherwise may not happen or may require us to actually liaise with many different teams in order to get them to sort of actually make those changes and then accept and review those changes. So kind of a quick tour of the Sourcegraph platform. So I'd just like to sort of thank you for your time. So, again, from a Sourcegraph perspective, our goal is to help improve that efficiency of that inner loop. How can we help developers understand their code, get context, essentially get into flow, enable their colleagues to answer their own questions rather than coming to sort of interrupt you to ask questions about the code base. I'd love for you to actually go to Sourcegraph.com to actually use universal search across two million plus repos. That includes many, many React repos or repos, all the Facebook repos, for example, that are public. Go and try it out. See what impact that has in terms of your own development kind of lifecycle. And I'd just like to say thank you very much for your time.


Simon Waterer

React Summit

React Summit 2022

Improving Developer Happiness with Preview.js

Hi, my name is Francois. I'm a developer happiness engineer from Sydney, Australia. You might be wondering what is a developer happiness engineer? What it means is that I'm a regular software engineer who likes to work on refactoring stuff or fixing flaky tests or making CI faster. But sometimes it's also about creating new tools to make other engineers faster. So one of those tools is called PreviewJS. And I'm going to be talking about that now. You might be familiar with this XKCD comic. I think it was drawn quite a while ago. But it's still somewhat relevant today. I'll give you a few seconds to read through it. So this, I think, was especially relevant back in the days of a lot of programmers using C++ or some other really, really slow language where you had to wait for five minutes, maybe 10 minutes, maybe even an hour for your code to recompile. It's not that relevant today for JavaScript. Or is it? It's actually not that uncommon these days to work on a large code base that uses maybe an old version of Webpack or a misconfigured version of Webpack that takes a couple of minutes to run the build. Maybe even worse, maybe you have to wait 30 seconds every single time you make a change to a file. Which is, if you think about it, when you add that up over a day, every single time you want to see the impact of the code change you made, that's quite a while just spent waiting. And not only is it waiting, but it also breaks your flow. So you're usually going to switch context, going to start doing something else and then you go back and it's just, you kind of lost track of what you were trying to do or whatever was in your mind is just kind of not there anymore. And it's really not very good for productivity or for engineering happiness. So let's take this example. This is a food delivery app that I called Hungry. And it's really just for the purpose of this presentation. So here we have a bunch of restaurants and let's say I feel like some French crepes. So I'm going to say crepes. Okay. There's a restaurant called Creperie François. And I'm going to go there and check out. Okay. So there are some really yummy things. Caramelized banana and chocolate. That sounds good. Fresh and candied orange. Okay. That sounds good. Okay. That sounds good. Okay. That too. Okay. I'm going to get everything. Maybe two of each. Cool. Great. And this is pretty much what you would expect from a delivery food app. And we're in the early days of releasing that to users. And the first piece of feedback that we get is that some users are surprised that sometimes the menu doesn't contain the items that they expected. So that's because sometimes if an item is unavailable, right now the API just removes it from the menu. So let's say this restaurant ran out of chicken. This first item, Kung Pao chicken, will actually be missing entirely. Which surprises users because they're like, well, did this restaurant remove this from the menu forever? Should I just completely boycott this restaurant because they removed my favorite item? But no, that's not the case. It's just unavailable today. And really that's our responsibility as designers of this app to make it clear. So instead we get a feature request from our product manager which says now we should still show unavailable menu items but just make it clear that they're not available. So you know how here we have this counter. Instead of this counter, we'll just say unavailable today, right? This should be a lot less confusing for users. Of course, the first way that we can implement this is by just running the app locally. So we're going to go to our terminal, run Yarn dev and wait a little bit. Okay, so it's running at local host. Cool. I do need to wait a little bit for this to spin up. I'm actually not entirely sure why. But there's something in here that takes quite a while. This is exactly what I meant by spending the time that you spend waiting. Like I might just go on Twitter and completely forget about this and go back here and just maybe have to wait again because I need to reload the page or something. Okay, cool. So that's our app. It's running. Now I need to find a restaurant that has a menu item that is not currently available. So I'm going to go through and try to find one. But wait, I said earlier that the API actually does not return menu items that are not available. So that's not going to work. All of them are by definition available because they're returned by the API. So I have a couple of ways to approach this. One is if I'm myself an engineer who works on the API, then I might change the API to return unavailable items. Although I have to be careful not to return them to versions of the app that don't support that yet. Or if I don't know anything about the API, I'm going to have to mock it out. So I'm going to go into my code base and find the restaurant page. And I'm going to go into that. So that's using this restaurant details page state, which is a MobX state. And really, at the end of the day, all it does is fetch. Okay, so it's fetching that, it's getting the data, it's a restaurant details response. Cool, at least this is well typed. And okay, that returns a menu item, and menu item has unavailable, which is an optional Boolean. Okay, cool. So I'm going to hack this up and say that menu zero dot unavailable equals true. And I'm going to go back to here. And so this first one, because number zero should be unavailable. But of course, we haven't implemented this, right now it still shows the counter. And now, I do know that this component is called restaurant menu item. So I'm going to go in here and say, okay, so here, instead of the counter, we want to say that if unavailable, then we show unavailable instead. So maybe the unavailable, unavailable. Cool. Nice. Cool, done. That's it. Now, of course, I need to remember to remove this, because if I don't remove this, it's going to break the experience for users. But other than that, we're done. So luckily, this is a pretty nice good base to work with. Thank you, Next.js. And yeah, we're pretty much done. So running the app locally is a lot of times the right solution, right? It's super straightforward. It doesn't require any additional setup. The only thing is that mocking data can be hard, depending on what is the specific use case that you're working with. And iteration speed can be slow. Again, only if you're working on a really complex code base or something that is not very well configured. But that's more common than you would think. Option two, we could use Storybook. In case you're not familiar with Storybook already, it's pretty much a gallery app for all of your UI components. So it's called Storybook, because you define stories for your components. Each story is a specific version of your components. So in our case, for example, we have the unavailable story, and we have the available story. So let me show you what that means. I'm going to go in here and run your Storybook. And this can take a while, depending on how many components you have. Okay, this in our case is very fast. Cool. And you can see, okay, we have this counter story, we have the no-match story, the restaurant header story, restaurant list, and so on and so on. So what we're interested in here is restaurant menu item, where we have two different stories, default and picked. So you can see that when it's picked, there is already a counter created. And I can go back in here, and let me show you how that's implemented. So we have this file next to restaurant menu item, which is the restaurant menu item.stories. And it has a little bit of boilerplate for Storybook. And then each story is this. So we have args that we define for story. So here we have two stories, default and picked. And default and picked are here. So you can see the difference is with the args that we pass, which are pretty much the props. So in our case, we want to create a new story called unavailable with a menu item that is of course unavailable. Oops, forgot a comma. Available, true. That's pretty good. And now it should appear. Okay, perfect. We have it here. But of course, we haven't, I reverted the change already. So let's do that again. Just simulating the experience from scratch. Menu item.unavailable, unavailable. Okay, perfect. And it updated pretty quickly, which is great. And let me revert that again, because we're going to do this again yet another way. Cool. The nice thing with Storybook is that it encourages good design, not just from a UX design perspective, but also from a software design perspective. So because you want stories for each of your components, you need to think about what components you want in the first place and how you want them to be designed in terms of the props that it takes, et cetera. And the way that Storybook structures stories means that you are pushed in the direction of creating dumb components that are kind of agnostic of the state, so they're not capable to Redux or anything like that. And usually that's a pretty good thing because it means that your components are really easy to test, really easy to reuse as well across code bases. So lots of good things there. It also acts as documentation, which again, is super useful. So if you want to say, tell your UX designer, hey, I have this component that is currently in this particular implementation, you can check it out at this URL. That's really super useful and reconciling that versus the box that your designer is working with. It can be a little bit slow to spin up in that it depends on how many components you have and really is something that the Storybook team is working on improving anyway. So it's not really something I would worry about too much. It does require a little bit of boilerplate. So we saw that you really can only look at components that have stories defined for them. So first you need to define the stories. If you find a component and you're wondering what it looks like and there's no story for it, you're going to have to write a story first. Cool. Is there an option three? You know how when you write markdown in your ID, let's say in VS Code, you can actually see a preview of it. So let me show you. Let's create a readme and say hello world. I'm on a max. I'm going to press command K and V, I think. Yep. And this is going to say this is instantly updated with a nice preview. I can see this is pretty cool. Cool. So what if we had something like that, but for React components? And I kept looking for that, but I never could quite find the right solution. There were a couple of contenders, but the problem is that they only work with components that don't take any props or that are super, super simple. So I decided to build it. And it's called Preview.js. It was actually earlier called React Preview because it was for React components, but then I realized that it could also work with other frameworks like Vue and Solid. So I renamed it to Preview.js and also in the process kind of reworked pretty much all of it. So Preview.js works with React, Vue 2, Vue 3, and Solid. And it's available on VS Code and IntelliJ. So let's look at what Preview.js looks like. Let's go back to VS Code. We have our restaurant menu item here, which I reverted back to the previous state. And I'm going to here have this button, open restaurant menu item in Preview.js. So I'm going to click on that. And oh, proof. That's pretty cool. Okay. So I can see a preview of that. And I, again, did not have to write any code for this. This is just out of the box. Basically what it did is it looked at the props of this. It's so, oh, okay. This specific, first, this is a React component. Therefore, I can show this thing. But also it sees, okay, that takes menu item counts on update. And it can actually look at the type of menu item and kind of generate a valid value for it. Well, at least as much as it can guess. So here, let's make it a little bit more realistic. So let's say brownies. And let's use cute kitten pictures. Although we're not going to eat the kitten. So yep, this is really just for illustration. And now this is a little bit more realistic. Now we want to implement the unavailable state. So what I'm going to do is provide an example value. Okay. And now I should be able to see what it looks like. So do unavailable. Oh, cool. That actually updates live. That's pretty cool. And I'm going to make it prettier then given I have instant feedback. That's pretty cool. Okay. A bit of padding. Maybe rounded corners. Yep. Maybe a drop shadow. Drop shadow. Yep. Oh, cool. Maybe a border as well. Border to border. Red. Oops. Sorry, typos. Lots of typos. Okay. That's what you get for recording a presentation at 11 p.m. Okay. Yep. One more time. Okay. Cool. I keep pressing save when I actually don't even need to save because privilege doesn't require you to save. Okay. So that's pretty cool. Okay. Unavailable right now. Okay. Okay. How does it look when I make it wider? Okay. Cool. That's fine. Okay. Maybe just a little. Okay. Cool. Done. That's Preview.js in a gist. Now, you might wonder if you use Preview.js, should you still be using Storybook? And the answer is yes. Storybook is pretty much still a great tool for documenting your components and making sure that you have documented every variant of it. In fact, Preview.js actually supports displaying your stories. If I go into menu item stories, you can see that I see the same Preview link for each of the stories. And I can see them like that. Which is perfect. I can also, you know, look at the restaurant header. All these different things. So, if you're just exploring a codebase, I use a Storybook and you use Preview.js and you have it set up, you probably don't even need to spin up Storybook. And this will probably be a lot faster to just use that instead. Just like that. In the future version of Preview.js that I'm hoping to release in June or July, there will actually be also a feature to save your props as a new story. Although I'm probably gonna make that part of the Preview.js Pro version which is paid. Just because at the end of the day, I would like to be able to make a little bit of money from that so I can spend all of my time working on Preview.js as opposed to having to squeeze that in my free time. But that's the gist. Preview.js works really well with Storybook. You can use both. They don't compete with each other. Preview.js is only possible thanks to a couple of recent web tooling innovations. Especially one called Vite. Which is pretty much an alternative to Webpack that is significantly simpler to set up and as well significantly faster. Your developer experience with Vite is that you update a file and within literally milliseconds, it will update. That's why Preview.js is able to do preview as you type. The only reason that's possible is because it uses Vite under the hood. If you want to take one thing out of this talk, aside from use Preview.js, of course, it's use Vite. Try it out. It's easier to set up than you would think. And it might save you literally many, many hours per week. If you want to set up Preview.js with your projects, there are a couple of steps to go through. To be honest, right now, it's not the smoothest experience, unfortunately. But unless you use, you know, create React app or something super simple, in which case it should hopefully just work out of the box. But the first thing is, of course, make sure that you use an IDE that's compatible. So, either Visual Studio Code or IntelliJ slash WebStorm. If you are not sure which one to use, use Visual Studio Code because the IntelliJ version is kind of buggy, to be honest. Working on that. And then the next thing is you have to configure it to display your components properly. Because by default, what Preview.js will do is display your components in a completely empty app. Which is not exactly perfect if, for example, you need some global CSS to be there. So, the way that you do that is by configuring a wrapper component. And let me show you what that looks like in my hungry app. It's here, Preview.js wrapper.tsx. And that's pretty much all of the config that we have. That's it. That's all the config. The important thing here is this import styles globals.css. Without this, it would look super ugly. So, let me just show you what I mean. Okay. So, I have this. And I'm gonna remove that just for fun. And it's gonna be... Yep. Really broken. Because, of course, in globals.css, in this case, I have all of Tailwind set up. And I also have a wrapper that sets up a screen container. I'm just adding a little bit of margin to make it prettier. But you might, for example, need to set some React contexts. Some, you know, initialize your redux state or whatever else you need. If you use aliases, import aliases, you might also need a couple of lines of config as well. So, as I mentioned earlier, Preview.js is quite new. It just came out in January. So, if you run into any bugs, please consider reporting them on GitHub. I really appreciate that. I'm expecting after this talk maybe a couple of hundred bug reports. Hopefully not that many. Go to Preview.js.com if you want to check it out. If you're on Twitter, you can follow me and share your feedback. I really hope that Preview.js can make your daily workflow a little bit better and a little bit faster. Thank you.


François Wouts

Measuring and Improving React Native Performance

Hi everyone, super excited to be talking to you at React Summit. I'm Alex, I'm a tech lead at BAM, we develop mobile apps in Kotlin, Flutter, and of course React Native. And I just love the subject of mobile apps' performance, so let's dive in. What does it mean for a mobile app to have good performance? Well, according to this video from Google, which will be available in the slides, your app should be able to run at 60 FPS, 60 frames per second. This means that your app should be able to draw 60 images per second when you scroll down, for example, to give an impression of smoothness to the user. It's basically like a movie. It's animated pictures, basically. But the question is, what about React Native apps? Well, this also applies to React Native apps, but there is an added complexity, the JS thread. Because most of your logic will run on the JS, most of your business logic probably resides on the JS side of things, you need to make sure that it's not too busy. For example, here I have this app with a Click Me button. When I click it, the state updates. I've been clicked one, two, three times. But Kill.js is too expensive, so when I click it, the JS side of things is blocked. So even if I click Click Me a lot of times after clicking Kill.js, nothing happens. And it's not before Kill.js has finished that the JS actually becomes responsive again, and you can see it update four to 12 times like that. So it's very important to take a look at the JS side of things as well, because your app could be running natively at 60 FPS, but be completely unresponsive. This is why React Native offers this view, the React Native performance monitor, displaying UI and JS FPS, and this is why we created this Flipper plugin to be able to display it in a graph. Also, as an added bonus, it gives you a nice score for you to be able to run performance benchmarks. But chances are, this score could depend on a lot of factors, actually. So let me give you some tips, general tips, actually, on performance measures. The first one is this. You should test on a lower-end device. I mean, if you only test on a high-end device, chances are that you will miss most of the issues that your users are actually could be having. An iPhone 13 can actually run JavaScript or some calculation 10 times as fast as a Samsung Galaxy A21s. So, well, you know what to do. You should definitely test on a lower-end Android device. Second tip is this. You should make your measures as deterministic as possible. Performance measures are hardly deterministic, so you can make several iterations and average the result. You can also make sure to keep the same conditions as much as possible for every measure, for example, network, the data you were loading, et cetera. And I mean, if you want to reproduce the same conditions, it's ideal to be able to automate the behavior you want to test. And for that, you don't necessarily need an end-to-end testing framework. You can just use ADB on Android, for example. Here with ADB shell input swipe, you can actually trigger a scroll on your app. Third tip is this. Disable JS dev. If you want to have true performance measures on the JS side, you should disable this, because you might encounter issues that you won't actually see in production. And the fourth tip is, well, if you find some issues when measuring, well, just use the best analysis tools. On the JS thread, that would be React DevTools or even running a JS Flame Graph with the Hermes profiler. And on the UI side, use native tools like Android Studio, Systrace Profiler, or Xcode Instrument on iOS. All right, let's dive in on a concrete example now. TF1 is a TV news channel, and we're building their news app. And we wanted to make sure that performance was on par with our quality standards. So we checked the home feed, and our goal was that when we scroll down, basically on a low-end device, we should have JS FPS always above zero to keep the JS side of things kind of responsive, and the UI FPS always to 60 to be able to be very smooth. So following the four essential tips that I talked about before, basically, we use a Samsung J3 from 2017. It's our favorite low-end device. It's pretty low-end. We set up measuring for 10 seconds. Arbitrary, but it's just important to keep the same time for every measure so you're able to compare. We reload with JS state mode disabled. We wait for the feed to be loaded, and we hit Start Measuring on the Flipper plugin. We run ADB shell input swipe, blah, blah, blah. And we wait until the end of the 10 seconds, and then we reproduce this five times just to be able to see if we get similar results and average it. And the result was this. The plugin was giving us a score of 40 out of 100. JS was dead at zero for about four seconds. UI thread was kind of okay. But basically, this means that the app was actually not responsive for about four seconds, which needless to say was completely unacceptable. So since the issue was mostly on the JS side of things, we ran two React DevTools. And it's available out of the box in Flipper, which is nice. So first thing you want to do is click on this button on the top right, and there you can check the box, record why each component rendered like profiling. This is a neat option to activate. We will see why pretty soon. Then just click the blue button here to start recording. Do some stuff. So in our case, that would be reproducing the exact same scrolling with ADB shell input swipe, blah, blah, blah. And then we hit the button Stop Recording, and it gives us a result kind of like this. All right. First thing you want to do is check this. This is the list of comets. These are the phases where React actually applies any changes. And so usually when you look at performance issues, you want to find the most expensive comets in terms of how much time it took. And in our case, this would be the 11th one, because it's the biggest bar here. So let's click on it. And this is what it gives us. Pretty. There is a lot of colors here, but basically this is the hierarchy of your React component. In gray here, you will see components that are actually not rendering. But in our case, the rest, green and some other colors is rendering. So if we zoom in a little bit on this part, for example, you will see the hierarchy of components starting with flat list here in gray, so not rendering. So our flat list, you know, our home feed was implemented with flat list. So this is it. And it's an internal implementation in the React Native code. Its child is called a virtualized list. So here it is. And we have context of consumer. Its child is virtualized list, contact provider, et cetera, all the way down to context provider, just the list of children, basically. And this guy has several children called cell renderers. This is basically what is wrapping the stuff you pass in your render items. So essentially, the cell renderer are our list items of our flat list. You will notice also that on every component, you have two metrics. You have this one on the left side. For example, here, 4.9 milliseconds on our virtualized list. It's the self time. It's the time the component took to render without any of its children. And the right one is the total time. It's the total time that the component took to render, including all of its children. So here, basically, we have a virtualized list taking three seconds to render. And we can see that basically all of the list items are actually also rendering. So our list is rendering. All of the items in our list are rendering. And this takes a total of three seconds, which is kind of crazy. I mean, remember when we talked about the JS being locked for about three or four seconds? This totally explains it. We have three seconds for that. So what should we do? Well, the first thing that you want to do is differentiate between initial rendering. And when you hover a component, since we activated this option earlier, you will see something like that. This is the first time the component rendered. Or are those components actually re-rendering? They have been initially mounted, but they're rendering a second time or another time. And in this case, you will see something like this. In our virtualized list, it's a state change, a last change, which we don't really know about because it's the internal implementation of FlatList. In our case, actually, all of the components here were re-rendering. Because remember, I said that we have loaded our feed previously. So it was rendering already some items in the feed. So when we scroll down, basically, it's re-rendering even the top items in the feed. And this is crazy, right? They don't need to be rendered. So what is going on? Well, the first iteration we took to fix was this. And everyone should know about this. Because see, so the FlatList is a virtualized list. And virtualization works kind of like this. You have a long list of elements, for example, I don't know, 10,000. But of course, for performance reasons, you're not going to be able to display them all at the same time. So we use a virtualized list to display only what the user sees and some items above and some items below to ensure smooth scrolling. It's important to notice that in React Native, this is the FlatList property called window size. And in React Native, actually, it's going to render 10 screens worth of items above the current viewport and 10 screens below it. So it actually renders a lot of items. Good thing to keep in mind. But so how does this work? Well, basically, the FlatList is keeping a state in its internal implementation of the first element to render and the last element to render. So when we scroll down, well, those change. And so this triggers a re-render of the virtualized list, which is normal. So basically, this means that render item, what you pass in your render item, is called onScroll. And this is by design, which means you should absolutely follow the best practices defined in the React Native documentation about FlatList. And you should memoize all of your list items. And that's what we did. And we went from this to this. So the big difference that you should notice is this. Basically, we have a lot of gray here. The items that we memoized are now not re-rendering. And this is what we want. We still have some green stuff above it. This is basically the internal implementation of virtualized lists, state changes, et cetera. So we can't really change, we can't really prevent it from rendering. And if it's not taking, I mean, what is really expensive here is the children. And we still have actually some green stuff here. But yeah, we'll get to that actually in a minute. Because first, we already have some less green stuff. We have some more stuff. I mean, we have less stuff rendering. So let's just check our performance score. Let's check our measures, just like before on the Flipper plugin. And this is what it gives us now. We went from 40 to 52. Chase is only dead for like three seconds. And the UI thread is still around 60. So OK, it's not fantastic. But already just with a simple memo, we made a very good improvement to our performance. But let's go deeper. Second iteration, I titled it the joy of nested list. And you will understand why pretty soon. Because yeah, remember those green stuff at the bottom? Let's zoom in to see what this is. So we have our cell render at the top. So this is wrapping or what we pass in our render item. Then we have the gray stuff, because we memoized it. But we have here something that is still rendering in green. And it's not a virtualized list. This is because we have horizontal carousels implemented with React Native Snap carousels, which itself uses a flat list. So essentially here you see our seven carousels that are displayed on our home feed re-rendering. But why are they re-rendering when we scroll down? Well, remember the state, the window state we talked about before for the parent list, it passes it as context to the nested child list. So we can see here that the virtualized list are re-rendering because of context change. And this means that when we scroll the parent list, nested lists, even horizontal, the render item will also be called. So we have to memoize everything. And in our case, that would be the slide items. And so that's what we did. And then we went from this to this. Might be hard to see, but now we have a lot more gray at the bottom. So oh, we have some stuff appearing on the right side. We could check what this is. OK, they're actually re-rendering for the first time, which means that this is probably new list items appearing when we scroll down. This is OK. Let's check first excessive re-rendering. So now we have this. Lots of gray at the bottom. Let's check our score. And we went from 52 to 54. Pretty much the same, basically. Not super good improvement. So we need to go deeper. All right. Let's check a bit more those carousels. If we zoom in on this guy here, we can see that basically it's a virtualized list re-rendering. OK, our carousel. We've worked 10 slides. Wait, 10 slides? No, actually, our carousels only have four slides. Oh, but that's right. We added the loop prop on the React Native Snap carousel, which means that it will actually add three slides on each slide of your carousel at the beginning and at the end to achieve the infinite loop effect. And the brightest among you will have noticed that this checks. This equals 10. So we decided to just deactivate this prop for performance reasons. And so now we went from this to this. We can see that, indeed, we only have four slides rendering. So let's check our score. And our score is much better. We went to 70. Yes, it's only there for one second. Great, great. Still OK. All right. We're getting there, but still not perfect. So let's go even deeper. Right. Let's click on this first carousel, this virtualized list. We can see all of the items. If we zoom in on the first one, this is what we see. We see our virtualized list here. Still taking 75 milliseconds to not do anything, basically. But we noticed this guy, animated component, being in orange. So React DevTools will print out in a different color, like orange here, items which have a very big self time. So they're very expensive to render compared to their children. And so this guy here is expensive to render. But where is it coming from? So the top here is from the flatlist code, from virtualized list to cell render. This gray stuff is our slide. It's memoized. So here, this is coming from React Native Snap Carousel. And yeah, actually, the animated components is here to have some cool, nice transition. But not only is it quite expensive to render, it's not even memoized. And it should be. So we could patch React Native Snap Carousel, or at this point, we kind of realized that nesting virtualized list is tricky. So the question is, can we avoid it? And the answer is yes. Because remember what I said about virtualization by default in React Native displaying 21 screens worth of items? In our case, we only have four items. So virtualization here for carousels bring no benefit whatsoever. So we decided to recode it ourselves with a scroll view and paging enable prop, basically. And now we have only gray here when we scroll down. Nothing is re-rendering excessively. So let's check our score. Now we are at 90. And the JS is never at zero. And the UI thread is always OK. Woo! We've done it. So I encourage you to try it out. Consider your app's performance. Take a low-end Android device. Find areas with the plugin with zero FPS on JS side or below 60. Analyze those issues and fix them. And check back your score improvement. That's it. Thank you guys for watching. Hope you enjoyed the talk. If you have any questions, feel free to ping me on Twitter or follow me. I tweet mostly about React Native performance. Thanks, guys. See you next time.


Alexandre Moureaux

High-Speed Web Applications: Beyond the Basics

Michael Hladky

Bringing the Power of AI into your Editor with GitHub Copilot

Krzysztof Cieślak

React Advanced Conference 2021

Beyond Virtual Lists: How to Render 100K Items with 100s of Updates/sec in React

Michel Weststrate

Supercharging Developer Productivity With Advanced Code Search

All right. So, if you're on sourcegraph.com, just follow me. So, I'm Prosper Otemiwa, I work as a developer advocate at Sourcegraph. We have an agenda. So, every developer in the world spends a huge amount of time reading and writing code. In fact, if you use GitHub a lot, you discover that even when you're on your laptop, you're on GitHub, you're trying to get notifications for pull requests, comments, and every other thing you're doing with code. Right? So, if you spend more time reading and writing, then you should have the tools that allow you to search for code very easily. So, we have a tool called Sourcegraph. Sourcegraph.com. That's why I said you should open your phones. If you open your phones, go to Sourcegraph.com. I like to call it the Google of code search. So this is how it looks like. If your interface doesn't look like that, you're not on Sourcegraph, please. Just cross check. Right? So, with Sourcegraph, this is the value we offer to developers. Sourcegraph has currently indexed over 2.1 million open source repositories across GitHub and GitLab. So, right now, you can search code on Sourcegraph, and it gives you data from GitHub and GitLab. Right? And you can also set private code across several repositories. With Sourcegraph, the same way you can do local search on your local IDs, you can have precise code intelligence on Sourcegraph.com. And with Sourcegraph, there's a feature we have called batch changes. Instead of automating, instead of opening several pull requests to different repos, with batch changes, you can have a file and it can make several pull requests for you instead of you having to do that yourself. So, it's called batch changes. And then we have two features called code monitoring and code insights. But for this talk, I'm going to be talking more about the search. All right. So, like I said, Sourcegraph can be called the Google of code search. It's literally a search engine that allows you to search all of open source code and all of your private code. Right? So, what are the code search patterns we have with Sourcegraph? There are three types of search you can do right now, literal, regular expression, and structural. So, let's go to literal. I know many of us are familiar with the source-based component. If you're a new developer or you're trying to see occurrences of a particular class, symbol, or definition, you can copy the code base and paste it into Sourcegraph and it goes ahead to search for you. Right now, this is me placing the source components in Sourcegraph and it searches all of the open source code it has indexed across GitHub and GitLab and it tells me examples and results of people that are using source components across this GitHub and GitLab. So now you can see the responses. You can scroll down. On the left hand side, you can see all the filters and operators that you can add. So, you can search through divs, you can search through the time difference. You can search through the committers of the code. I can have access to how people are using certain APIs. Another API that you can talk about in ReactJS is the unstable batch of this. So you want to know how many people are using unstable batch of this in the world? How many people are using it and how are they using this particular API method? With Sourcegraph, all you need to do is paste it in. If you look at the arrow, it searches within the ReactJS organisation, it searches all of the repos within the organisation, and it brings you out results of every usage of unstable batch of this. So, from within the React code itself, and within every other example within the React organisation, you can just get results. Now let's go to regular expression. How many of us are familiar with regular expression? I know we probably don't use it every day, but with Sourcegraph, it allows you to flex your muscles with regular expressions. If you understand what you're trying to look for, you're trying to look for something within a file, for example. So, here, I was trying to look for how people are using some of the latest versions of React by using regular expression to search via the package.json of several repositories. So I pasted this into the Sourcegraph search engine. I toggled on the regular expression mode, and this is the results it gives me. So with this result, you can see, and you can narrow down to get the results of how many people or how many projects are dependent on a particular version of React. So some of us here are open source maintainers, some of us are open source authors. You really want to get an idea of how many people are using your open source package, or how many people are using certain versions, maybe because you need to deprecate certain methods or maybe because there is a new architectural change you need to work on. So with this, you can easily scroll and see how people are using it, Webpack, RemixRun, Visualiser. You can see how many people are really dependent on a particular version of your project. So this is an example of me searching through branches, right? I was searching through the Sourcegraph repository, and then specifying with a regular expression to search within every branch that has mchap within the name of the branch. So this goes into all of the branches that has mchap within it, and then searches for Ubuntu latest. With that, it returns all the codebase for me. This is just open source code. And then connect all your private repositories as well. If you sign up and connect your private repositories, it's the same result it gets you. It searches within the scope of all the repositories that you've connected to Sourcegraph. And then we have the structural search. I think this is one of my best types of search. With structural search, you can literally take blocks of code. So you can take if conditions, try to catch a full block of code and paste it into the Google search engine, into the Sourcegraph search engine, and it's going to give you the results you're looking for. So this is me searching through the Google organisation on GitHub and looking for this block of code. If not path.length, and you have the three dots. So it goes ahead and looks for all the types of code that fulfils this particular condition and returns them to me. So now I can see all of the projects and all of the codebases, all of the files that have this within them, and then I can keep narrowing my search. There are so many keywords that you can use. In fact, we have a boot out there with a cheat sheet, so I encourage you after this talk or when you're free to come out to our boot and get the cheat sheet. There's a lot of things to learn there. So why you actually need Sourcegraph? Developer velocity. As your team is growing, you want, you know, as you build more features, you want your developers to move very fast. So with Sourcegraph, if you have all your repositories connected to Sourcegraph, it allows them to search stuff, right? Some people, we get into a company, and within the first week, they're already committing code. They can easily get the codebase, right? For some people, it takes three weeks because you have to go through different repositories, you don't know what you're doing. With Sourcegraph, everything is in one place, and it allows your developers to get on quickly to the codebase. And then with refactoring, there is no case of I left this behind. I forgot. I know you have tests. Yeah, that's very good. But when you have shared systems, for example, you have a shared design system they're using across different repositories, sometimes you forget that a particular component or something is used in this other part of the codebase or in another repository. With Sourcegraph, once you paste that in, it brings out all the references from all the different repos, no matter how many repos, 100, 200, 1,000, connected to it, and you get all those references and you move fast. Now a recap of the search parameters. Again, there are different keywords you can use with Sourcegraph, right? This is just a very good illustration of some of those keywords, right? You have the repo keyword that allows you to search within a particular repo or within an organisation of repos. Then you also have the branch where you can specify the branch to limit and narrow the search. You also have the type symbol. With type symbol, what happens is instead of returning the code with the function call, it just returns the definition of the class or the definition of the function with type symbol. So, with file 2, you can limit it and say, hey, I want you to just search within the config files or within the package files. And then with type commit, you can say, hey, I want you to search within a particular commit or within a div. Then you can specify the lang, for example. If somebody is trying to learn about lambda functions in Python, you can type in lambda and narrow your search to Python and it will give you all the ways lambda function has been used in the world or within your private codebase. If you want to learn more about code search, I implore you to visit learn.sourcegraph.com. Learn.sourcegraph.com is our entire suite of learning tutorials for everything that has to do with regular expression search, structural search, and everything that you can do with code search. And then we have more resources. We have an active presence on Dev 2. We have our blog. We also organise what we call Dev 2 time. So Dev 2 time happens biweekly. So if you go to our YouTube channel and search for Dev 2 time, you can see the amazing set-ups of different developer workspaces. And then you can search our podcast as well. So all these resources, you can use it to learn more about code search and about Sourcegraph. So thank you very much. And then you can follow me on Twitter and on GitHub and ask me as many questions as you want. Thank you.


Prosper Otemuyiwa

JSNation Live

JSNation Live 2020

I See What is Going on: Visual Testing for Your Components

Gleb Bahmutov

React Summit 2020

Flipper: The Extensible DevTool Platform for React Native

Visualising Front-End Performance Bottlenecks

Richie McColl

JSNation Live 2021

Debugging with Chrome DevTools

Hi all, I'm Jocelyn Yin. I work at Google. I'm the developer advocate for Chrome DevTools. As a web developer, I use Chrome DevTools every day to debug my web applications. Let me share with you some tips that might help you better utilize DevTools for debugging. First tip is about getting to the panel or feature you need quicker with run command. For example, if I want to debug my video, I can go to run command, type media and click enter to open the media panel, or if I want to capture a page screenshot, I can run command with the command shift P keyboard shortcut and type capture. Here you can see a list of screenshot options. Scroll through the list. You will be surprised that there are many commands that you can run. Run command helps save my brain memory because sometimes I just don't remember which panel to open to emulate the CSS stuff theme, for example. Next there are a bunch of keyboard shortcuts in DevTools, but we as humans have limited memory. Instead of memorizing the shortcuts DevTools predefined, you can now customize your own shortcuts. Go to settings, shortcuts. I can customize the run command shortcut. I can either replace the current command shift P shortcut or add another shortcut, say option C to the same command. If you are using Visual Studio Code as code editor, you can map the shortcuts to that as well. Next, there are times I want to debug my search dropdown. However, when I right click inspect on the search box, the dropdown is gone. This is annoying. I mean, I just want to debug the dropdown. Please help. Okay, cool down. Let's pull out the run command and type focus. Select the emulate a focus page option. Problem solved. The reason being is the dropdown is triggered when the user focuses on the input. So use DevTools to emulate the focus effect and you are good to go. Next a new feature. For folks who deal with memory a lot, you can now use the memory inspector to inspect the JavaScript array buffer and Wasm memory. For example, I have an array buffer here. Let's set a breakpoint and refresh the page. Notice the new icon next to the buffer value. Click on it to review the memory inspector. Then you can navigate around and resume the script executions to inspect the memory changes real time. Learn more about the memory inspector with this documentation. Next let's look at the network panel. There are times we want to find out the initiators or dependencies of a particular network request. Hold the shift key and hover the mouse over to the request in the request table. DevTools colors initiators green and dependencies in red. Next you can change the user agent in the network conditions tab. For example, you would like to make sure your page works for search engine optimization because some servers or CDN configurations might block crawlers by default. You can debug such behavior by clicking on the network conditions icon, choose Google Bot from the dropdown, and refresh the page to see if any errors occur. You can also set a custom user agent if none is found on the list. Next some tips on the network filter. You can filter the list by the size. Here I use the larger than keyword to find out requests that are larger than 15 KB. What if I want to find all the requests smaller than 15 KB? I can use the negative sign to negate this filter result. For example, you can exclude all requests with status 200 with the filter negative status code 200. Next let's move on to the console. If you find yourself typing the same JavaScript expression again and again during debugging, consider using the live expressions. This way you type an expression once and then pin it on the top of your console. The value of the expressions updates in near real time. Say I would like to keep track of the dotted images in this page. Click on the create live expressions icon and type document.querySelectorOrImg.length. Right click and duplicate the image element now. See, the number is updated automatically. Nice right? There are also a few handy console utilities that can save your typing time. Just now, we used document.querySelectorOr to get the dotted images of the page. We can use the $$ command to do the same. Also, if I want to print the image element that I have currently selected, I can use $0 to do so instead of typing console.log. I can combine the $ command with copy to copy the element to the clipboard. There are actually more console utilities, refer to the documentations for commands like monitor events, query objects, and profile. Next, if you have code that you frequently use, you can save them as snippets. Go to the sources panel, open the snippets pane. Create a new snippet, say the copy command we wrote previously. Save it. Now, go to the elements panel, select an element, we can run a snippet to copy it. Use command P to pull out the command menu. Then type an exclamation mark followed by the snippet name. The exclamation mark here means execute it now. There you go. Go ahead and save all your frequent use commands as snippets. Next, an undermentioned feature. Use the local overrides to keep changes across page loads. For example, my friend Jack is asking for suggestions to revamp his website about diving photos. We can edit that locally without any deployments. Go to the sources panel, select the overrides pane, then select a folder for overrides. Click allow to grant DevTools access to the folder. Now, we can edit the page. Let's add his name to the title. Try to refresh the page now. Oops, please remember that the changes do not proceed if you edit in the elements panel. The editing should happen in the sources panel. Let's do that again. Save the changes and refresh the page. Nice, the changes are persisted now. Jack likes maroon color. Let's change the title to maroon color as well. Nice. Let's look at the images now. I think Jack can use a more optimized image format like AVIF to improve the page performance. Go to the network panel, filter by image to see how much data we download for the image currently. It's about 450 KB. Let's improve the code by using the picture element. Use command D to select all the image tag occurrence and add in the AVIF image format. Edit the image names and close the picture tag as well. Done. Save all the changes and refresh the page. Let's go to the network panel to see how much data is loaded now. Nice, we cut nearly half the data here. By the way, Brian and Uma have great content on how to use local overrides to compare and optimize page speed. Give it a read. Cool, I can propose the changes to Jack now. But I forgot what I have changed so far. It would be great if DevTools tracked all my changes and show me the differences. And yes, there's actually a changes tab for that. Let's open that. Here you can see all the changes we have made so far. You can click to undo the changes as well. Do you know DevTools is a web application itself? It is built with HTML, CSS and JavaScript. In fact, you can use DevTools to debug DevTools. Make sure your DevTool is undocked. Then tap command option C to open another DevTools. Now you can inspect DevTools with DevTools just like any web application. Our team just migrated DevTools code base from JavaScript to TypeScript and refactored the code base to use the new JavaScript modules. We blog about how we do all this. If you would like to learn more about how we build DevTools, go to our blog at goo.goo.gov slash devtools-blog. Final one, if you want to give us feedback or file any DevTools issue, you can click on more options, help, report a DevTools issue or reach out to us on Chrome DevTools Twitter. Thanks for watching. I hope this tip helped you enjoy DevTools more. Follow me on Twitter if you have any questions. Thanks for watching.


#devtools