Michael Chan Encapsulates State

Kent C. Dodds:
Hey friends, this is your friend, Kent C. Dodds, and I'm joined by my dear friend, Michael Chan. Say hi, Michael.

Michael Chan:
Hey, how's it going?

Kent C. Dodds:
So good. So happy to have you here again. For those of you who listened to Michael's other episode already, then this will be a review, because Michael's already a good friend of yours. But for those of you who haven't, so I just barely, actually minutes ago recorded an episode with Michael, and we just had so much to talk about. I wanted to talk about some more stuff with him. So, we're doing the second episode. But yeah, so definitely go listen to that other one, especially if you want to get into Michael and my shared love of show choirs.

Michael Chan:
Do you have pictures? I have pictures.

Kent C. Dodds:
Oh yeah, I've got ... I'm looking around my room. I don't have them hanging up, but I used to have a picture on my wall. So, Michael, why don't you just give us a quick intro to yourself, and then we can jump into our subject for this episode.

Michael Chan:
Yeah, so I'm Michael Chan. I go by Chantastic, almost everywhere. Host the React podcast at reactpodcast.com. I guess for context of this episode, I got into React super early. I think I wrote my first component in November or Christmas break of 2013.

Kent C. Dodds:
Wow, that is super early.

Michael Chan:
And immediately, one of the first things that I did, was to put my CSS in the style attribute of my component. So me and CSS and React components have a long, long history. Anyway, I thought I'd get that out of the way in the intro.

Kent C. Dodds:
Yeah, I love that. Yeah, I think that's great. And 2013, even at the tail end, that's like very, very early days React. That's impressive. I didn't really start getting serious about it until 2015, so you're a bit older than I am in React years.

Michael Chan:
In both years, probably.

Kent C. Dodds:
Yeah. So Michael, actually one of the first things that I remember watching of your educational content was, you had this website, it was something React beginner something, where you showed making a component that encapsulates its styles. Do you know what I'm talking about?

Michael Chan:
Oh, yeah, yeah. It was probably at learnreact.com which I have not updated in a really a long time. But yeah, it talked about style encapsulation and components.

Kent C. Dodds:
Yeah, yeah. I'm pretty sure that's where that was and it resonated a lot with me because one of the things that I love about React is the black box nature of it.

Michael Chan:
Yeah.

Kent C. Dodds:
When we're talking about components, even with AngularJS where I was working before, before I got into React, I treated my directives as components. And this was before Angular dot component came around. And so I just made these things, and I wanted to encapsulate everything into this black box. And just by the nature of the design of the framework, it was kind of difficult to make a black box that didn't leak a lot.

Michael Chan:
Sure, yeah.

Kent C. Dodds:
So, that was tricky, and you had to be really intentional about doing that. And one of the things I love about React is that it's a lot easier to make a black box of abstraction with React components that don't leak, that are iron-clad. And that's the pit of success, and of course, you can do the wrong things that are not idiomatic but with that, talking about using encapsulating styles into these components comes with so many benefits.

Kent C. Dodds:
Do you want to talk about... Why do you think CSS and JS has just exploded in popularity in the React ecosystem?

Michael Chan:
Well, yeah. I think what you said is totally right on. There's something about the encapsulation model of React components that is just brilliant, and it works in a way that we haven't really seen in other places. I think one of my favorite examples, I have this tiny, tiny, tiny component. It's called React SVG spinner, or something like that. And the thing that I love about it is not that it's particularly well-designed, or has a good API, or any of that kind of stuff, but it's a React component that renders out an SVG element that it fully draws inside of the component, and then some CSS just inside of the component, like a local style tag, that it uses to style and animate the SVG.

Michael Chan:
I just remember thinking it was magical that I could make this one NPM install that did all of those kinds of things, instead of having to be like, "Hey, add this style sheet, and import this SVG from this other thing." It's just like, if you're running React, you have this one thing, and it just puts up a spinner, and does all of the things that you need to do, baked into it.

Kent C. Dodds:
It's brilliant. Yes. It's so awesome. Anybody who's new to this, it's just like, Yeah, that's life, right? But before, you're like, "Okay, now you have to add this Babel loader, or this Webpack loader, or you have to add this script tag," or all of this nonsense that was like, "Well, I can't really do that, because my built system is such and such." There's so many hoops you have to jump through. But being able to put it all into just, you can copy paste this file, and now you don't even have to take the whole file. Just like take the code. It is a totally different paradigm that was, yeah, fantastic. Absolutely.

Michael Chan:
Yeah. And I know for me, coming from Rails, so much of this stuff was really irritating, because maybe you had all of those things, but you had to package it up into a gem, which was totally aware of the Rails system, and how things were bundled. And then you had to have three different parts where you imported the JavaScript into one JavaScript manifest, and the CSS into a CSS manifest. And now you have this gem sitting around. It has nothing to do with Rails. It's just like a bunch of CSS and JavaScript. And it's like, yeah, I love where we're at, in terms of encapsulation right now because it's just what, I think we wanted for a really long time.

Kent C. Dodds:
Absolutely. And I think that React just got the ball rolling, when it was like, "Hey, listen. This whole separation of concerns thing is pretty cool and all, but you're separating the wrong things and you defined concerns wrong and as it happens, a button..." Like let's take a toggle button for example. A toggle button isn't a toggle button without the Markup, the behavior and the styling. You can't have it without all of those things. So let's just put them all together, and it will start with JSX, and then CSS and JS comes around, and we just marry it all. And when we do that, we just acknowledge the reality, and then we can have some really powerful things with that reality, right?

Michael Chan:
Yeah.

Kent C. Dodds:
So, with that in mind, we are going to talk a little bit, or we want to get into a little bit, why you might want to not get a divorce in that sort of marriage, but why you might want to be a little more intentional about how you create this design system in a way that is leveraging the modern platforms that we're building on.

Michael Chan:
Yeah. So, a lot of the work that I do is in frontend architecture, and then design systems. And most of what I do is helping designers and developers communicate. I'd say if I had one job over the last 10 years, it has very little to do with code or design or anything. It's just like trying to figure out the areas that we can agree and move forward on. So, I'm really bullish on communication across the wall.

Michael Chan:
And I think that something that concerns me deeply about any technology, is when we put too much inside of it. And I think that we saw this early. To draw a corollary, inside the React universe, I think we saw this pretty early on in React, where everyone was taking their state, all manner of state, and putting it into Redux, or some flux implementation. I don't want to single out Redux. Putting everything inside of some global state management. And I say that because I think that we have, over the last three years, been crawling out of that in our applications. Would you agree with that?

Kent C. Dodds:
Oh, my goodness, yeah. I agree so much, so much, yeah.

Michael Chan:
Because I know that this is something that you have to talk about a lot. Now that everything can be in a component. We've got this really nice encapsulation model that allows us to do this thing for the first time. You have to be very strict about what you let in there. And this can be really hard, because it's extremely nuanced, and I think for a lot of people, like they want the rule, they want the ESLint rule that says, do this, don't do the other thing. And that's just not how this works. Sometimes it takes a huge amount of experience and having gone through transitions from one platform to another platform. To have an intuition I guess, about what is too much. And yeah, it's tricky because you see the component and you see all these capabilities that we baked into it.

Michael Chan:
And I feel like we've largely solved the performance issue in CSS and JS now. And it's really good now and it's hard not to just throw everything.

Kent C. Dodds:
It's true.

Michael Chan:
What would you say, the biggest takeaway from... Because I know that you've taught and guided a lot of people in this transition of thinking away from just putting everything inside of a global store, like from that as an example. What are some of those nuances or what are some of the areas that have been hard to communicate to people in dividing that line between what should be local state, what should be global state, et cetera.

Kent C. Dodds:
Yeah, I think that in general, I try to develop a principle for these nuanced things that we're teaching people and these principles typically can't be encoded in an ESLint rule, which I know lots of people have a lot of trouble with. But the principle is co-location and this applies to global state, it applies to where your files are laid out in the file system, where you put your tests, all of this stuff. If you think about the principle of co-location and the fact that the closer you put related things together, the easier it will be to maintain on the longterm. And in some cases the more performance it will be as well. Then global state actually does fit into that because I have this state and the closest it could possibly be to where it's related is actually at the top because literally everything needs it, right?

Kent C. Dodds:
So, that's still co-location and so yeah, that's kind of where the real struggle that I've had though is people do want to have an ESLint rule that just says, okay, do this, don't do that. And when we're talking about something like co-location, the only thing that will always "work" is putting everything global. And so you make ESLint rule against React state and that's how we got here. And so yeah, taking a more nuanced approach, more principles based approach. I think we're really good at lifting state, less good at going the opposite direction and co-locating state. And bringing it back around to CSS, I think we've just really fallen in love with this ability to encapsulate our styles because we really don't like having global styles, but for some reason we're okay having global state.

Kent C. Dodds:
I'm not exactly sure I understand that. We're like these two things are passing on the highway. It's like, wait a second, where are you going?

Michael Chan:
So I bring up the Redux thing because I think that it's such a good example of putting too much inside, redirecting too much into the wrong place. And I think one thing that I've always been on about with components is that the encapsulation model is only as good as you are at encapsulating a single piece of information. Right? I think Hooks are really good at this because they make it difficult to encapsulate more than one concept. They're kind of like biased against that a little bit. But let's say like every design system on the planet has a button. Right?

Michael Chan:
And I think this goes back to maybe that first lesson that you had seen of mine, but I do all of my componentry a little bit differently in that when I create a button component, I don't want it to think about size. I don't want to think to about color or anything. All it thinks about is just how to display the minimum viable button. And then if I want a button that is a certain size or a certain color, I make another button that composes that button. Right? And kind of works together. This is composition versus everything that we've seen, like every design system that's kind of post bootstrap, where it's like a single component has all of these ideas of size and all that kind of stuff baked into it.

Kent C. Dodds:
Like 13 props.

Michael Chan:
Right? Exactly. I feel like as React developers who kind of latched on to the notion of design systems and largely co-opted it from the field of design, I feel like we've done it wrong. And when I say the industry, I don't mean we, because I feel like I'm still doing it right by just having the one components that compose each other but it's something that I'm deeply concerned with. Because I feel like we put more and more into these components.

Michael Chan:
So many systems, React based design systems have a box now, which is basically every single component in those systems inherits from box. And we're in this position again with design systems where we have kind of taken the easiest route and pushed everything into one place like global state. And it's concerning to me as someone who is actively migrating systems from one place to another, from Rails to React. To think like in 10 years we're going to have all this legacy React code that was super hot in 2020 that is immobile, like cannot be moved to the next thing. And we're in a position where we have to like rewrite everything, which sucks.

Kent C. Dodds:
Yeah, definitely. Definitely not fun. So, what is your... I'm not going to say perfect, nothing's perfect, but what's your ideal design system like then? I imagine lots of people listening to this are like, yeah, my whole design system is styled components and it's amazing. And they've got the theme stuff and they got media queries all magically working together in something that they feel is working super well for them. And so here we are talking about how maybe there's potentially a better way, a more portable way. So, what is that way? How would you recommend people go about creating design systems that are framework free?

Michael Chan:
Yeah, that's a good question. I like framework free. It's like free range design systems. So, first of all, both of us love CSS and JS for certain projects. I'm not going to beat around the bush. My first talk was at React Europe, encouraging people to start using CSS and JS. And as we focus more and more on accessbility in the React space. You realize how important these components are because CSS and JavaScript and Markup are entangled when it comes to styling things that are accessble. And so I don't want to discard all of that because I think that's super important. But you look at libraries like Reach UI and they're still exporting like a CSS thing, which is easy to override. And I feel like this is a good model because open source, like more than anything has to be, I guess, extensible.

Michael Chan:
And I feel like if we look at open source is kind of a model for how we should be designing our closed source. I feel like that is a really good model of like, Hey, we know that these things are intertwined. We're going to give you the minimum viable implementation to make it work, right? To make sure that these interactive elements show in the right place, et cetera-

Kent C. Dodds:
Right.

Michael Chan:
[crosstalk 00:17:44] you can easily override them. I think my feeling is that design systems as well as open source that's going to transcend React really has to be thinking about the browser as a target and not React as a target. And kind of relooking at what's capable in the browser now. I think predominantly the killer features are going to be CSS custom properties/variables and CSS grid and kind of determine a strategy for their apps or their open source on how they want to leverage those things and how they're going to maybe support legacy applications if they want to at all. In kind of betting on standards in the future. Because I think that at some point Internet Explorer is going to be end of life. Right?

Kent C. Dodds:
It has to be, please tell me that it will be, even if it won't, I just need to hear those words.

Michael Chan:
It will, it will. And CSS custom properties and CSS grid have such... I think we've gotten so obsessed with React. We've missed all of the innovation that's happened there and browser support for grid and CSS custom properties is almost as good as Flexbox, if maybe not better in some cases. And so, if you're already using Flexbox for stuff and all of these things are really good at overriding the properties that you would have used for a legacy systems anyways, like floats and all that kind of stuff.

Michael Chan:
So, I don't know, I'm super bullish on standards pretty much always.

Kent C. Dodds:
Yeah.

Michael Chan:
Yeah.

Kent C. Dodds:
So, in your mind, the ideal design system today would be one where it's leveraging mostly pretty much all CSS, like regular style sheets that people would then import the style sheet for the styles, but then there would be an accompanying React component that has props and stuff that people can use, so that they say, okay, just include this style sheet, include this button component and use that button component. You don't have to worry about class names, you just, I need to have that style sheet on the page. Is that what you're [crosstalk 00:20:10]?

Michael Chan:
Yeah. Yeah. And I think that the boundaries are going to be different for every person. And this was my feeling in terms of transitioning to CSS and JS is that there's no way to make a clear boundary about this. Like we were talking about with ESLint rules and whatnot. If you want to make one decision, you going to be stuck on one side or the other. But if you're willing to bridge the gap, I think there's so much cool stuff that you can do in maybe not even using class names, right? Like just defining a bunch of like custom properties that are used with values and then having components consume those. Right? One of the things that everybody hates about CSS is the fact that you have to give something a name first and that's one of the two hardest problems in computer science. Right?

Michael Chan:
And I think that with this you can just define a specification for an avatar or whatever. And now if you want to do everything in React, you just have a React component that consumes those custom properties.You have another React component that modifies those custom properties to put a ring around the avatar or a border or make it so it can overlap other avatars in a group and so you can still leverage the component model while also taking advantage of the latest features in CSS. Which makes these things very customizable, very easily overrided, overwritten?

Kent C. Dodds:
Either way, I think we all understand.

Michael Chan:
And then yeah, CSS grid, there's so many bespoke grid systems out there and that's just built into the browser now. It's like just learn that, it's so much more powerful than every other grid system I've ever seen before, yeah.

Kent C. Dodds:
Mm-hmm (affirmative). Absolutely. So, actually on that one, would you suggest that application or people who build design systems just to expose class names that use those things and then application developers would use those class names? Or would you also expose grid components that are built on top of regular CSS grid? Because there's a lot of value in scoping down the amount of things that you can do, right?

Michael Chan:
Yeah.

Kent C. Dodds:
When it comes to a design system.

Michael Chan:
Yeah. It's tricky say for any given team. I hope that people just explore it and find out what the boundaries are for them. I still expose classes because my work happens largely between Rails and React and there isn't... I have to have some type of handle for the Rails code to target. Right?

Kent C. Dodds:
Right.

Michael Chan:
And so we use classes for that. If you were strictly in React, you could still set up all these custom properties and then just consume them in React. But grids are rad. They're so ridiculously powerful and I think we've been conditioned to want to build the generic grid system for our applications instead of saying, I need a grid for this particular layout or I need a grid for even one small form setup, right? Make a thousand grids and use those instead of having a generic thing that has 50,000 props on it and allows you to do stuff in a bespoke way of your application that isn't leveraging the browser technology.

Kent C. Dodds:
Yeah. Yeah. So, related to this, when I was at PayPal, the very last thing that... Big effort that I was working on before I left was what was called PP React, which PayPal PP, it's unfortunate. I didn't want to do PayPal React. That's too long of a module name, but I was working really close... It was a component library for all of PayPal. Everybody who was using React, which is pretty much everybody was either on React or moving to React. But I was working really closely with its design system team and they really wanted me to work on something that would work regardless of the framework. And I pushed back so hard. I was like, literally everybody here at the company is either using or moving to React. So, we could build... Web Components came up and I would love to hear your thoughts on Web Components in relation to all of this but I shot that down very fast.

Kent C. Dodds:
And yeah, so I just really was pushing like, "Let's just do CSS and JS. You can give me your tokens, whatever as a packet, I'll import that as JSON and grab all the values I want." But they were like, "We still have lots of people who are on old stuff and we want to make this work for the future." And so, eventually I was finally convinced and just started making... One of my big problems and the reason that I decided to work on this, was because I would look at PayPal and applications and almost every single one of them, you'd pull up their coverage numbers that Google Chrome dev tools would show you. And I'd click around and open modals and everything and I could never get our CSS coverage down below 90% unused CSS.

Michael Chan:
Yeah. Yeah.

Kent C. Dodds:
This is not a small amount of CSS. And so I was like, we've got to have something that's code splittable. We've got to have something that once you remove that component, the CSS is also gone. That was such a huge an important thing to me. And so, what we developed was, they created regular CSS classes and in my package, up on our internal NPM thing in the built version, it would have import statements for CSS. And so then, you you want to bring in the button component? Well, sure that'll bring its CSS along with it. If you want the modal but that's code split, that'll come later and the CSS is all just magically code split along with that.

Kent C. Dodds:
And so, I felt that struck a really great balance of the ability for us to get scoped down CSS for components, componentized CSS. We get all the benefits of components and code splitability and everything, but also being able to deliver that same CSS for non React applications. And I left the company before it really got a lot of adoption. But I've heard since that it has gotten a lot of adoption, which is validating. But what do you think about that approach? Is there anything that you can tell our listeners that like, Oh, maybe consider this before doing something like that?

Michael Chan:
Yeah, I think that's a really great approach and that's the approach that libraries like Reach UI are taking where they have kind of this CSS. And it's cool because you can handle all of that as part of the build. So, you're doing that as part of the build, you're kind of encapsulating all of that. I think one nice thing about CSS custom properties is that they don't necessarily have to be exposed as a class name. Right? And so, if you really do have a... If your task is to make a global design system, having these CSS custom properties, those are your tokens, right? And if you can just rely on those as the undercurrent of you your design system, then you can consume them however you want in your componentry or your CSS classes or whatever you want to do.

Kent C. Dodds:
That's fascinating. A big takeaway for me is go learn about CSS custom properties because I know nothing about this stuff.

Michael Chan:
Yeah, they're really nifty. I'm actually doing a... What is it? We talked about egg head earlier, but I have an egg head collection that I'm working on that is going through some of the... I guess more like intricacies of custom properties and how they're useful. Because at first you're just like, Oh, they're CSS variables and yeah, but there are so many cool things you can do and there are so many ways that you can compose them and take them as a variable and extract other values from them. And it's just really neat.

Kent C. Dodds:
That's fascinating. Well, one of the thing that I wanted to make sure that is clear and maybe we'll disagree on this, I'm not sure. But when I was building that component library and design system, I was also working on PayPal scripts. That one, I didn't use PP, I guess didn't come up with that later, but PayPal scripts, basically like React scripts, a whole build tool chain, all in just one tool. You update that dependency and all of a sudden your build is faster.

Kent C. Dodds:
It was awesome and that also had a lot of adoption, but in that tool I had built in support for emotion for CSS and JS and specifically the CSS prop and that's how I was telling everybody to style their applications. I would say use PP React for all of our built in design system components and then use the CSS prop for all your bespoke application specific stuff. What are your thoughts on that? Do you feel like it would be better to just go full hog on CSS and CSS custom properties for our applications as well? Or do you see any value in CSS and JS from an applications perspective?

Michael Chan:
Oh, I definitely see value in... Was it CSS and JS from an application perspective? I think from that first talk at React Europe, I presented the idea of CSS and JS as a continuum. And I think for me, it's so important to develop flexibility in your thinking. That allows you to focus on the exceptions and the nuance as a tension you just have to live in. Right? And I think I've been in a fortunate position where I have had to support simultaneously modern systems and legacy systems. And I think when you accept that is a constraint, like a persistent constraint, not just a temporal constraint where it's like once we get to the modern system, we're good for the rest of time. But the legacy system that you're migrating from, that was the modern system at one point.

Michael Chan:
And you're just building the next legacy system. If you can build something that transcends both of your existing systems, well, then you're in a much better spot to move easily to the next thing. And so, yeah, I couldn't say specifically what the best approach is for any given team, but I think, kind of a tangential theme in this conversation is, don't try to make a single rule that works everywhere. Try to live in that tension a little bit and ask yourself... Determine the nuance a little bit. I think state derived styles are so much better to write in a component that is already maintaining that state. But your design system on the other hand, maybe that should be in a technology that's standardized and can transcend whatever web technology you're using.

Kent C. Dodds:
Yeah, I think that's just fantastic advice and we're coming down to the end of our time, but I really am curious about your answer to this question about if we're leveraging the platform for our CSS, we're using CSS grid and CSS properties so that we don't have to do all of that in JavaScript for our design systems. At some point, some of those things need to be applied to HTML elements and you're going to be having components that render that with JSX. Is there value in the same vein of using something like Web Components, which technically is the standard for components on the web?

Michael Chan:
Man you got to hit me with that one right at the end. Fortunately we're basically out of time so... Man that's such a sticky thing. I know that at least it seems like Web Components as they've been specified or kind of in maintenance mode. That doesn't seem like there's a lot of future outlook on that. And Chrome and teams at Google have been investing a lot into Next and working with React and trying to figure out the values of the declarative component model and how we can integrate that kind of thinking into the browser. So, I don't know, it's really tricky. I feel like Web Components are kind of maybe a little bit stuck and this is just my feeling as an outsider. I have no privileged information about this.

Kent C. Dodds:
Nobody rage tweet at Chantastic for you.

Michael Chan:
And I wish that they weren't and I wish that React had better integration for them. Because I feel like that would be... If React and Web Components worked perfectly together and like you didn't have to work around the edge cases. That feels like the natural path forward, right? Of just do your design system and Web Components and then wrap them in whatever framework you want them to be in. But it feels like we're not there and it's a real big pain in the butt for people who attempt to do that.

Kent C. Dodds:
Yeah, absolutely. I think that the thing that I wanted to mention about this is that, just because something's a standard, doesn't necessarily mean it's the one that we want to use. Right? Before React came around, if the folks on the React team were like, "Well, here are the standards that we have. So we'll just use those things." Then React never would have come around. The same could be said of anything. And the fact that Web Components came after React, it doesn't necessarily mean that it is going to work for your use cases better. To be Frank, I'm not afraid to share my opinion on this is that Web Components was a bit of a failure in addressing the needs of modern web application development. Which is a real shame and I wish that's not the case.

Kent C. Dodds:
And maybe eventually we'll get something that is less of a failure in my mind. But yeah. One last thing that I wanted to mention as we're talking about let's make our code as framework free as possible. Because I do think there's a lot of value in that. I just don't think that we've been able to really accomplish that with our Markup yet. But Logic can absolutely be framework free as well. And since you've mentioned Reach UI, one thing that you'll find that's interesting in digging through Reach UI code is that actually a lot of the Logic lives in state machines. They don't use xstate or anything but they have their own kind of state machine little thing. And what's cool about that is Logic is actually often the hardest part of all of this. And so putting that into something that is framework free allows for them to say, Oh let's let's make a Vue Reach UI and let's make an Angular Reach UI.

Kent C. Dodds:
And because they've separated their CSS and their state or their Logic and their Markup, they can just find and replace or switch out the Markup for each one of these frameworks. And I think there's a lot of value in that. When we're talking about design systems, I don't think that this same thing applies with applications. Absolutely not. I don't think anybody should build an abstraction on top of their applications so they can swap out Markup frameworks but with a design system that seems to make a lot of sense to me.

Michael Chan:
Yeah I'm glad that you went there with Reach UI, because I just tell people like, Oh Reach UI is great on so many levels, just knowing that they're going to get the benefit of this like framework free implementation. And I totally agree with you, it's so hard to draw the lines. Sometimes on when you should use a standard, when you shouldn't, when you want to leverage the power of a framework and when you should back off the gas a little bit. But I do feel like you touched on at least some of the nuance there, which is like the more general something is, probably the more likely you want to reach for a standard. And then the more specific it is to your domain like yeah, leverage the kind of framework specific stuff that gives you that extra boost.

Kent C. Dodds:
Yeah. That's such an awesome takeaway. Thanks for bringing that out. Because I think that when you're making a trade off by using the platform often, and that trade off often comes in the form of your time and productivity. The frameworks bring you just so much speed of development. But when we're talking about something that is so far reaching as a design system, you're willing to put in the extra cost of your speed in exchange for having longevity of that code. Whereas an application, we don't even know if we're going to be in business tomorrow. So, let's just get this thing shipped.

Michael Chan:
Yeah. And so much of this does come down to business trajectory because if you're just like working week to week, do it as fast as you can and figure out the longevity [inaudible 00:37:40].

Kent C. Dodds:
Yeah, absolutely. Well, cool. Michael, it's been awesome chatting with you, eight minutes overtime. Awesome. So, let's wrap this up here. So, our homework for folks is, we want you to take one of your small CSS and JS components and if you have them, if you don't then that's awesome. Good for you. Maybe for you, try CSS and JS for your apps because there's some really awesome things that you can do with that. But for those of you who are using CSS and JS for your design system, we want you to try and switch it out for a regular CSS solution to back it up. And see if you can do that in a way that doesn't like change your API or anything. You should be able to accomplish that, I think. Maybe you require people to include a CSS file or you can figure out some way to make it so they don't have to do that. But in any case, just explore the existing standards, especially for CSS that we've got and for my own personal homework is to go figure out what the CSS custom properties things. This is good stuff.

Michael Chan:
You will like them. You will like them.

Kent C. Dodds:
Yeah. Very good. Awesome. Hey Michael, how can people reach you?

Michael Chan:
Oh yeah, I'm a Chantastic, most places on the internet and if you want to hear some podcastage with some really cool React people and kind of React tangential people, React podcast is the place to do it.

Kent C. Dodds:
All right. Maybe we need a framework free podcast. No, I'm just kidding. We love React podcast [crosstalk 00:39:11]. Really strongly recommend that podcast. I always look forward to those episodes. They move up in my queue if I've got other things ahead of it. So, thank you so much. It's been such a pleasure to chat with you, Michael, and I hope everybody has a wonderful, safe, healthy rest of their day or evening or morning or whatever time it is you listen to this and yeah, we'll catch you all next time. Thanks.

Michael Chan:
Thanks.