Feature Flagging With React

Rate this content

Decouple your releases from deployments, while maintaining full engineering control of your application.

27 min
23 Oct, 2023

Video Summary and Transcription

Feature management in React.js applications involves techniques like feature flags and toggles, allowing for decoupling of application deployment from feature releases. Gradual rollouts, remote configuration, and audience targeting are key techniques. Increased control and flexibility in feature management provide targeted launches and quick rollbacks, but there are pain points like lack of reviews and approval workflow. Infrastructure as code (IAC) and GitOps are practices that can be combined with feature management. Feature Advisor is a tool that helps with feature management in React applications, focusing on principles rather than the tool itself.

Available in Español

1. Introduction to Feature Management

Short description:

Hi, everyone. My name is Fahad Hilal. I work as a Principal Engineer in DAZN company. Today, I'm here at React Advanced to talk about feature management in React.js applications. I'll focus on the conceptual side of things, the techniques involved, benefits, and pain points. I'll also touch upon infrastructure as code and GitOps. Then, I'll show you how I combined these concepts to create Feature Advisor. The tool is negligible; it's the concepts that matter. I'll demonstrate how to bring this practice to your React application. Feature management is a practice consisting of techniques like feature flags or toggles. It's an if condition that externally manages true or false values, not hard-coded in your application.

Hi, everyone. My name is Fahad Hilal. I work as a Principal Engineer in DAZN company. We are all about sports streaming and many other things related to sports. And today, I'm here at React Advanced. Thank you for letting me come here and give you a talk about feature management in React.js applications.

So initially, when I submitted my talk, I had the idea that I'll just come in and talk about a new open source project of mine and just like advertise it, let everyone know about it, but I realized that's going to be a big, big failure if I really do it that way, because then nobody will understand why I even built that tool and what are the pain points and suffering that led me to even think of building such a tool. So then I backtracked a bit and then I made this my agenda. So I want to focus more on the conceptual side of things, starting with feature management, like what it is, what kind of practice it is, the techniques involved in it, and how we can adopt it, what are the benefits, and also what are the pain points that come with it.

And very quickly, after that, I also want to touch upon two topics called infrastructure as code and also GitOps. So I really want to insist that I understand this is a conference that is focused more on the React side of things in the front-end area. Even if you do not know these terms, I have a very strong feeling that you actually know it without knowing these terms. So I'll clear that up very, very soon. And then, once we have covered the conceptual side of things, I'll show you how I combined these three different practices, three different concepts together to create this solution that I call Feature Advisor. And then I also want to, again, mention that the tool is the negligible part of this talk really. A tool could be anything, like it could be a third-party SaaS tool or this tool that is open source or something that is bespoke and built by yourself, it really doesn't matter. So it's really the concepts, the practice in software engineering. And then of course, because it's a React advanced conference, so I also want to show you how you can bring this practice in your React application and also benefit from that. So I promise that I'll show you some code, but at the very, very end.

So first things first, what is feature management? What is it like? How does it differ from some other source of management, like content management or things like that? So if I were in the same room with all of you, I think I would have asked you all to raise your hands asking, have you ever used feature flags before in your organization, in your source code, in your team? Have you ever done that? But since we are remote right now, so I will just go ahead with my slide. So I'll start by saying that feature management in the end is a practice. A practice that is consisting of several different techniques that we apply in software engineering. So the first one that comes to my mind is called feature flags or feature toggles that you might already have used before. So if you have not, then I want to mention that it's really an if condition, an if statement. It's an on off switch that you check in your code somewhere with an if statement somewhere. It could be JavaScript, it could be Golang, really language doesn't matter here. And if something is true, you do something. If not, then you do something else. As simple as that. But the idea is that conditions that evaluate those values as true or false is something that is externally managed and something that is not hard-coded in your application.

2. Feature Management Techniques

Short description:

Feature management allows you to decouple application deployment from feature releases. A-B testing, gradual rollouts, remote configuration, and audience targeting are key techniques. Gradual rollouts involve launching a new feature to a small percentage of traffic and gradually increasing it. Remote configuration allows external management of specific product behavior. Audience targeting, like Facebook's use of New Zealand as a testing ground, is another approach.

Because the idea is we want to decouple your application deployment from your feature releases. I'll talk more about it soon in the next slide, but for now, let's just assume that it's an on-off switch that just controls the behavior of your application in certain areas.

And then also, if you are into more product development, you might have also heard about A-B testing or multivariate testing. So, what happens is, imagine you have a new sign-up journey designed and you want to test different variations, like variation A, variation B, variation C. So, you want to test it against all your traffic. So, maybe 33% of the traffic gets variation A, other 33% gets B, and the others C. And then you figure out which one converts best. Is it the B variation that gives you the most successful sign-ups and on? So, this is one of the techniques as well that you externally manage while influencing your application without requiring any further deployment.

And one other thing that's very, very crucial that I found in my carrier is the concept of gradual rollouts. So, imagine you and your team have been building a new product feature that you're launching, let's say, next month. You don't really want to go for a big bang release. You don't want to release it to the entire world or to 100% of your traffic. You want to be confident that, hey, we built this thing for such a long time without exposing it to users. Maybe you should figure out if it actually works with real users at all before we expose it to everyone. So, what you can do is launch it only to 5% of your traffic. Then 10%, gain some confidence, see that everything works well with your back-end system, with your front-end code and everything. And then you gradually move the percentage level all the way up to 100%. And you know that, okay, now it's completely out. Nothing is held back for anyone anymore. And so that's gradual rollout.

The other one is remote configuration. Imagine you have some very specific product behavior that you can parametrize, and you do not want to hard-code that configuration in your application itself. So you manage that configuration externally, and you can tweak the configuration whenever you feel like it, and it influences the behavior of your application right away, without requiring any further deployment. How amazing is that? Imagine this new redesign that had some toggle, like on or off. You could just toggle it off whenever you feel like, because you think that this is causing some harm to your production environment. And then comes audience targeting. So I'll pick one example from Facebook, actually. They call themselves Meta now. So New Zealand was always their playground, their testing ground. So they used to always launch these new features and they would expose it to users in New Zealand only, for some reason, don't ask me why.

3. Importance of Techniques and Decoupling

Short description:

And then they'll figure out if it's working or not. Audience targeting allows you to expose features to specific audiences based on runtime conditions. Decoupling releases from deployments helps maintain a separate feature configuration and code. It also promotes continuous delivery and avoids long-running feature branches.

And then they'll figure out if it's working or not. Even in Netherlands, there are big companies sometimes launching some new products in Netherlands first, before they roll out to the rest of the world. So they target their audience. So this is audience targeting. You figure out in the runtime if the country is equal to Netherlands or country is equal to New Zealand, I want to expose this feature for the rest of the audience. I do not want to show anything yet until I'm ready. So that's audience targeting.

So I'm talking a lot. And so this is actually just the techniques that I mentioned. But why even adopt them? What is the need for even knowing these techniques and why incorporate them? How does it make your life better? So now we move on to the next slide. So this is only the few handful of items that I have come up with for this talk. So the first one is decoupling releases from deployments. So now this may sound a bit confusing, like what is a release and what is a deployment? So deployment is when you ship your code. So imagine you built a React application and you have bundled it. It's already sitting in a dist folder somewhere, and you upload it to a CDN or your server. So that's the deployment part. The code is being shipped, but code being shipped doesn't necessarily mean that it's actually already being exposed to users. Maybe there are some certain features that are not in enable state, like behind a feature flag. So that's the decoupling part. So you keep them separate, the feature configuration and the feature code itself. That's a shipping part.

And so it also, like if you adopt this way of working, like when they are decoupled, it also helps your team and your organization to adopt this mindset of continuous delivery. And what do I mean by that? So there are different approaches of managing code in a Git repository or any other versioning system. It doesn't matter. It's called often trunk-based development. So you keep on merging new features that you develop, and you just keep merging it to your main branch or master branch, whatever you want to call it, and you just ship the code. But they are not actually exposed to your users yet until you feel ready. And this helps like avoid having to maintain a long running feature branch for a long period of time. It introduces so many conflicts, if there's so much sync issues, you can really abort all that. So misdelivery really, really helps you there.

4. Control, Flexibility, and Pain Points

Short description:

Increased control and flexibility in feature management allows for targeted launches and quick rollbacks. Centralization of feature flag management provides visibility and alignment across teams. However, there are operational pain points, such as the lack of reviews and approval workflow in most feature management tools. Additionally, the limitation of creating a single project for feature management can be restrictive.

Other thing is increased control and flexibility. So by control, I mean it can control who sees what, where and when. I mentioned the country's like based configuration before. So it could be like anything, it could be also like saying, Okay, I only want to launch my feature to people aged above 25 or below 50, like whatever, you could come up with these conditions yourself. As long as the evaluation is being done by the code, the configuration could be coming from somewhere else, totally separate from your application, giving you that flexibility.

Risk mitigation, one more thing. So I mentioned it briefly before. So if you have some feature that is like a launched, but you realize that okay, it's like a causing some bad to happen in your, like organization or your system. So you can quickly roll back, you can just disable it very, very quickly without having to coordinate, I don't know, deployments across maybe 20 or 30 different teams, depending on your organization size. So it always like centralized in one place is much more easier and with centralization of all these like feature flag management, like configuration and their product specific behavior. It also gives you a very solid visibility in your entire organization. So product, marketing team, engineering, of course they can all come together and get behind a single source of truth. And they can collaborate in one place without leading to any confusion or any like, pain and suffering that can come from it if people are not aligned. So these are like all good things. I mean, I think we can agree that we at least I get some benefits like by just going to this list here.

But in real world things are not just rainbows and butterflies all the time, you know, like there are many, many operational pain points that come with it. So I'll briefly mentioned those two. And I can really tell you that every single item here has caused me great pain in my career. listed them down here in this list. So the first one is, having a reviews and approval workflow. So what happens with most of the tools is like there's many third parties like SaaS tools there for like feature management needs. And the ones that I reviewed myself, I would say more than 80% do not have this reviews and approval workflow. So most of us in this audience right now, I'm assuming that we are mostly engineers. So we know how to work with Git and GitHub. And we know how to send full requests. So we have a very review and approval based culture, you know, so we like to like make it peer reviewed before something goes live. So this is something that doesn't always exist in feature management tools that I really, really dislike. And it has caused so many issues before, like in my jobs, like multiple different jobs. And this is something that I really miss. Another thing is that most of these tools allow you to create a single project and it makes sense that you want to have your entire, like feature management managed centrally as in a single project.

5. Configuration Serving and Pain Points

Short description:

The serving of configuration in feature management can lead to performance issues and unnecessary loading. Deprecating unused features and establishing ownership are missing features in many tools. Feature dependencies and testing in production are operational pain points that need to be addressed. Operational pain points can be more challenging than coding challenges and technical issues. Be adaptable like water in high-pressure situations.

So everyone can see everything. But the problem is the serving of this configuration. So imagine you have a front-end application, there is landing page, there is a sign in page, sign up page, there's a checkout flow, all that. They're separate areas of your, like, you know, like organization, each team doing their own thing. Even though like from end user perspective, you are seeing them all together. But when you fetch the configuration, you might be loading, let's say, configuration of checkout area, when you're just trying to render a landing page. That's not really cool. Like with web, like performance is like a very important, like we only want to like load as less as possible to deliver the maximum value to our customers so that we can give them a good experience, make the page load really, really fast and all that.

So this thing really, really hurts this configuration size that we all need to fetch for our like feature flags. Deprecating is one other problem. So with these tools, you see that people just keep on adding and adding more feature flags and more feature configuration like to the tool, and they never delete them. And because everyone is afraid to delete anything, what if like I delete something and it like break something in Australia or break something in the United States, because we don't know. So if we have a deprecation workflow saying that, okay, if someone is evaluating this feature, show them a warning so the engineers can like take care of it themselves for removing it. So this is also a missing problem, missing like a use case that I see in many tools.

Feature dependencies, when you have like one feature depending on another one, that's also like a concept that doesn't exist in many tools. Another one is establishing ownership of all the features. So if I create a new feature flag, do I get to assign myself as an owner or a team as an owner? So as owner, so that the next time you want to change something so that he can know like who this person is or who the team is that I need to communicate to. Testing and production, another one. So if you have a QA team in your company, you must like consider yourself very, very lucky because not many teams and companies have that. So everyone has to test everything themselves before they shift to production. So many of the tools are not really designed around the QA workflow, the quality assurance team. So you want to maybe expose a feature flag as enabled only for your QA team only so they can actually test in real production before exposing to the rest of the users. So this is another operational pain point that I have. So I've been mentioning a few of these, every single item that I face myself, I'm sure like many of you have faced yourself as well. And trust me on this when I say it, coding challenges, technical issues are something that we, most of us can handle. But operational pain points, like when you have to be in a room full of like 15, 20 people, everyone like stressed out trying to figure out what went wrong, where and you don't know it, you really want to avoid that kind of situation. You don't really, really want to be there. And this is a gif that I just like added in the slide. So a great man once said, like in this kind of situations where external environment is trying to put too much pressure on you or like you are getting too much like inputs, be like water. Like it was a Bruce Lee, a very disciplined man.

6. Introduction to IAC and GitOps

Short description:

As much as you want to be composed and calm, sometimes stress can bring out a different version of you. I poured my experiences into a new tool I built. Infrastructure as code (IAC) is a practice where infrastructure is provisioned and managed using declarative code. GitOps is a new term that manages everything in a git repository, providing a source of truth, reviews and approval workflow, automation, and audits.

But thing is in reality, I mostly act like this. So I mean, as much as you want to like, you know, be very composed, very calm, when stress level is high, and there are many people from different departments coming together, like sometimes a different version of you can come out. And all of that, that I learned actually, through this journey, I tried to pour into this new tool that I built that I want to show you soon.

But before I go there, I just want to mention two new topics very, very quickly. So first one is infrastructure as code. So this is a sentence I copied from Google with some edits. So infrastructure as code is a practice in software engineering where infrastructure is provisioned and managed using declarative code. And by declarative code, I mean code but code that tells the system what like what to do, but not necessarily how to do it. Because we have what all the manual process is like we are telling almost a person like do this thing and the person figures out how to do it and then it gets the job done. And if I give you some quick examples, there's Terraform, there's Docker, there's Kubernetes and all that. So they're all like adopting this ICC principles, ICC short for infrastructure as code. But I really want to focus on the last part only because I think that's where we have the common ground in front end and back end. Many of us have already dealt with CI, CD pipelines, GitHub actions is a popular one. They are also like free for open source projects and all there's GitLab CI and there are more. So what happens is we define what we expect from our CI, CD pipeline in workflows. We define a YAML file with a job, with the steps, and then we just like hand it over to GitHub and GitHub source everything out for us. It runs the job, it gives us a green or red status based on if the build passed or build failed. So all of that is taken care of by them. So we don't really like to figure out all the little hows to make that work. So that's really IAC.

The next one that I want to quickly touch upon is called GitOps. So we know about DevOps and other sorts of operational works, but GitOps is a new term that's also gaining a lot of popularity and it builds on top of the principles of IAC, but we manage everything in a git repository. So everything is like declared in a declarative syntax like YAML file or JSON file or TOML. It could be any language of your choosing, as long as it is declarative, like without any programming code. We use everything in Git. So everything is, this is a source of truth. We have reviews and approval workflow out of the box because everything goes via pull requests and we have automation via CI-CD pipeline because everything's like backed by it. And of course it's Git, so we have audits like out of the box because it maintains all the changes that we have and it has a full history. So no, everyone will know like who did what when, so you have like more like transparency in your organization right away. So we learned like a few different concepts.

7. Introduction to Feature Advisor

Short description:

I struggled with the concept of bringing together infrastructure as code, feature management, and GitOps. After cracking the API in my head, I developed Feature Advisor, a free and open-source tool that works with JavaScript and React. However, the tool itself is not the most important part. It's the principles that matter the most.

Now we learned about infrastructure as code. We learned about feature management. We also touched upon GitOps. So I really was like struggling with this concept for the last two or more years and wanted to figure out like, is there any way to bring these three parties together and build a solution that can make engineers lives happier? So that's why I, and this year I finally cracked that API in my head and I really went for it. And so I'm calling that tool Feature Advisor. It's free and open source. It works with JavaScript, it works with React, with SDKs and all. And again, I want to say that the tool is not really the important part here. I'll show you some of this tool's functionality. You can really use any other tool, but it's the principles that really matter the most.

8. Working with the Tool and Defining Features

Short description:

I will show you how the tool works and how you can apply this learning to other tools. GitOps applies to feature management by decoupling releases from deployments. You send pull requests to update feature configuration, which is then built and uploaded to a CDN. In your application's runtime, you fetch the configuration and use Feature Advisor SDKs to evaluate values. The three building blocks are attributes, segments, and feature allow rules.

And this is where my slides actually end. I will go to the website quickly to show you how that tool works and how you can even take this learning to any other tool of your choosing. Maybe you can build something yourself and benefit from that. This is the homepage. So I'll ignore the landing page details for now and I will take you straight to the bottom of this page and I will show you the way of working with this tool.

How does GitOps apply to feature management? So you have a Git repository. This is your feature advisor project. This project, this repository is independent of your application code. So that's how we make releases decoupled from deployments. And you send pull requests for updating all your feature configuration as their individual YAML files. And once the pull request is reviewed and merged, a CI-CD pipeline takes in that you own yourself. I have templates for GitHub Actions so you can copy that if you want. And it will build the configuration files that is consumable, and then it will upload to a CDN of your choosing. It will be your own server.

And the third step is basically, once those configuration files that is built and uploaded to a CDN, you can fetch it in the runtime on your application. And by runtime, I mean if you are a React application developer, it could be the browser environment. You fetch that configuration from the browser directly and use Feature Advisor SDKs to evaluate those values as true, false, or some other variable value. And there are three building blocks to defining the features. So I will quickly go through them. Attributes are like fields. For example, if you want to have a condition set against countries, like if country is equal to New Zealand, or country is equal to Netherlands, so define a country attribute. That's your field that you will have a condition against. So here I'm creating an attribute slash country dot yaml file. I'm saying it is of type string, and I have some description just for documentation purposes for us humans. And then comes the segments part. Segments is like how you define like, what are our targeting conditions? So if we want to let's say target iPhone users in the United States, this is like one way that we could define it. So you'll have an iPhone US dot yaml file. And in our conditions, we'll say that, okay, the country attribute must equal to the value of US. That is the country code of US, United States, and the device should equal iPhone. So all of a sudden, we just have like a segment, reusable segment that we have defined that we can use when we define our feature allow rules.

9. Feature Definition and JavaScript SDK

Short description:

Segments have an exhaustive list of operators. Features are defined using feature flags, with three possible values: flag value, variation, and key-value pairs for configuration. The simplest form of feature definition is creating a new sidebar.yaml file, defining rollout rules, and specifying the target audience. The JavaScript SDK is universal.

Segments have like an exhaustive list of operators that you can use, like beyond just equals operator. So I do not really have the time to go through all of them, but you can come back to it later. Like when you visit the website.

Then comes the features part. This is like the most interesting part. This is where you define your individual feature flags. The idea of defining a feature is you either want to evaluate one of three different values. The flag value itself that is like an on and off status. There's variation. You can use AB test. If you're using variables for like remote configurations, you can also use some key value pairs as configuration here. So here this is a very, very simplest form of feature definition in Feature Advisor. So you create a new sidebar.yaml file because that's what you want to call your feature flag. So you have a sidebar and then you define some rollout rules in a different environment. So here I only have production environment, but imagine I could also have like staging environment or development environment or anything else, you know, it's totally up to me to customize it. And then I have the rules. I'm saying that, okay, I want to launch it to everyone. So asterisk means that all segments, full audience and percentage is like if I wish to rollout gradually. So it could be any value between zero and hundred. And we previously created a segment called iPhone US. So imagine we wanted to launch this sidebar feature to only iPhone US users only. So we could have done something like this in the segments instead of asterisk. We could just say like, okay, instead of Germany, I could just call like a United States or iPhone US users, anything, you know, we are totally free to compose our own targeting conditions the way we want customizing against our own needs. So this is the definition part.

So I will not touch upon the topics of the CICT part. Like it's just like one command that builds everything. You can use that from the website. But I'll quickly touch upon the SDK itself. So the JavaScript SDK, so I'm going to come to React like right after this. So the JavaScript SDK is like universal.

10. JavaScript SDK and Feature Evaluation

Short description:

The JavaScript SDK allows you to initialize feature flags by providing a data file URL. Once initialized, you can evaluate the feature flags and perform actions based on their values, such as showing or hiding components. The SDK also supports variations and variables.

It works in Node.js and also in browser environments. There are like more SDK's in other languages and development already, but JavaScript is like the one that's already done. And you just initialize it by providing a data file URL. So imagine you downloaded, uploaded your like configuration file to your own CDN, you just provide that URL. And you just initialize that using the create instance function of it. That's it. And once you have it, you can like evaluate your feature flags by calling, if the feature of other instance has this feature key as enabled or not, you get the value and do whatever you want with it. Like you can do if it's enabled, show this sidebar, if not enabled, do not show it. It could be anything. Same thing for variations and variables and all that.

11. React SDK and Decoupling

Short description:

The React SDK complements the core JavaScript SDK, providing a small and efficient solution. It includes a provider component and various hooks for checking flag status, variations, and variables. It works with React Native as well. With this tool, you can decouple application development from feature management and easily tweak configurations without redeploying all applications. It enables centralized management for multiple teams and services.

But I really want to like move to the React side now. And also because we are in a React conference after all. So the React SDK complements the core JavaScript SDK, which is only like six kilobytes in size, the core SDK. Like it's very, very small and very, very efficient. And there's a provider component that you import from the React package of FeatureVisor. You set the instance at the root of your components tree, so that like all your child components can like make use of this. And it has a bunch of different hooks. So if you want to check the flag status, if a certain feature is like enabled or disabled, you can import the use flag hook and then call it synchronously in your component. And then like evaluate it and react to it like whatever way you want. Same for variations, like use variation hook or A-B test. Same for variables if you want to have some remote configuration. So all of that is, all of the common use cases are like already covered for you. And it works with React Native too. So I tested an iOS application myself. There's an example repository too. So it's the same package that works everywhere, because React Native already comes with a fetch API. So you have that covered. That's the only API that FeatureVisor has a dependency on. And so yeah, like you really can completely decouple your like application development and your feature management separately. So that like you can tweak the configuration at the time of your choosing without having to go through the deployment process of all your individual applications in your organization. And many of you may have like multiple teams managing multiple different services in backend, frontend. You can bring them all in one place with this tool.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.