GraphQL Galaxy

GraphQL Galaxy 2022

Authorization Patterns in GraphQL

Sam Scott

React Advanced

React Advanced Conference 2022

Killing Bugs With Kindness

Hello everyone, my name is Darshita and I'll be talking about how to reduce bugs in a React codebase by understanding antipaths. A little bit about me, I'm the maintainer of the open source project Athree Engine, which is a new full-stack web development framework. I'm also the co-founder and CEO of Athree Labs, which is the company behind this project. So using Athree framework, the front end of a website can be created by writing React code and its package in Node.js, Python, etc. There are many productivity tools baked into it, such as a visual editor that can be used to create the front end of a website to complement your React code. This is how that visual editor looks like. As you can see, there are numerous interactions on one page. For example, we can add components, style them, and move them around. And we can also see how responsive our website is by clicking on different screen sizes. So while creating this framework, for our team, it was very important to understand and characterize antipatterns in our large React codebase, because suboptimal code in one interaction can affect the entire application. Moreover, the objective of our framework is to support building production-grade websites. Consequently, building internal standards that are rigorous around code quality were very important to us. So in this talk, I will share the types of bugs we have identified in our codebase and the guardrails we have built to avoid them in future. I will cover how to prevent three types of unexpected code behaviors. First, a component does not update upon a user event. Second, the component updates partially upon a user event, since the previous state is still there. And thirdly, the component renders unexpectedly. Initially, while building our framework, we were encountering these bugs repeatedly. So our first resort was to use random print statements like a true developer. But of course, later on, we had to use, we had to create some method around it. So we used one central theme to codify hints that are easy to remember, and can lead us to identify antipatterns. And that theme comes from React's official documentation, which states that a React code should be independent of the sequence in which components will render, and when they will render. The first hint is if we are using hooks without a dependency array. We think that one way to visualize a React code is as a collection of interdependent pieces of code. Hence, if a code's dependency relationship cannot be established, then there is a high likelihood that it will result in bugs. So if we can just take one thing away from this talk, it should be this. Be as paranoid as Charmi was in this iconic Always Sunny episode, when you see or write hooks such as useState, useRef, etc, that do not take dependency arrays. Another way to avoid unnecessary useState is by using the context of the event handler to store state. Here I am demonstrating this using the custom slider component. The code on the left has antipatterns. For example, there are four useStates and three callbacks. The startPosition state records the initial position of cursor. The code on the right is its refactored version. Note that we do not have any useState and only one callback because we have used the local context of the callback to store all the ongoing information related to user interactions. When we applied this refactoring to our framework, we were able to drastically reduce the ratio of useState per component. Our current ratio of number of useState to total number of custom hooks and components stands at around 1 is to 3. To give you a context of the size of our codebase, it has around 100 custom hooks and around 200 components. The next hint for antipatterns is if you are using nesting for arranging components. Note that while using nesting, if you are not paying attention, you might pass down duplicate states to children. This may lead to inconsistencies of states between parent and children. Recall that our code should be independent of the sequence in which components will render. Moreover, there should be a single source of truth for each state, otherwise it will result in bugs. The second thing to note here is that tracing changes in state is the most time-consuming step in debugging. Since nesting allows change in state at each level, it takes longer to debug. The third hint is if you are using many uncontrolled components. We are aware that there is an active debate on the use of controlled components, but we believe that controlled components should be preferred, especially if the number of interactions per page is high. In our framework, we have been able to reduce bugs by more than 80% by using controlled components. So, to summarize, be extra careful when you are using hooks without dependencies and using nesting to arrange components. We should definitely avoid two anti-patterns. First is using props in context or as initial state. And the second is using destroy and recreate anti-pattern. As the name suggests, this anti-pattern refers to removing the component from DOM and destroying all the hooks and states created during the first function call. This is followed by creating the component again from scratch. This anti-pattern can lead to issues such as flickering effect. There are four coding patterns that we recommend our developers to prefer to reduce bugs. First is using props in JSX. Second using the context of the event handler to store state. Third, instead of trying to make useState work somehow with patchwork, switch to a hook that takes dependencies, such as useMemo. And fourth, use controlled components wherever possible. Thanks for listening. These are my social media handles. If you're interested in reading more about these anti-patterns, you can check my blog post. There I discuss these anti-patterns in more detail. I've also used an example app in the blog that demonstrates these anti-patterns. Finally, this is the link to the full stack web development framework we are building. If you're interested in contributing to our project or sharing feedback, please check it out. And if you like what we are building, please start our repository. Thank you.


Darshita Chaturvedi

Separating Separation of Concerns

My name is Jacob. I live here. I work here. My concern today is to tell you that my concern is what I'm attempting to do, and that how I accomplish that will necessarily mirror my understanding of my concern. An excellent first example is to talk about a to-do app. If I choose to conceive of my to-do app as managing a list of non-interconnected tasks, then I'm probably going to write code that maps from an array of non-interconnected tasks to an array of elements. I'm going to slot that in the DOM, and that's going to be my primary functionality. But that's not going to be the entire app. I'm probably at least going to have a heading, and I'm going to have a div around that, and maybe a footer, and maybe some analytics, and maybe some trackers. I'm going to represent all of that as a tree structure, and to instantiate that tree structure, I'm going to use the DOM, because the web is good. What we run into immediately is that our headings aren't just presentational semantic. They don't simply have that concern. By enframing the functionality, they enable the functionality. We wouldn't be able to interact with this app if we didn't know what it was and how to do it. So these sort of crosscutting concerns, it's useful to co-locate them, instead of separating them out into HTML, CSS, JavaScript files. That was what React meant when they talked about separation of concerns, rather than separation of technologies. Another set of concerns that we have co-located in all of our components are our concerns of functionality and our concerns of efficiency. These were the two primary concerns that Dijkstra was talking about when he introduced the term separation of concerns in his seminal paper on the role of scientific thought. The most germane passage is as follows. A program must be correct, and we can study it from that viewpoint only. We also know that it should be efficient, and we can study its efficiency on another day, but nothing is gained by tackling these various aspects simultaneously. It is what I have sometimes called the separation of concerns, which is yet the only available technique for effective ordering of one's thoughts. And when we talk about efficiency in React land and in industry more generally, is as if it were the precise inverse of abstraction. So because React is more abstract than JS, it follows that we can expect that React will be significantly slower than JS, but this isn't actually the case. If we look at a piece of JS, say 3JS, and we look at React 3 Fiber, we see that React 3 Fiber is actually faster than vanilla 3. And what this tells us is that we may be misconceiving of React. We may be thinking of React as being, say, an entire framework, when it may be something closer to a library that has a particular concern of dealing with, in this case, scheduling. And one of the downfalls of this mode of conceiving of it is that when we structure our apps incorrectly, we can't take advantage of React. One of the biggest problems in React is that our components re-render too often. Too often, in quotation marks. And to deal with this, we pull our state out of those components. For example, Redux at arm's length and pulling it all the way out of React. And I think this misses the point. And I think the core React team might agree with us. Because they actually put together a state management library right when they made React. This state management library is called React. And every time you NPMI React, you're also NPMI-ing React. So, let's see what this React does. If I look at my component, I'll notice that there are actually two, more than two, but at least two concerns that are all jumbled up inside of it. If I'm a list, I don't care about every single letter that enters this input. That's not what I'm concerned with. And having it in this input means that this input is going to re-render with every single letter that comes in. It seems reasonable of React, and this was the whole point of React, for it to re-render whenever state changes. That's how it reacts. That's what it's reacting to. It's state change operations. The whole sort of message of early React was that UI is a function of state. And that's what the component form is. We're taking all of the state and we're bundling it together with the UI. We're saying that the two are inseparable. And so, what React is doing is it's taking advantage of this. It's taking advantage of this implicit connection between the components and the tree of components to say that we don't need to explicitly talk about the connection between pieces of state. The component tree is that connection between the pieces of state. And so, as long as we properly separate our concerns, as long as we properly separate our states, and as long as we properly separate our components, not only will we get a more efficient app, but we'll also get an app that's a lot easier to read. We'll get components that are smaller, faster, lighter, and more readable. And that's what I find staggeringly beautiful about React. Is that if we properly think about our concerns, which we ought to be doing anyways, then our app is almost always going to be fast enough to deal with what we want to do. And if it isn't, then I guess you should use Svelte.


Jacob Whitford-Bender

React Slots: a New Way of Composition

Hey, it's my great honor to be here to share with you some of my thoughts on design system. My name is Gongwu Nie, you can call me Nio. Today my topic is React Snots, a new way of composition. Before we dive into the topic, I'd like to tell the backstory first. When working on the design system, I'm always thinking how to build flexible and future-proof components. For me, the hardest thing is not creating new components or fixing weird bugs. It's the component API design. Every time when I found a new design system, the first thing I would do is to see how they implement the text input component, because it's one of the most mysterious components. Let me show you. Text input is simple and straightforward. It comes with a label, an input, and have a test. Let's add accessibility support first. When building a shareable component, please don't forget to forward ref. We need the ref to the input to focus it in form validation. But what about the wrapper? We also need the ref to the wrapper to attach propover or tutip to it in some cases. Well, we can add a wrapper for it. But wait, have you noticed a potential problem with this current approach? What will happen if we are trying to add some margins to the component from the other components? It will increase the margin between label, input, and description instead, because we spread all the rest prompts to the inner input element. The fix is simple. We can pass the class name and style to the component wrapper instead. Looks good? The problem is that the component is getting confusing for the consumers. Which prompts will be passed to the wrapper? Which prompts will be passed to the input? The component becomes a black box. In reality, the product teams will keep asking for more options to access the internal elements, like attaching point events or adding data attributes to the label or description, similar to wrapper ref. We can introduce wrapper prompts, label prompts, and description prompts. It works. But it doesn't end here. What if we need to add surroundings to the input? More prompts. Now you can see how API gets bloated with this approach. Here is the API of text input from Maintime. Don't get me wrong. Maintime is a great components library. I love it a lot. They choose the configuration way to design the component API. In the configuration way, we have to support flexibility with API bloating, and the components become a completely black box for the consumers. Let's take one step back and think. How do we build our web app in React? We compose components. Each component just does its own job and that's it. Simple and flexible. Then what if we use the same approach for shareable components? We gain the same clearance, simplicity, and flexibility. A lot of popular components libraries are using the composition way to implement accessible components like Chakra UI, Redux primitives, Hedonist UI, and more. To support accessibility, we have to use React context to communicate between parent and children to coordinate the accessibility attributes. Configuration is simple to use. You really want to write your model in the left style rather than the right style. But the composition way is not the final answer. Take the Chakra UI for example. What if we swap the position of input left addon and input right addon? We get input left addon shown on the right side and input right addon shown on the left side. It breaks semantic with a broken style. I have a hobby when I found a new design system is testing the resonance of components. By adding extra nodes to the items, we see how it breaks. For dedicated design systems, we deliver well-designed components. But you just can't imagine how alternative developers will break them in various ways. And unfortunately, we can't prevent them from doing that. You would say it doesn't matter if we follow the design order correctly. Okay, let's see a lot more realistic problem. Building an accessible list. The parent needs to know the children's information to make it accessibility compliant. For Azure Active Descendant, it's easy to achieve using the configuration way because the parent knows all the items from the item prompts. But it's a bit cumbersome for the composition way. The menu can't see its internal items. The component is blind. To solve the problem, we can use React Children with React Clone Element. Then we can take control of the rendering of items in parent component. But in terms of extension, it will break again. Even we can iterate the children, the parent is still blind, as it can't see the deep details. The problem is well described by rootUI. If you are interested, here I have a homework for you, figuring out how those libraries are trying to solve this problem. That's recap. The configuration way provides the best consistency, as the component is a single source of truth. But it's hard to extend, and it becomes a black box when multiple items are used. On the contrary, the composition way provides the best flexibility. You can customize your subcomponents freely. But it causes another problem, consistency. It needs uncontrolled use cases and wrong patterns. Then can we have a way to build components with flexibility while keeping the consistency? Yes, the answer is not. Slots is a standard for web components. In web components, slots are identified by their name attribute, and allow you to define placeholders in your template that can be filled with any mockup fragment you want when the element is used in the mockup. It's easier to understand the concept in code. First, we define a template with some named placeholders, and define the web component. Then we fill the named placeholders with named slots. Finally, we get the result with injected elements. Here you can see how the consistency is granted. The layout is defined in the template, not described by the composition order. Some popular frameworks like Vue and Svelte also implemented the slots composition pattern from framework level in a similar behavior. But as you know, React still doesn't support web components very well, not saying slots. There are a lot of approaches from the community trying to bring slots to React world. The most common way is using React-Children with React-Clone-Element, but it doesn't scale very well as component is blind that I just shown. React-Spectrum uses context and use grid order to solve the disorder problem, but the functionality is limited. For example, the grid order will change the type index in an unexpected way. GitHub Primer uses double rendering to approach slots. It renders the sub-components into a browser with empty content and gathers the slots information first, and then uses the slots in the second render. The problem is obvious. It doesn't support server-side rendering. There was an experimental package from the React core team called React-Core-Return, which provides a way to interpolate the children during render phase. It could be the best candidate to bring slots to React, but unfortunately, it was removed shortly. So I created the React-Slots-RFC to outline the problem with a proposal. Let me show you the code directly. Again, the typical text input component implemented in React-Slots-RFC. In the RFC, we introduced two new APIs called create-host and create-slot, which is very similar to React-Core-Return, but with a much simpler mental model. The create-host creates the template, and the create-slot creates placeholders, and then composes the slots in the host component. It's quite similar to slots for web components, but way much powerful, as we don't simply inject the elements, we interpolate them. It opens the third eye of the component. Now, the parent can see the deep details of its children, no matter how it was extended. Now, demo time, I will show you how the previous problems will be perfectly solved by React-Slots-RFC. Here, I implemented the React-Slots-RFC with React-Core-Return in 10 lines. And then, the text field, first, we create the slots for label, input, and tag. We pass the children to create-host, then it gives us the slots. Here you can see how we can interpolate the slots. That means we can do everything we want in a single place. Here you can see how I support accessibility for the text input. We can read the input ID directly for the label, and also we can iterate all the tags. Now, I will show you some magic. No matter how I compose the slots, it doesn't change the result, because the layout is defined. In the template, by create-host. In the meanwhile, we are still free to extend the slots. For example, we extend the tag, we extend the input, and we can change the order of tag, it will change the result, because it's a list. And the other problem, component-resilience. Let me try to wrap the tag with an extra node. It will work, because it's not a node. That's very important for a dedicated design system, because we have prepared the components. You should not change the layout easily. Let's change it back. And another use case is that, what if we use the slots outside of the host? Nothing will be rendered. That's also important for a consistent design system. And the listed slots are also supported. Have you noticed that how we create the text input, we don't need to create a styled text field label or text field input. Instead, we style it in the template. The slot itself renders nothing, but only a data carrier, that means a lot. For example, we can create a tree builder. Here is the example. We create a tree, but it renders nothing to the browser. You can see in the console log. Here is the tree, the listed menu, but here is how we compose them, but it's not rendered to the browser at all. But still, we can get the data, because the slot is just a data carrier. It's not needed to be rendered to the browser at all. You can see how it's reactive. So we can still benefit from all React provides to us, the life cycles, states, context, all the other things. Here is a package called React Neo, trying to do the same thing, but let's see the size. It's almost 100 KB minimized, even 30 KB minimized and gzipped. Doing the same thing, because it has to bundle the React reconciler in it. But with React Snots, we can use the React reconciler directly. Now you can see how we achieve flexibility while keeping the consistency in React Snots RFC with a decentralized customization and centralized control model. What does it mean for us? Now the host component is the single source of truth and takes control of its children, like the configuration way. So we can make composable components predictable. You can see how simple it is to add accessibility support. And because it's not necessary to render the slots into Realtometry, instead we simply connect the information and then decide what to render based on the connected information. So virtualization support is out of the box and more possibilities, for example, custom renderer. Furthermore, I created a package called create-slots, which implements the React Snots RFC fully, unlike other approaches which doesn't work well with some React features like server-side rendering. It uses pre-rendering, which is similar to React core-return to collect the children's information during render phase and use the information later during the same render phase. And then we can commit the interpolated result into the browser. And it has been used in Revolute design system already. As we are also using the composition way to build our shared components, we have almost 200 shared components and faced more problems than I have discussed here. And that eventually led me to this talk. But the package is not ideal, as it repeats React reconciler's work. That's why I still want to see the support from React itself. And that's it. If you want to discuss further, you can find me at GitHub and Twitter. Thank you.


Neo Nie

React Summit

React Summit 2022

Becoming a Form Wizard: Intuitive Multi-Step Workflows

Nick Hehr

React Advanced Conference 2021

Advanced Patterns for API Management in Large-Scale React Applications

Hello, and welcome to Advanced Patterns for API Management in Large Scale React Applications. My name is Tomasz Findly, and I'm a full-stack web and mobile developer with 9 years of programming experience. I'm a co-owner of Findly WebTech and a mentor and consultant at Codementor.io. I'm also the author of Vue and React The Road to Enterprise books, as well as a technical writer for Telerik and The Road to Enterprise blogs. Now, let's have a look at what we are going to cover today. So first of all, we will start with how to manage API requests in React in a scalable and flexible manner with an API layer. Then we will see how to handle different API states while performing API requests. We'll also create custom hooks to manage API requests and states, as well as how to cancel requests with Axios and an API layer. Finally, we'll have a look at how to use React Query and API layer and how to cancel requests with them. Okay, so how can we perform API requests in React? Actually, it's quite simple, right? We can, for instance, use Axios for that. We can just import it and use it in our components. And well, it can work fine for, let's say, small applications. But there are some issues as the project grows, especially large ones, really. So what are the main problems with this approach? First of all, code duplication and lack of reusability. Because imagine that we need to, for instance, fetch information about a user, let's say on the login page, register page, and the user profile page. So all of this would have the same code snippet. So Axios gets a URL endpoint and so on and so on, right? So that's not really reusable. And also, it's hard to maintain because if we had to make any changes to this code, like let's say, for instance, the URL endpoint change, or we had to change the payload format, or let's say we had to migrate from using Axios to something like Firebase, right? We would need to visit every single component that is Axios and change them. Well, that's not really great, to be honest. So let's have a look at how we can fix these issues by implementing an API layer. So first, we would start with the base API file, where we would import Axios and create a new instance with some default configuration, like, for instance, a base URL. Then we'd have an API function that basically returns API wrapper methods around our HTTP client. In this case, Axios. And finally, we export it. Next, what we can do is we can use this base API file and import it in another API file. So for example, in this case, we'd have users API file, because we want to do some things with users like fetch information about users, add a new user, and so on. In this example, we have three methods, list users, get user, and add user. And as you can see, they all use the API methods from the base API file. And how would we use these in a component now? So basically, what we would do is we would import an API method from the API directory, and then just use it in a component. So as you can see, the component doesn't have to think about what kind of API endpoint has to be hit, right? The API method takes care of that. So what about if we wanted to use a different HTTP client? Like let's say, for instance, Firebase instead of Axios. So our base API file would look a bit different. So here we would just import some necessary Firebase methods, would initialize the Firebase app, and then we would export what we need. So for instance, Firebase, Filestore, which gives us methods to basically, well, connecting with the database, and so on, and other things like off storage functions, etc. Now, in the users API file, we would again have the same methods like list users, get user, and add user. However, in this case, we're using Firebase, of course, right under the hood. But let's have a look at how it would look like from the components perspective now. Well, actually, for the component, nothing would change, because it still would import the API method from the users API file, and it would just execute it, right? So that's a really great thing about the API layer, because it's like a black box to your components, right? Because your components don't need to yet don't really have to care about what you use to perform requests, what you really want, you know, it only is concerned with what methods it should call, what kind of input it should provide, and what kind of output it can expect. As long as you can preserve this input and output contract, you don't need to make any changes to your components. You only need to make changes to the API layer, really. Now let's have a look at the benefits of the API layer. First of all, maintainability, as all the API related code is in one place, scalability, because you can easily add new API methods and files. And we also have flexibility, but it's much easier to replace the HTTP client, and also enhance the API layer with custom logic. So as you've just seen, we replaced access with Firebase, and we didn't need to make any changes to the component. And also code reusability, because API methods can be just imported and used anywhere in the application. And well, API layer pattern is also framework agnostic. OK, so next, let's have a look at how we can handle API states. So what I've seen in a lot of applications is basically using Boolean flags, right? For instance, if you want to show a spinner, you would have isLoading state. If you want to show an error, if for instance, a request failed, you would have an isError flag. And let's say if we want to lazily initialize a request, for instance, if a user clicks a button, or if a user scrolls to a certain element, then we can also have this initialized flag, right? So as you can see here, we have three different states, and then all of them are updated accordingly. The problem, however, and here, as you can see, if it wasn't initialized, we display a button. If it's loading, we display a loading data message, can display a spinner. If there was an error, then there was a problem. And finally, if everything went all right, we are displaying the data. But yeah, the problem, however, is that for each API state, we need a new state hook, right? We have initialized, isLoading, isError. So that's already three states. That's only for one API request. If we need to make two requests, we might need to have six states. If we need to make three requests, we might need nine, and so on and so on. But that's not really great. So let's have a look at how we can improve it by using API states instead. And we will also implement a useAPIStateUse hook to help us with that. So first of all, we have four different API states. Idle, which means that basically the request didn't start yet. Then we have pending, which means that the request is being performed. And then we also have success and error. So obviously, success is for when the request is completed successfully, and error if there was a problem. We also have an array here, which basically just exports the constants, as we will need it in a moment. So let's go now to useAPIStateUse hook. So first of all, we need to import useState and useMemo. And we also get the idle constant, as that's our initial state for the hook. And we also get default statuses. And the reason why we need them is because we want to basically take all our statuses and then basically return an object with basically the statuses, like isIdle, isPending, isSuccess, isError, as you can see on the right side on the slide. And only one of them will be active at the time. So for instance, at the start, only isIdle will be set to true. And now here's our useAPIStateUse hook. So we have our state for it. So in comparison to boolean flags, we have only one state that holds all the API statuses. And only one of them can be active at the same time. Then we have the result of prepareStateUses. As I mentioned, basically it's an object that has isIdle, isPending, and so on. And we use useMemo here so that it only re-evaluates if the API status changes. And then finally, we return an object with setAPIStateUses method and all the normalized statuses. Now, let's have a look at how we can use it. So as you can see here, we basically initialize the useAPIStateUse hook. And we can pass the idle there, though it's the default state anyway. If you wanted to start with pending immediately, you can do that. And then we destructure all the statuses as well as the setAPIStateUse method, which then is used to basically update this API status accordingly. Before the request is started, we set it to pending. If it's completed successfully, we set it to success. If there's a problem, we set it to an error. And as you can see in the markup, we can basically just add ternaries, right? If it's idle, then we do something. If it's pending, then we show the spinner or loading message. If it's error, then an error, and so on and so on. So it's much cleaner this way. You don't need to have as many boolean flags. And the code is much cleaner and more concise. So now let's have a look at how we can improve it even further by implementing a custom useAPIHook. So first of all, we import useState again, as well as the useAPIStateUse hook that we've just covered, and three API statuses, pending, success, and error. Then useAPI accepts two parameters. The first one is the method that will execute an API request, and the second one is a config object. So for instance, in this example, we can pass initial data inside of the config object and set it on the state for the data. Besides the data state, we also have a state for the error. And of course, we initialize the useAPIStateUse hook. Now next, inside of useAPIHook, we have the exec function. So as you can see, what it does, it takes care of basically setting API statuses and updating them accordingly, depending on the status of the request. It also takes care of setting the data after the request finished successfully. And it will also handle setting the error if there was a problem. And it will clear it out if a request is supposed to be started again. And finally, the exec method returns an object with data and error if we needed to handle them. Okay, and last but not least, just return everything from the useAPIHook data, APIStateUse error exec, and so on. And now how can we use this hook? So obviously, we need to import it and then just pass the method that is supposed to execute the API request. So in this case, we're passing a method that will just return the result of getUser, which obviously comes from the API layer. And from the useAPI, we receive an object from which we destructure the normal statuses, the data, and the exec method. And as you can see in the JSX, again, depending on the status, we just return appropriate markup. So, you know, for isIdle, the button to initialize fetching, for spending the spinner, and so on and so on. Okay, so how can we cancel requests when using Axios with the API layer? So actually, we can enhance the API layer with abort logic. So in the base API file, we would add the withAbort method that would first accept the function. So this function would be one of Axios methods, like Axios.get, Axios.put, Axios.post, Axios.pat, and so on. Then withAbort returns a function, which, well, basically, these arguments should be the ones that are passed to Axios methods. So for instance, URL, body, and config. Then what we're doing there is we need to get access to the original config. And the reason for it is because as part of this config, we want to pass an abort property, which should have a function as a value. And what we're doing here, if abort is a function indeed, then we create a new cancel method and a cancel token using Axios source methods. And on the config object, we assign this cancel token, and finally, we execute the abort method and pass the canceler there. You will see why we did that in a moment. And finally, after enhancing the config object, we just execute the request. So we forward all the parameters besides the last one. And the reason for it is because we don't want to pass the original config with the abort property. But rather, we want to pass our own enhanced config object that doesn't have the abort property, but might have a cancel token. And note that it's important that we use await here, because if there was an error, basically without await, this error wouldn't be caught in the context of with abort. So that's why we need await here. And then finally, if there's an error, we use Axios's isCancel method to check if the request was canceled, and if it was, we basically set an aborted property on the error object, and we just throw the error feather so it can be handled outside. So let's, okay, one more thing. We also need to wrap, of course, our API wrapper methods with abort. So like I mentioned before, we first pass Axios methods, and then we initialize it again and forward all the parameters. Okay, so here's how we can use it. Now, so imagine basically a feature like, you know, a search box. For instance, a user can enter some query, and there will be an API request made to fetch some information, for instance, for autocomplete. So we have two states, one for the data that will be fetched from the API, and one for the query that the user enters. And we also have the search abort ref. So that's an important part here. The thing is that we need to be able to store the canceler method in between re-renders, right? So that's why we will put it on a ref. But first, let's just have a look at the onQueryChange function. So what's happening here? Well, obviously, we are setting the input value on the query, but that's not the important part here, really. But here, before the request is initialized, we are trying to cancel the previous one. However, there might be no canceler method when the onQueryChange is initialized for the first time. So that's why we use optional chaining operator. So basically, if there's a canceler method, execute it. But if it's not, then that's fine. We don't care, but we don't want the JavaScript engine to throw an error here, right? That's why we use the optional chaining operator. And then next, as a part here, the abort property. So basically, as part of the config object, we pass this abort property that receives a function, and the canceler method is passed as the first argument. And then we can basically assign this canceler on the ref, so that when this onQueryChange is initialized again, we will have access to this canceler. And finally, in the catch statement, we basically check if the error was aborted, right? And yeah, it was. And what's really great about the way it is implemented is that basically the implementation details of the HTTP client, which is accessed in this case, didn't leak into our component at all. We didn't have to import it anywhere. Rather, we only have to provide the abort property, and that's where we get the canceler method, set it on a ref, and voila, it's available for us, and we can just call it. Okay, so now let's have a look at how we can use the API layer with GreerQuery. But actually, it's quite simple, because really what we only need to do is import the API method from the API layer, also import whichever hook we need from React Query, like for instance, useQuery in this case. And then we just use it, right? We pass the key for the query, then we pass our list, well, in this case, list users, so the API method, and we just destructure what we need. So for instance, in this case, we get data, we get the refetch method, which can be used to initialize the request, and we also get our normalized state uses. Again, and this part is basically the same as it was with, let's say, with our own useAPI hook, right? And depending on the state use, we render appropriate content. And how can we cancel requests when using API layer with GreerQuery? Well, again, right? We can basically pass an abort property. However, this time, what we are doing is we're not using a ref, but rather, we have a cancel variable, and we assign this cancel method that was passed through the abort property to this cancel variable. Because the thing is that the way React Query works is that it expects a cancel property to be available on the promise that is returned. So that's why we need to do it this way. It also is very concise and clean. And here, finally, if you want to cancel the request, we just need to call cancel queries. That's it for today. Here are the links to the GitHub repo with full code examples, slides for this talk, and websites where you can find me. What's more, I have a special gift for all the conference attendees. React the Road to Enterprise is coming this December. It's an advanced book with best practices, patterns, and techniques that covers many various concepts such as scalable project architecture, local and global state management, testing, API handling, performance optimization, SSG and SSI with Next.js, and more. You can get 35% off with the code REACTADVANCED. Well, I hope you enjoyed this talk and happy coding.


Thomas Findlay

Full-stack & typesafe React (+Native) apps with tRPC.io

Hello, I'm Alex. I'm here to talk about full stack React and TRPC. I've been making websites for a really long time and been working with React since 2016 or so. I've also worked a bit as an iOS developer and whatnot. Today I'm here to talk about APIs. I know this is a content conference, but just bear with me. You'll realize it's not that hard. So to break it down, let's start with the question, what is an API? So in the context of HTTP, very simplified, an API is just a way of calling functions on another computer. And the way we make and use APIs today might look something like this. We start with an API contract or schema because we want to have some guarantee that our API is actually returning what we want it to return. And then we might write code generation in order to help our backend logic on what it needs to return. And then once we've done our backend, we write an API query on our frontend, which then might have some code generation attached to it to generate a nice use query hook that we can use at the end. So I think there's quite a few steps to doing an API today. And the reason for this, as I see it, is that we have decoupled our backend and frontend completely, or rather that we have made them disjointed. But what if our backend and frontend didn't have to be decoupled? There are tools today where we can write the same sort of language on the frontend and backend and mobile. And one of those tools is TypeScript. So TypeScript is a good language which you can use everywhere. And I've been working hard over the last 10 months to create some set of tools to simplify the sort of API development with your React apps. And yeah, I'm here to introduce tRPC. tRPC is a toolkit for making end-to-end type safe API in a very easy manner. I'm just going to dig in to show you how it looks like. So when you write a tRPC backend, you start something like this. You have a router where you nest all your queries. And here is a query called hello. So we call this a procedure in tRPC. You can also view it as an endpoint. And all that this function does is that it returns some data. And when we then use this in our frontend, we get straightaway auto-completion of all our API endpoints. And we get the data inferred from your function in the backend to your frontend. And this doesn't rely on any code generation. It's just a bit of an abuse on the TypeScript compiler. And it's a thin wrapper around React query. And what you see here works exactly the same in React Native. And if you want to, you can incrementally adopt tRPC to your project, or you cannot use it at all if you don't want to. So let's see a bit more complex example. Here we have a backend that is actually talking to a database. So you can see here that we have a post by ID query. And that takes some input data through a validator. And you can see that the types of that validator is inferred straightaway to the frontend. And then at the end, you can see that we are talking to a database through an ORM called Prisma. And that gets some data back that is also then inferred straightaway on the frontend. So I started working on this open source project to scratch my own itch around January. And since then, it's gotten quite a lot of traction and a lot of companies are using it in production already. It's really well tested and I would really love for you to check it out. It's used right now for everything from COVID vaccination bookings to insurance companies to grocery delivery apps. Obviously, this is lightning talks. I want to be able to cover all the features of gRPCs to mention a few of what you can do. So that have mutation help us. This is a similar way that we have the use query stuff that I just showed you. We can do painless SSR and we can do a lot of other stuff as well. I'd love to hear from you if you love or hate gRPC. You can reach me on Twitter at Alex.js or by email on Alex at gRPC.io. Thank you.


Alexander Johansson

A New Kind of Abstraction

Hello everyone, I'm Mike Harkington. We've already had a full day of a lot of technical topics. Let's take a break from that and talk about ideas and abstractions. So as someone who came from a non-engineering background, I was taught that an abstraction is this thing that builds on top of another thing. Simplest example is we have this low-level library or low-level API, and we just have all these kind of rough implementations of how to get things done. This could be assembly, this could be C for you, this could be a raw DOM API. People come together and they realize that that is not going to be very productive, they're going to be stuck having to maintain the nuances of a low-level API, so they go ahead and they create an abstraction. They build on top of it, they provide either some kind of utility or some kind of library that can sit on top of that low-level API and give you a better time developing. People come along later and they realize that that's a pretty good starting point. Let's go ahead and make something more. Let's make this a little bit more easier. Let's remove this method because it's not really used that often. There's a lot of foot guns in there. Let's give you something that's going to be simpler, easier to understand, and let you get to build whatever you want. So on and so forth. We sit with this level of abstractions where we either look at them as being very, very low-level or very high-level and the spectrum of very high-level to low-level and this hierarchical spectrum is how we typically look at it. Now with this hierarchical approach, we also have to consider that whatever is at the high-level might also include more code, whether that's run time or just in general as a library. Might include limited feature set but still handle edge cases. So the smaller the abstraction, the closer that it is to the lower-level, maybe, maybe not. In addition, the abstraction also could provide escape hatches to the low-level. For example, not in JavaScript but in Python, you can import C modules. You can write some C, import it into your program and have access when you need that escape hatch. Lua offers the same thing. There could be JavaScript libraries that instead of returning their own custom object, they return a valid JavaScript object, whether that's a date or something more. So these are the ways I was taught to think of abstractions and as time has kind of gone on, I've realised that there's another way. We could think of them as a spectrum. Now it's not just about how far removed from that low-level API are we operating on, but where is this code going to live? What's its execution target? Is it going to be the browser, server? Are we going to be doing cloud functions? For example, node, deno and the browser. Is this code going to operate in both the browser and node? Maybe. Is it going to operate in node and deno? Probably not. How that code operates and how that code is approached is just another level of abstraction. If we use a library that operates really well in the browser, chances are it could run in deno but we don't know. So how far removed is it from that target? One that I'm really familiar with is the idea of cross-platform. We have one side the web and we have the one side native. Now, depending on where you are, where your team sits, you could be picking abstractions that are one degree removed from pure native. Or you could be picking abstractions that are one degree removed from just pure web. Doesn't matter if they're... Don't look at them as if they're better or worse, look at them as just being opposite ends of the spectrum. This is stuff that we think about daily at Ionic where we think we have our abstractions sitting right at the middle. We give you access to the web but we also give you access to native. So is that a middle ground? Is that better? Is that worse? The answer is kind of up to you but it's just a different way of looking at what that code is. It's not necessarily better or worse. It's just going to give you the options. So understanding that code and abstractions are less about the performance impact, the actual size, the level of removed from low level. It's really about your code, performance size, and where is it going to live? We could have code that works in all of our devices right now but in a few years, is it going to be able to work there? Are there going to be more platforms where this code can't run because it's using the wrong abstraction? So as a team, evaluate what abstractions you're using, what their portability is, and also how far removed are they from the low level? Those not discounting the hierarchy. I'm just saying evaluate more on the spectrum. And with that, thank you.


#patterns