Cory House
===

Paige: [00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics which surface the UX and technical issues impacting user experiences. DevTools your users are struggling by trying it for free at logrocket.

com. Hello, everybody. I am your host today, Paige Niedringhaus. And today we have Corey House, a React and JavaScript specialist, here to talk about creating custom DevTools for your React app. Welcome back to the show, Corey.

Cory: Thank you for having me. ~Okay.~

Paige: ~Well, ~as you've heard before, we have had Corey on, I think, last year recently, and I got to interview him then, so it is nice to see you again, and,~ uh,~ let's just dive right in.

So you actually gave this talk at React Rally most recently, and you started by talking about how, you said, we shape our tools, and then our tools shape us. So maybe you can explain what inspired that perspective, and how it applies to software development in [00:01:00] particular. 

Cory: Yeah Ive been thinking about this a lot because uh tools over the last couple decades have continued to improve they've actually colored the way that I think about. Automated testing altogether. ~It's, ~it's funny, but you go back to the early two thousands and I was very negative on automated testing.

And I wouldn't say that to anybody. ~I, and ~I didn't say it out loud because I had a feeling that my feelings about it were largely colored by my inexperience. And I thought,~ well,~ maybe if I just need to get better at this, then it will be easier, but I also recognize that back then. It was just a harder thing to do.

The tooling wasn't as mature. ~Uh, ~it was slower. It didn't do things like automatically wait for things to show up. ~Uh, we, ~we just had, we had fewer debugging tools. We also just had,~ uh, ~patterns that didn't lend themselves as well to. Unit testing in particular, we didn't have component libraries. So there's a lot of things that have shown up in the last decade or so that have continued to make automated testing easier.

And I've thought about just also the sorts of tools that I use. And even the way that I set up my [00:02:00] office itself impacts all of this. So like my office, I have a standing desk. I have a treadmill desk that I sit under my standing desk and I deliberately leave it up ~every, ~every once in a while. Night when I'm done with work, even if I was sitting that night, because I want to come ~in, ~in the morning and my tools should shape my behavior.

So if my tools are set up in a way that says, okay, if I'm going to work at my desk, I'm going to have to stand on the treadmill, at which point I might as well, turn it on that removes a set of friction and it pushes me in that direction. So a lot of what I've been thinking about is how do we create tools and development environments that make automated testing feel like.

A very natural decision, make it feel easy, make it feel,~ um,~ more than just testing, but as an accelerator for development itself.

Paige: So instead of it being an afterthought or something that you have to do to get to your team's kind of definition of done, it should be more of a thing that you want to do to feel more confident in your code. And like it's, like you said, ~kind of ~a natural extension ~of just the, ~of the [00:03:00] other code that you've already written.

Cory: Yeah, ~I think, ~I think about a lot of what I've done through my career is repetitive. And as a developer, anytime that I'm doing something repetitive, that should set off alarm bells, it should trigger me asking, is there a way for me to avoid doing this manually and repeatedly, because a large portion of my job is figuring out how to automate these things away ~and, ~and a great example of this is how I've filled out forms countless times, manually, ~and ~Until they did exactly what I wanted because,~ uh, I've, ~I've built a lot of crud apps over the years.

~So, uh, ~a model in my head that I found really useful or a mantra is a better way to say it is that I should rely on automated tools to interact with the application to the point that I should feel comfortable writing an automated test and. I can trust that it passes without me actually watching that test run.

If I get a green, then I can feel confident that I have implemented the feature successfully. And this isn't to say that I don't actually look at the test and be critical of it, but I have worked on teams where we had [00:04:00] such good test quality and such good test coverage that I truly did feel comfortable coding blind.

And when I say blind, I mean, adding a UI feature, adding tests for that UI feature. And watching those tests pass, feeling like, okay, the only real thing that I need to look at is the CSS that I wrote. Does it visually manifest in the way that I expect, but the feature itself, I could feel very confident that it worked.

And I never manually clicked. I never manually filled out a form. I just asserted these things happening. ~So, uh, ~I love what I love about that is this feeling of it. It motivates me to write the test for selfish reasons. I just, I don't want to have to manually do these things. And Hey, if that's an incentive to get me to do the right thing, then that's a win for everybody.

Okay.

Paige: So one of the things that you mentioned pretty early on in your talk as well is that it is easy for developers to overlook the tools that they use daily. So what are some of the risks that you would say of sticking to the familiar tools without looking into better options [00:05:00] or ~newer, uh,~ newer options and solutions?

Mm

Cory: Well, something that I see is we're at least in a culture now where automated testing ~is, ~is more and more the norm, which I think is wonderful, but I'm still seeing a lot of teams that are struggling with doing it well. And to emphasize this whole point, I recently had put ~in a. ~Out a poll on Twitter, which I found fascinating.

And I said, imagine you're in a situation where you have to choose between types and tests. And what was fascinating about this poll was I think around 5, 000 people filled this out. It was very popular. And in the end, the results were 49 51. It was almost exactly 50 50 until the very end where. Types surprisingly won out over tests.

And I say surprisingly, because I had figured that most people would say tests because types, for instance, do not tell me that the code does what it should. It merely tells me that it compiles. Whereas ~a test, ~a test does actually tell me if the test is written well, then it does tell me that it's doing what we expect.

But the problem that you run into is ~there's a whole set of. There's, ~there's a whole set of mistakes that can happen in tests that can be subtle. And there's a lot of teams that [00:06:00] struggle with writing tests well. So that's something that I've been really enjoying helping teams do better. But in particular ~that this, ~this comparison between the two, I think is relevant because I find teams struggle less with using types.

~Well, ~yes, you'll see teams sometimes,~ uh,~ create overly broad types, or if you're in TypeScript, use something like any,~ uh, Um, ~and that's not necessarily a problem, but if it becomes pervasive, it certainly can be to the point that you're not getting much value out of it anymore. But that sort of thing, analogous and testing seems to happen less often.

~Um, ~or ~I, ~I should say,~ uh, ~seems to happen more often. ~The ~things like somebody writing a test, but not even actually asserting. The expected behavior,~ uh, ~it's a test that sets things up and then they forgot to do the expect and that might Quietly pass and you don't realize this is why you have the old saying that never trust a test that you haven't seen fail and this one has ~uh ~punched me in the face more than once where I Wrote the test and it was green and I think I'm done.

~And ~then later I realized that I should have done TDD because I never saw it fail. It actually passed for the wrong reason. ~So, um, ~those things can [00:07:00] happen. ~But the, the, I mean, ~back to the core point that you made, ~where. ~What people run into is

Paige: ~Silence. Silence.~

Cory: they know that they need to write tests, but ~if, ~if we merely say that, and we stop there, there's a lot of headwinds to doing so, not the least of which is everyone needs to agree on where do we put these things?

How do we name them? What is our mocking strategy? When we do these mocks, how do people flip between these different settings? Do we have a. Database that is shared among different developers. At which point now we have shared mutable state, which means that our tests can't possibly be reliable. So how do we get around that problem?

So there's, there's a lot of things like ~that, ~that, that lead to. Like stepping back and saying, all right, from first principles, how can we create an environment that makes it easy for us to write the tests in a reliable, fast manner, comprehensive. ~Uh, ~and that does mean early on moving more slowly so that we can move faster.

Later.

Paige: So you were actually talking about creating a custom dev tool, which ~I, ~I doubt a lot of people have done. It's something [00:08:00] that I've never considered as I've done my own ~lower, ~lower life cycle and local development. So can you talk a little bit ~about ~more about what custom dev tools are, how they are different than something like Chrome dev tools that you would just open up in your browser or React dev tools that you would install as a plugin?

Cory: Yeah, those are great examples. So when people think about DevTools, just about everybody that's doing web development is familiar with Chrome DevTools, or more broadly, hitting F12 in any browser and getting the built in DevTools. Those are very handy. But then you can also start thinking about DevTools that you use.

with certain tools. So you might use Redux and Redux comes with DevTools or you might use TanStack Query and it comes with the TanStack Query DevTools. Then there are other interesting DevTools like Axe, which is a DevTool specific for people that are concerned about accessibility. So there's all sorts of extensions that you can put into your browser.

That give you extra developer tools. And those are great. They work really well. ~Um, ~you could also even say things like ESLint is a dev tool that helps you find certain errors and can run [00:09:00] automatically. Now, the thing that's missing though, is every one of us is building an application that's weird, unique, different, or at least it should be.

If it's not, then we should just stop coding and go use the thing that already exists, but. In these situations, everybody's app tends to benefit from a set of dev tools that are unique to your problem. So the example that I give is,~ um,~ easy to understand. I talk about a to do app, and a to do app is going to have a situation where I can check a box next to a to do, I can add new to dos, I can edit them, I can delete them.

Basic CRUD app. Now in that situation, It is helpful for me to mock my endpoints so that I can make that to do app reliable, because again, if you and I are hitting a shared database and I write automated tests, if I test a delete, and you are running the test at the same time, and I deleted the very record that you were expecting, Now we have flaky tests.

Now, one way that you'll see teams get around that sort of issue is you and I could have our own database instance ~that ~that's a nice way to go, but there are other downsides to that because,~ well,~ [00:10:00] now we obviously each have the overhead of setting up that database instance. We have to have a static data set.

And I do think these things are useful, but the other downside is. It is always going to be slower if I'm making calls to a database than if I'm hitting mocks. ~Um, it, it,~ Sort of the difference between,~ uh, ~making a call here across the United States versus going all the way to the moon. I mean, it's a big difference ~in, ~in network calls, especially if you're in a development environment where ~that, uh, ~That database might be slower for any number of reasons.

Often we've got worse hardware in development, see these sorts of things. So in those situations, mocks are really useful and having a custom dev tool that lets me. Change mock responses via a UI is super useful. ~So, uh, ~in the talk, what I do is I demo a custom dev tool that lets me say, when somebody adds a to do, I want it to take two seconds for just that one call, because we've got a business rule that says if the call takes two seconds, we're going to time it out because we're very confident that no call should take over two seconds.

And then there's other [00:11:00] things like a product owner might say, If you go to add it to do and it fails, we want to show an error message on the screen that says, sorry, adding your to do failed. Please try again. How would you write an automated test for that? ~Well, ~the problem is what I used to do is I would go, okay, now I've got to go break the backend temporarily, and I've got to force backend to return this error, even though it's not broken right now.

~Well, ~what if instead you mock out The backend and you can do that. Yes, you can use,~ uh,~ tools like mock service worker and those support that sort of thing. And in fact, the custom dev tools that I tend to use often use mock service worker behind the scenes. It's a wonderful tool for those that aren't familiar.

What it does is it captures HTTP requests. They never leave your browser and then you get to decide. What your browser sees and said, so I can say, if you make a slash post to slash to do, I'm going to capture that request and instead use this hard coded Jason. ~Uh, ~to simulate this. So when you're in that situation, it's also nice to have a user interface for that so that you [00:12:00] can change those settings, you can see them.

And also so that your automated tests can leverage these tools as well. So that's the secret sauce here is I want to use these custom dev tools, not just to accelerate my development, but also. To operate my automated tests. So~ So my automated tests can load up the application and say, I want this request to be slow, or I want this request to return a 500, whatever may be.~

~Oh, I shouldn't have gestured because it breaks my cam. I'm going to have to turn off my webcam and turn it back on. This is the joy of Mac today. Actually, I think it may have completely frozen my browser. I~

Paige: ~I can still hear you,~

Cory: ~You can hear me, but you, but~

Paige: ~but if you need to leave and come back,~

Cory: ~Okay. Uh, so is it okay for me to close my tab and come back or what should I do here?~

~What do you recommend?~

Paige: ~yes, I think you can just. Um, I don't quite remember where~

Cory: ~ I'm trying to remember too. Let, let me, let me pause for a second. And, uh, this is clearly an edit point. So what I was talking about at the last moment was about, um, the nature of dev tools, making things faster, having,~

Paige: ~Having mocks instead of actually trying to hit databases locally or in the cloud, um, intercepting all the calls and being able to then just change whatever happens for the to do app or whoever is, is hitting it.~

Cory: ~yes. Okay. So let me just pick up from there for a second. ~So the important thing about having the dev tools configurable is that now I have power both within my automated tests and also

Paige: ~hmm.~

Cory: I would emphasize is some teams will end up using built in mocking tooling that comes with their test tool.

So Cypress will intercept calls. Playwright will do the same.

Paige: ~hmm.~

Cory: You can do similar things in Jest or Vite test. I generally prefer to have one mocking solution, which is mock service worker. And the reason I like to do that is now I only have one API that I need to understand and maintain and I can. ~sort of ~learn it once and use it all over the place.

And sometimes I can even reuse those mock configurations between those different tools. So that tends to be [00:13:00] quite useful. ~Uh, ~but when we talk about custom dev tools, I want to emphasize that it's not merely a conversation about mocking out endpoints. It's also anything that I might want to do. To speed up my development.

So you think about some other things that are useful. A lot of people, they open up their application and they manually log into that application and they have to think about, okay, am I going to log in as Corey or Emily, maybe we have different user roles and one of us is an admin and the other one isn't.

So now we have to keep track of those different passwords. And password keepers make this sort of thing easier. But what I like to do is just have a dropdown in my custom dev tools. It lets me pick between different people and even tells me, okay, Cory is an admin,~ uh,~ Emily's a super admin and so on. So I can really quickly see, all right, what type of user do I want to be right now to help me do development on this particular feature?

The other thing that I like to have in there are things like feature toggles. So lots of applications benefit from feature toggles, teams like them because we can integrate. Continuously. And we don't [00:14:00] have to necessarily wait for a feature to be done, but being able to toggle those features in the dev tools means that I can write a test that says when the flag is off, the application operates this way when the flag is on, it operates this other way.

And again, ~I just, ~my tests actually use the dev tools. to toggle these things.

Paige: ~Yeah. Okay.~

Cory: One other instance I'll give. A lot of applications have a situation where I might be looking at a record and you and I could conflict with one another. Perhaps you edited the very record that I'm looking at, or you deleted the record that I'm looking at.

How do we write an automated test that simulates that while I'm looking at a record, if somebody else deletes it, I should get a notification that says, the record you're viewing has been deleted, Click here to go back to the homepage or perhaps click here to recover the record. You can decide what user experience should be there, but you can have custom dev tools that will simulate.

Traffic and that traffic can be simulated using mocks. So you're effectively configuring a tool like mock service worker dynamically [00:15:00] using a user interface. So these are the sorts of ideas that I've just found really useful. And as you go down this road, what's fascinating is every team I've worked with on this topic ends up with a custom dev tool that looks.

Significantly different than everybody else's because they all have their own needs. Every application is unique, but these are some of the core ideas that I found as common threads across applications.

Paige: So you've talked a little bit about kind of things to consider when you're building your custom dev tool, ~you know, ~being able to manipulate HTTP routes, having feature toggles, things like that. ~What could, or ~what are some of the specific capabilities that you've built into your custom tools?

You've touched on a few of them, but I'd love to know,~ like,~ are there any really unique things that you've done that you think other people should really consider adding to their own?

Cory: ~Um, well, it's, ~it's hard because like I think about, I was working with an insurance application and we had a number of settings in there that were specific to insurance. The nature of insurance ~is it, it ~tends to lead to situations where you have complex multi step forms and those complex multi steps forms are going to.

[00:16:00] Pivot greatly based on the way that certain questions are answered as you move through them. ~Um, ~and then there also tends to be a lot of diversity in the users, as ~in some users have ~one user might have one insurance policy, another person might have many, and they might have different combinations. So just being able to toggle between.

~Uh, ~many permutations of users and even being able to turn on and off certain attributes for those users within the dev tools was useful because those users could be granted a set of rights. And if you're in a situation where you've got users and those users might have 20 or 30 different things that they can do, you could create.

Every possible permutation of different users or what you could do is just have your custom dev tools allow you to quickly toggle these things on and off. So I find that can be really useful if you have complexity in your authorization story. So ~I mean, ~to answer that, it really comes down to what are the parts of your application that are remarkably complex and that tend to.

Benefit [00:17:00] from potentially having a wide variety of data, but recognize you don't necessarily need to have every permutation of data if you can easily change that data using dev tools. Cause this relates to another point that I like to make is I find most teams can benefit greatly from having a static data set.

And I tend to, my ideal is to create that static data set early so that we have it to work with and so that it grows organically. So we're in a situation where. Early on, we say, okay,~ we,~ we just need one test user, but then later we find, all right, this one test user isn't sufficient because there's a lot of permutations.

So then we go down the road of maybe creating a few more or enhancing the dev tools to allow me to toggle all ~the, ~the interesting attributes of that user. So two different ways to do it, but the bottom line being, I, what I like to avoid is, Oh, let's just take the production database, pull it down and use it in development because it tends to be, ~you know, ~There's a couple of things.

For one thing, it becomes so big that it is, it tends to be slow and [00:18:00] needlessly slow, just joining all this data. If you get complex queries can make our automated testing stories slow. ~Um, ~and the other thing is if we go ground up, if we start from the beginning, we can be strategic about the data that we put into the database and people can understand then.

If I've got a bug and it can't be reproduced with our current dataset, we add one more record, or perhaps we change an existing record, but we try to keep it in the realm of dozens or hundreds of records instead of thousands or millions where performance becomes such an issue. ~Okay.~

Paige: ~how, ~

Cory: Okay.

Paige: custom dev tools how, how you make it work with everything, whether it's automated tests or just you doing local development?

Cory: So the nature of mock service worker is you declare a URL and you say, I want to [00:19:00] capture Uh, put a post delete at a given URL and that URL can have placeholders wildcards. So for instance, I can say, if somebody does a get to slash user, I want to capture that request, and then I get to, since it's declared in JavaScript, the sky's the limit on what I might put inside of there.

I could say, okay, if you go to slash user slash one, then I'm going to return this mock record. If you go to slash user slash two, I'll return this other, and you're going to have placeholders within these URLs. So that tends to be helpful. Okay. So at its core, that's the way it works. But one of the cool things you can do with mock service worker is actually configure it using a URL.

~Um, ~and by that, I mean, imagine that you have search params in the URL. So I could, for instance, put in a question mark, throw error equals 400. ~And,~ and I could say even more specifically, ~um,~

Paige: ~Okay. Okay.~

Cory: Throw error on get to dues. Like I can be very specific. I can decide what the URL should say, but in the end, once we start reading configuration from the URL, now our [00:20:00] mocks are configurable by the URL.

And to be clear, what I'm talking about here is just built into mock service worker. Now, what I tend to do is ~like ~to add user interface on top of that again, so that everybody now has clarity about the API. ~Um, ~you could sort of think about the URL like. Working on the terminal. Some developers like using the terminal, but you know, the downside of the terminal is discovery.

You end up often having to go read docs and figure out how to structure your requests and you might make typos along the way. So I tend to want to sort of have my take and eat it too. So let me explain what that looks like. I want to be able to configure my mocks and more broadly, all my dev tools using the URL.

But I also want to have the option of using a user interface. So what I do is. The initial values for my custom dev tools come from that URL. So that sets my defaults and loads it up. The reason this is important is imagine that I want to show you a bug and I want to say, you've got to be logged in as [00:21:00] Corey, and then you have to have your network slowed down to two seconds on this particular request.

And you'll see that the request times out and the application fails. And what we should instead do is maybe wait a little bit longer or retry the request.

Paige: Right.

Cory: I would like to be able to send you a URL that configures my dev tools to act that way so that you're immediately logged in as that person so that the request is slowed down by that amount.

I could force an error, whatever it may be. And that's where the URL is really useful. Now, the other thing is though,~ uh,~ that URL is also useful for tests because that means that now I could write an automated test that initializes my application with all these settings. And now my automated test merely just says, load this URL.

And I know that the application is going to be in a really specific config. That's powerful. And I really enjoy that. ~So that, that, um, combination is, is ~Unfortunately, rather tricky to get coded up, right? So I created a, an open source project called react slingshot for my own purposes. And effectively what I did was I open sourced the core [00:22:00] patterns that I use to create custom dev tools.

So you could think of it as a starting point for anybody to create their own custom dev tools. You get ~Um, ~an optional user interface, but I've also just got custom hooks that contain the core logic here for reading settings from the URL, persisting them to local storage, being able to copy those settings into a URL after you've changed things in your dev tools.

And those are the core ideas. So once you have those sort of primitives together, the sky's the limit. You can add all your own settings in, but you at least have this opinionated structure that helps you build your own.

Paige: So at the end of the talk, you debuted react switchboard for people to start using and trying out on their own. So have you gotten feedback yet? Or have you heard of people who've used it and said it's really, ~you know, ~made their local development much better than it was previously?

Cory: So I've gotten some feedback just from ~issues, a few ~issues that I've fixed in there, but I haven't gotten to see anybody sharing their particular work yet. And that's what I'm really excited about. And given this has only [00:23:00] a couple of weeks. ~Um, and, ~and frankly, I still have no sense of how broadly this may or may not be picked up because I recognize that ~this, ~this stands upon a number of other prerequisites.

You need to have a team that cares about automated testing. You need to have a team that cares enough about. They're dev tooling to want to put in the time to actually build these custom tools. And then I also need them to close the loop and come back to me and show me what they've done. And that last piece may or may not happen.

~It's got a, uh, I I've gotten, ~I've been so happy with the traction at least from GitHub, from what I can see as far as stars and,~ um, ~people interacting on Twitter, but what I'm hoping ~my future. Hope ~is that I can share pictures of what different people have done as an inspiration, because I think that's one thing that's missing right now.

And Kathy Sierra did a wonderful talk years ago at an O'Reilly conference where she emphasized this idea of. Sharing a rich list of examples in documentation because humans learn so well from examples and often that's what's missing is you'll have docs that say, here's how you do these things, but, and they might have one example, [00:24:00] but often two or three or four or five, as you get more and more, you start going, every example I look at gives me a little more confidence that I fully understand how far I can go with this thing and all the different angles that I could take on it.

So that's my vision. I actually wish in the past I had kept more screenshots of previous clients. ~Um, ~but that's,~ um,~ that's a hope for the future. ~Um,~

Paige: Yeah, ~I mean, ~I personally would love to see, ~you know, ~how other teams have taken it and ~kind of ~made it work for them, whether it's adding feature toggles or setting up specific routes and how they do error handling and stuff like that. ~But kind of, You're, ~you're absolutely right. Seeing how other people have uniquely tailored it to their situation helps me think of more ways that I could make it work for my particular app that I'm trying ~to, ~to work on.

So will look forward to when you do start to get more feedback. All right. So you've ~kind of ~put this out there. You want people to take it, make it their own, make it work for them. How do you see this concept evolving or where do you see it going next in the [00:25:00] future?

Cory: ~Well, ~I thought about the idea of a Sort of plugin architecture extensions, people sharing other sorts of things that they've found useful. Like you could think for example, how lots of people use feature flags and they might use a feature flagging tool such as split. io or launch darkly. Now those tools have,~ um, ~APIs and ~you could also visual, ~you could also imagine how you could have a user interface for those sorts of things.

~So. ~I could see how it might be nice to have just a plugin where I go, okay, if I pull in this hook, I've easily got a way to go ahead and read these settings. I could also have a default user interface that just, I pass it an array of feature flags and it displays a bunch of radios that I can toggle on and off with all these.

So I don't have to build these things. And that's just one example ~of, ~of, as we see more of how people want to use the tool, I'll have a better sense of how to make it extensible. Cause right now the tool really has. Two core ideas built in one is just general settings. And so switchboard has settings for where you [00:26:00] display the dev tools.

For,~ uh, ~whether they are open by default, whether you can open and close them via the keyboard, just basic sorts of things that you don't want to have to build yourself. Just, it'd be nice if it were there. Now, again, that user interface is totally optional because there is for every user interface that I provide, which is just a react component.

I provide a custom hook that contains all the logic so that you can use that logic to build your own user interface for it. If you don't like my opinions, I was deliberately. Quite plain about my styling and implementation here. ~And, ~and frankly, I expect most people will probably be fine with using the user interface I provide because it's not public facing you just as a dev tool, all you need is something you can read.

It doesn't need to be pretty or styled. It doesn't need to match your applications design, but I wanted to give people. Options there.~ Um, ~I think otherwise what I'm interested in seeing is the sorts of domain specific ideas that people might share where you think about, all right, I'm working in dentistry or construction, [00:27:00] whatever may be, and in that particular area, there's a set of interesting settings that will help us move faster.

And as I see more of those, I think that'll help me. genericize those ideas ~and, ~and basically encourage others to think about their application dev tools in a new way. ~Uh, ~cause ~I'm, ~I'm still finding these things too. ~I, ~I, again, this is a fairly young idea. The first time that I'd heard it even mentioned was only probably three years ago.

And I'm only aware of a handful of teams. That are doing this. Although I suspect that there are many that are, that may not use the same terminology. It's hard because the very nature of this idea is when you talk about it's something custom that your team does.~ Well, ~it doesn't have a public manifestation.

So unless you go to a new company and even if you go join a new team, you're going to have to deal with exactly what we're dealing with here, which is how do I explain this idea that I can't show you? I can't demo it because it was at my old job, but trust me, I found it useful and here's what it looked like.

But [00:28:00] also this thing that we did isn't going to look quite like what we should do on this application. So I can only talk in generalities here. So there's a lot of reasons that this idea is ~sort of ~hard ~to. ~To spread, but that's also why I'm like, I'm excited to be on here talking about it because I really do think it's something that a lot of people would enjoy.

Paige: ~Yeah. Well, and~ along those lines, ~are, ~is there anything about custom dev tools that we 

haven't talked about yet that you want to make sure people know or are aware of? Okay. 

Okay.

Cory: that this conversation would involve creating a Chrome extension.

And that would be logical. You can get a lot done with a Chrome extension, but I have found that there is benefit in building your dev tools literally into your application. Now in react land, the [00:29:00] way that I get that done is I lazy load my dev tools and I do that using an environment variable. So that's the right way that react switchboard.

~Uh, ~encourages you to configure it. It doesn't force you to, but the docs tell you lazy load react switchboard and then render it if your environment variable says that you should. So now it's in a separate bundle in production. Nobody's going to get any overhead here. Guarantees. It won't be there, but once you do that, the nice thing is you hold all the cards because now switchboard actually it's API encourages you to render the application via switchboard when you're in development.

And this means that your application could completely crash. It could air, you could be looking at a red air page or whatever, but switchboard will continue to render. You can still see your dev tools. Cause I found that really useful. It's frustrating. ~If, ~if I want to force an error, I want to make sure that I could go change the settings after that error occurs and try other permutations of things.

So that's just a little pattern that I found useful. The other thing is keep in mind that some people might [00:30:00] say, why do I need to control? Say slowness of APIs. Cause can't I go into the Chrome dev tools and turn on network delay and simulate slow three G you can. The problem is ~that ~that's not granular.

That's going to slow down every single request. And if I have an automated test that needs to just make sure that one request operates a certain way, when it's slow, I want to make sure that all the other ones run fast because. I don't want everything to run slow because then it's just slowing down my test needlessly.

I only need that one. And same story. If I want one to fail, I don't want to completely turn off the network, which yes, you can simulate being off network with the Chrome dev tools. I want to simulate just one request failing with a ~particular HTTP request, ~Particular HTTP response code, like a 500. And I can do using dev tools that are built into my application that have full control over my mocking tooling.

So ~that's, ~that's why I really encourage people to think in terms of build your dev tools inside your code base. Render them as part of your [00:31:00] application. And now it's full fledged, really the sky's the limit. You can do anything. You can even access your application state. Like you could choose to take the state and dev tools and push that down into your app and overwrite things as well.

~So, um, ~you could read from context, any global data stores. ~It's a. Man, ~it's fun. Cause it feels like you're playing with Legos, which,~ uh,~ I've always felt that way about development. And this is one of those cases that it particularly rings true.

Paige: It sure does. So if people want to try out Switchboard or they want to get in touch with you to learn more about it or any of the other courses and talks you've done, where are the best places to find you online?

Cory: ~Uh, ~so you can find me on Twitter at house core. ~Um, ~you can find the talk,~ uh,~ the conference talk where I introduce it at react rally by going out to YouTube, just looking for react rally. That's their 2024,~ uh, ~video there. ~Um, ~and then you can find it on GitHub, just search for react as switchboard and you'll find the NPM package.

~Um, ~Listed there, setting it up only takes a moment. I've got a running demo where you can tinker with this too. Really demos are the way to go. And in a couple of minutes, you'll get [00:32:00] the big idea and,~ uh,~ hopefully it'll get you excited enough to go farther.

Paige: Fantastic. ~Well, ~Corey, thank you so much for joining us today. It's been a pleasure having you on the show.

Cory: Thank you for having me.

Paige: All right, we will see you on the next episode of PodRocket.