Panel Discussion: The Modern Way of Making Websites in React

Hey, how's it going? I am Alex, Alex Drost, a developer experience engineer at Prismic. And I have a phenomenal, phenomenal group of panelists here with me today. And the goal of this panel really is to discuss some of the important aspects for developing excellent React components, as well as the decision making that goes into that process.

Like I said, we have a wonderful panel of experts here. I'm going to quickly ask that they introduce themselves. I'm going to start at the top with Natter. Go ahead and just introduce yourself, name, where you work and what you do. Yeah, absolutely. Natter David, I'm a Senior Developer Advocate or actually, I guess now I'm Developer Relations. I was with AWS for a little over three years and now I'm at a company called Edge & Node and we're doing crypto stuff, we're doing DeFi stuff and decentralized finance and all kinds of cool stuff. Awesome. Thanks.

And Erin. Hello, I'm Erin Fox, I'm a software engineer at ConvertKit, primarily working on the Builder for emails, cats. So I just got a dog so I like animals, I guess, but I'm still a cat person. I won't tell the dog, it's between everyone here at the conference. It's fine. Next up is James. What's up everyone? I am James Kukwyk. And I've got a dog in the background. So Seve is joining me today. I'm a JavaScript developer, a speaker and a teacher and specifically a developer advocate at Auth0, where we focus on making it as easy as possible to add authentication to your applications as a developer. Awesome. Thanks, James. And last but certainly not least, Sadek.

Hey, my name is Sadek Droby. I'm in in some way or other, I found myself to be the CEO of Prismic. So I was a developer and I saw that CMS is always, they were not great for doing anything. And I thought, OK, can we make them good for developers? And I guess we succeeded some way or another to do that. And now I'm thinking like, OK, let's make CMS is good for components. So that's what I do. And you know, I'm still a developer and I trust that developers are good for the CEO. Let's see what happens in this panel. Awesome. Well, thank you to everyone for joining us. You signed off a thing, but I'm kicking it off with that. Thank you to everyone for being here. It's just a great group of people. So for today, I want to talk about building components and specifically kind of around the topics of design, reusability, dynamic, content, and logic, and then actually the maintenance of a component after you've created it. So to kind of start it off, Aaron, I want to go to you first. How much at ConvertKit, for instance, how much is the design team involved in the actual component architecture? Like, is it a waterfall process or is it more collaborative once you get to coding? How were the designers involved there? Maybe like two words about ConvertKit for those who don't know. Great call. I mean, of course, everyone knows it. Of course. So ConvertKit is an email marketing company where we help creators earn a living online through email marketing. And we also have digital products for commerce that you can sell. And going to your question, Alex, how we work with designers and kind of like the architecture with components is a very collaborative communication approach. So we have a design system, we have a component library, and we try our best to get those matched up as possible. And I think one thing that we both, within both departments or both teams, design team and the engineering team is we always try our best to have a futuristic approach when creating a component or designing a component, because if styles change, if colors change, if we want to change a button to a dropdown, we want to have those conversations early on. We even loop in product sometimes. So in the beginning of the creation process, it's very much collaborative. And what's the end goal? And is this aligned with the business goals as well? Awesome. And I should have said it at the jump, but to everyone, if you want to jump in after something, add something on, you know, that was a question kind of more specifically about how ConvertKit works. But in your experience, how was the design team involved in the component architecture? Like, are you discussing the actual API of what might be needed down the road? Anything like that. Does anyone else want to jump in on top of what Aaron said? I could add one more thing real quick.

We are very fortunate enough to have some designers that know how to code and have built a lot of our components in the beginning. And that's a huge win for us still. And on our team, he helps design and comes up with colors and components and things like that. And he's just more aware of kind of how the structure of components are and kind of the life cycle of them if we need them, if they change. So that's kind of been my first time working with a designer that is aware of the actual component architecture of it. So that's definitely a plus. That's so useful when you have those things across the different disciplines.

I, I, I, I guess we are like, okay, I'm all done. I'm old enough to have witnessed the dream of components since long, long time. And we always wanted this components and to build things with components and stuff. But it always failed. I've seen it failing so many times. And maybe I can recognize that this moment is different than the other moment that I've lived, because I've lived that this kind of promise of components. So many times, so many like Microsoft and every everyone threw themselves into, into like, okay, let's build these things with components. But now it's very different. Imagine the design tool, like Figma has components built in, and they tell you use components, Sketch went into that kind of, everyone is now into the components. So it's a, it's a very different thing.

So now you tell me, should, should designers, if the question is that, should designers be involved since the beginning, of course, of course, and that the proof is in Figma, the proof is in Sketch, it and our designers, they, they, since the beginning, they, they, okay, we need that, but not only about the ma the micro component. So our, our business have been different, or maybe, I don't know, Aaron, you have a similar thing, but we, we also not only talk about these kinds of small components of like buttons and, you know, text areas and stuff like that, but also these kinds of sections, like if you look at a website, you have these horizontal sections, right? A hero and, and the other sections that you have in a website. So we call them macro components. We call them slices as well, but these things also. Um, uh, so the whole design system should be talking about the small components and also the big ones that that sections now the designers would be involved in the micro and in the macro components, but even the editors, I think we can stretch this kind of metaphor of components to that content writers. They could also think about components and, and build things with components. So I think like it's components all, all the, the, from, from, from the beginning to the end, I really think that it's a, it's a, it's very exciting moment where, where components are getting the success that they want. We want it to, to, to, to have with this approach. Alex, I've got a, a quick example of something that maybe is the complete opposite of what we're talking about here. But just for awareness of like how. Opposites attract James, go for it. Of how some companies work.

Of how some companies work. So when I was working at FedEx before I joined all zero as a software engineer, we didn't have any designers at all. So just like kind of raising recognition to like some companies in some teams aren't fortunate enough to have designers involved. So Aaron, to your point about having people that have a little bit of background in both, like even if, even if you just dabble, even if like as a developer, you pay attention when things look good and you start to ask yourself why? Like those sorts of skills and that practice of just trying to become more aware can really make a big difference. Especially when you don't have someone that's able to do that handoff for designs and tell you exactly what it should look like. If you're able to have a little bit of that knowledge yourself, it'll help hopefully kind of bring it along even without having dedicated designers, What kind of knowledge, what kind of things you're talking about? I mean basic design principles, right? Like white space, consistent fonts and sizing, and just spacing in general, thinking about user experience, right? Like that's something that people often overlook, and especially as developers, I think like when I get an idea, I'm like, oh, let's start writing code. But what I've started to do and I just invested in the remarkable tablet. It's not an adjective, that's like the name of the tablet. So I sketch out all the things with just like pen and paper of like, here's what the different screens are going to look like at a very high level. And here's how you navigate between them. Like just going through that exercise gets you a lot of the basic answers from an experience point of view that developers often overlook. So I think being intentional about that and then just paying attention to, like I said, typography, spacing, that sort of stuff on websites that you think look and feel good can go a long way.

I have a question about that and I don't know if you can help me with this, but when you design components and it's good because you know, you have this kind of sandbox environment where we will design the component, but do you also always like try to think about components together? Like, okay. You design components as atomic things. Do you, do you look at like how will they behave together? Is it the designer question, like a responsibility to, to look at how components will behave together in a page or, or together with another component or all these kinds of things? I think. For me, I think you should always be thinking that way with components because I think that's the beauty of react is it's going to throw again, a Lego analogy. They're building Legos, react, building components. You have one component. It's great on its own, but in order to have something even greater, you need that bigger component. So I think going in with the architecture of knowing that this component is going to be used in another component, and it could also be used in a completely other component should be able to function and be tested to work all those spread out.

Cool. I, I, it's, it's awesome. Cause I was curious about this too. It's Sasha in, in the chat actually just asked a, a longer question. So I'm going to try to sum it up a little bit, cause I kind of have a similar question of how do you make your design system scalable with your code base? And Sasha kind of also touches on, like if things start to change within that code base, like fonts and colors and just over time. So it's kind of the combination of making sure that your components are like hard coded for, for colors. And then when, when the design team says, Hey, that green is now blue. You have to go through and change a hundred components, but also the, the trick with making it so that your first component doesn't look out of place when you put it next to your hundredth component, like how, what are some best practices with keeping your components visually consistent and scalable? Dad, or do you want to, do you want to hop in on that?

Yeah, sure. I mean, I can kind of speak to some of the experience. So I honestly haven't worked on a lot of teams using like React as an engineer in the last couple of years. But when I built React Native Elements, which is essentially a UI component library, and it was kind of like the first big one to hit the React native ecosystem. And it still does, you know, hundreds of thousands of downloads, and it still seems to be very well received. One of the main principles was extensibility and not having any configuration that couldn't be overridden in some way. So when you're building out a component and you kind of have, let's say for instance, a button and you have like all of these different elements that are within the main container. And this was React Native. So we're talking about views, we're talking about text elements, but you could kind of apply the same thing to dives and spans and paragraph tags and all this other stuff. But one of the things that seemed to like really resonate with developers was that they could pick up this UI library and they could get productive with it and they could build out their app much faster because they didn't have to sit there and write out every button, every list, all these things kind of came pre-packaged. And then once they got their app written, they could basically overwrite whatever styles that they had. So literally everything could be overwritten. So I think that seems to scale really well, as long as you're creating things that even if you need to kind of override something later on, you're never, you're never kind of constrained by the API. You kind of have every single thing available to the developer, but with smart defaults, right? Like something that kind of works out of the box and doesn't break. But at the same time, if you do want to update it, you kind of have that API service extended to the user.

Awesome. Thank you. Yeah. There's one specific thing that comes to mind with the question of like fonts and, and colors and things like that change CSS variables is a big, um, a big specific thing that I think people can implement to help them out, because one of the things I really like about Tailwind as a framework for people haven't used it. It's a, like a utility based framework and it has basically design principles already baked into it. Um, but it helps you, it helps give you that consistency, right? Like you have this many different font sizes that you can choose from. You have this many different shades of a, of a different color that you can choose from. And the equivalent of that, if you, if you do it by yourself, as you translate that into CSS variables and use those. So at the time, if you use a variable, you probably wouldn't call it orange, you'd call it like accent color or something, and you have it all throughout your application. Now you can update that thing in one place or the font sizes or the box shadows or things like that. If you go back and update those CSS variables, now you're actually, you're able to scale just like you would in like programming, right? Like we don't hardcode things. We use variables as much as we can. So CSS variables, I think would be a great way to help, um, ease that transition in the future as, as some of those things start to change. That makes sense. Is that something like, if you had like a theme configuration file that you could kind of keep all of your configuration in one place, um, where would be the trade-offs between using CSS variables versus something like that as, as someone that hasn't had a ton of experience with CSS variables? That's why I'm asking. I guess that would, I'm not, I'm not sure I'm the best to answer that. I guess it would depend on like what kind of CSS you're doing. Like if you're doing like styled components or like other, um, CSS and JavaScript or like other tools, they might have their own way to do it. I think more or less that accomplishes the same thing, right? Having that centralized, like here's this, this, this, this and this, and then just use reference that thing instead of hard coding the variable or the value over and over again. So I, I think it accomplishes the same thing. Although I guess it probably depends on like what you're actually using specifically. Okay. That makes sense.

For consistency, I don't know if, um, I, I can add to that, but I think one of the major thing that, so basically what we do is that we, we, um, so a lot of like our users, they, they, basically they, they kind of pushed us into, into like, uh, components, components. You need to do something about components, right? And I was like, okay, w what do you want us to do? And, and the first thing they asked us like, Oh, Hey, like, we have this, because often our, our business is like to connect data to, to some kind of contents, some kind of data into, into components. Right. And they tell like, okay, first thing they wanted to the model to be next to the, to the, the, the component. So that you're like, you, you don't have them to leave, um, in, in different places, like the queries, the queries. And, and the data model for a given component, like what things go into the component, they want it to be, to be living together with a component next to the component, basically as part of it.

And the data model for a given component, like what things go into the component, they want it to be living together with a component next to the component, basically as part of it. So basically even the query and maybe there is, you know, you will get back to this topic, but even the query itself, like it should be in a way componentized or, you know, and, and also the other thing that I feel for consistency is very important is to storybook can, can, can solve a lot of problems. There is to have some kind of combination of, uh, using components together. And now I'm, I'm always talking about macro components, like these say a website sections, like we try to have a variety of story book stories where they combine kind of randomly at different sections to see like, okay, are they still working well together? Do they work together? And I get these stories, these bigger stories that will, will combine components will allow you always to see like, okay, are they consistent? Are they breaking together? I guess it, it helps you always have a view of how things combine together. I don't know if you have that experience with storybook and combining things, things into stories. Um, so I, I think that like storybook is fascinating. I think we could definitely dig into that. I do want to move from design, um, on a, some of our, our other topics, but, um, I would love to have a followup panel with all of you just talking about the design and consistency aspect. It's there's a lot to get into, but, um, so kind of shifting to reusability, um, James, I'm going to kick this to you. When do you start to break a component down into smaller components or break like logic out into hooks? Like what's kind of your, um, I don't know when, when, I think there's, there's no, like easy way to ask that question because there's also no easy way to answer it. It's just, this is kind of the same thing. Um, I, you think about like when people talk about learning and programming and their, their purists and they talk about functions and functions should do one thing. That's kind of like a similar principle for components. Like this component should, should do one thing. I think most of us who have, who have written reactor review or anything with components have been in the situation where we start off and we just dump a bunch of stuff into a component. We keep adding until it works and then we look at it and it's like, well, this doesn't look very good. Right? Because there's, there's different things that are going on. We're accomplishing different things with different parts of the code. So I think some of it's kind of an eye test. Like there's no limit on lines of code, but some of it's an eye test. And then some of it's just looking at like, how do these things function? And then. If they function differently, that might be enough of a reason, but also if one part of that functionality could be used somewhere else, then you're thinking about like, not just separation in terms of like clean code and organization, but can I reuse this thing somewhere else? So, especially if there's a way to reuse that thing or to make it, make that thing, take in properties and make it customizable through props. That's a great reason to move it out. I think moving into like hooks and react, um, hooks are so powerful. And like, I continue to realize their power almost every day. Any, any sort of like. Not just a display mechanism, but like data, for example, that you need in a few different places. An example of this for me is I built my Twitch overlays, so like different pages for my Twitch streams and Gatsby, a framework built on top of react. And on different pages, I wanted to be able to display the title of the stream. And I was querying that from just the serverless function and Netlify.

And so I would, I would query it here, query it on a page load, on a different page load. And once you're doing the same query, you realize like, I probably want to share this stuff across components. So you can, you can then take that functionality, just going and getting that data, have that stored or accessible in a hook through a provider. And then now have that information all over the place. So I'm not having to query multiple times. I queried once I had the data that I need. And then any different page or any different component, I can access that data and pull it in directly.

I have a good example for this. Um, my current project, I'm working on Spotify embeds for our email and for our landing pages. And the way I usually approach creating this component is to just div it out. So I just make divs within divs, and divs, and divs, and then I end up seeing, Oh, I have a header, I have a subtitle. I need a Spotify logo. I need a play button. And I need an image. And so once those keywords start popping out to me, I realized that those are going to be smaller components. So I, I think for me, for advice is I don't know that it needs to be smaller components until it's one big component.

Um, and then being able to like map it out big, being able to pull them out small and different files. Help with the structure of what you actually need within your component, if that makes sense. Yeah, absolutely. Um, I'm just giving them a little bit of space in case anyone wants to jump in because it, you know, without it being in-person, you can't make the eye contact like you, you, so it was always that, that little bit of awkward pause, but I wanna make sure I'm not stepping on any toes or a sidelining any great additions there.

Natter, I actually have a question for you. Uh, how do you kind of decide whether or not you're like with a compound kind of component? Um, how do you decide if you're going to be baking in other components or if you're just kind of leaving a space for children components to be, to be passed as, as, as a prop? Like what, what kind of a judgment call do you make there? Um, I mean, I guess kind of just always keeping the idea like extensibility and scalability. And if this, if there's any chance that they're going to use this by itself and make it to where that it's not going to be affected by having a parent. Um, I don't know, like, uh, everything that could be standalone should be enabled to be maybe standalone and that sort of thing. Um, I know that like at AWS, we were, um, building and supporting a UI library that kind of allowed people to just spin up like authentication flows and image pickers and stuff using, um, using React components and just like maybe one line of code and, um, some of those things were, um, kind of like relating to that. So for instance, for authentication flows, you could like spin up, you know, the entire flow with, with a single component, or you could kind of like nest within those components, um, individual components to kind of like configure things the way that you wanted, but we made it work either way. So you could use these components standalone, you can nest them together. And, um, and yeah, it seemed to work out pretty well, pretty well that way. I guess. Awesome.

Um, cool. I, uh, I know we are, we are running a little short on time, so I want to make sure we kind of hit all our main things, so I kind of want to move on to dynamic content and logic, just as kind of a broad topic, but, excuse me. Do you have any like best practices, uh, for bringing data into your components? And Sadek, I know that you, uh, you, you think about this a lot in, in terms of. Um, yeah, just in, in terms of how to get data into, into those components, ways to make that still re reusable, um, and dynamic if, if, if needed. I mean, yeah, it's, uh, it's a, it's a big challenge and your components could mean a lot of things. And often what we deal with, as I told several times already, we, we, we deal with websites, right? And a component could be part of any page basically. So, um, as I said, like the, maybe the most important thing is like to, uh, have a way to componentize the, the, the, the, the query, right. But you don't want to do like 10 queries or 20, 20 queries if you have 20, uh, components, so you need to kind of get one, one shot, all the content and then break it into different things. So we have, we have a concept for that, but you know, you can do it also with the graph QL, it's a, it's a very good way also to, to break the query into smaller parts, but then you can, you know, uh, form a bigger query. But the important thing is like, uh, it's important to think in components, even when you're talking about data, okay? Like, uh, and then, you know, there are different kinds of components, like you can have a page itself could be a component, right? The whole page is a component is a company as a page component. But then each section of it is a component. And then the, the small buttons and, and, and things that you show inside that kind of micro or section, uh, component or section are as well. So you need, so it's, uh, it's often is, um, so we, we try to make like, okay, best practices we, we see what, what matters, like it's a matter of at which stop, we should stop breaking things into smaller parts, right? So I think that it's, for us, at least for our experience, there has been the section level is, is the, is the middle ground. Okay. So let's break the data into the smaller sections and then, and then that's it. You know, each, each section will manage its own, its own, uh, data and its own, uh, uh, components because it, it seems to be in websites. This is how it goes. So it depends on the logic, on the app or what you're doing. Right. But it seems like sections are more or less independent and you can take that kind of make that kind of assumption and say like, okay, we break them into these kinds of macro things and then everything else will, will get from these data.

So this is what we do often, right. But the important thing is like you have, as I said, the model, the model of the data should be next to the component because otherwise it will be a mess if you do a big query and then you will throw that data and hope that the component will, will find their data that could break. That's so fragile that can break so easily. So that's why, even when you're modeling your data, you say like, okay, I'm modeling that component, that, that, that section instead of like thinking about the page as a whole. I don't know if that, that's clear, but that's, that's what we, at least what we understood from our clients.

There's a couple, couple of tools that are useful as well for like caching and cache and validation react query and use SWR are ones that I've used before. And it took me a while to kind of understand the use case for them, mainly because they automatically continue to refresh your data, even if you don't tell it to. So one suggestion is even if you use one of those tools to help take care of like your querying your cache or cache and validation, you might take away those things from updating automatically if you have a situation where you know when that data needs to be updated. So you're not making extra requests and getting data that doesn't need to come down.

But those, those sorts of, uh, those two packages specifically add or take away a lot of the boiler plate for doing like use effects and fetch calls and that kind of stuff. They take away a lot of that and then just expose your data to you in a way that works really well across components. And it's funny. It's, it's funny that I saw in, um, for instance, in, in several framers, including, um, next, for instance, that you have this kind of distinction between static data and dynamic data, which comes very handy in this kind of case, uh, because also the way you manage that is not the same, like in a website, mostly static.

You don't need things to be dynamic. And that's, that's, that's a waste of CPU cycles, right? Or whatever it is our network or a lot of other things. Uh, where is, where is for other things that should be dynamic? Then it should be dynamic and you decide that, okay, this component should be dynamic. And I guess it's a good, it's a good way also of dealing with this problem. Yeah.

Awesome. Um, James, I'm actually curious about the benefits of Auth0 hook based library compared to what I feel like we used to have a lot more of was like you would send the entire form as a component. And I would like import a form. I'm not sure if that's how Auth0 did it, but I see a lot of libraries moving away from here's our input field. Here's our button component and you use that, but now you're just sending us the logic. What's the benefit there?

Yeah. Uh, so I love our React SDK. And then more specifically, recently our new Next.js SDK is fantastic. And what it does, like you said, is it, it, uh, you use the Auth0 provider, you wrap your application, which means you then have access to the use user hook in any different component that you want. And anybody that's done anything with users in the past, you, you probably want like information about the user in the nav bar. So you can conditionally display log in log out buttons or like their name on a profile page.

You need information about the user display there. So you end up needing user things in lots of different places. So with our use user hook, going back to the use case of hooks that we talked about a few minutes ago, in any component that you need information about the user, you just use that hook and have access to it and then display it. And a couple of other things that it does, it gives you the user, but you may not have a user, right? So the user may not be logged in. So it gives you a loading state as it's doing that validation to tell whether or not the user is logged in. So that, um, in applications, oftentimes you'll see a little flash when the application loads, you might see log in and then it switches to log out because the application took a second to realize that the user's logged in. So you can actually handle that with the loading property is loading. I think that comes back from that use user hook in addition to the actual user itself. So a lot of the conditionals become like, if is not loading and user then display some sort of user information or the opposite of that for like a log in button versus log out button, but just having access to that hook and using it in any component that you need to get the information that you need about the user is super, super nice.

Awesome. Um, so to kind of close out, I think we're, we're coming up on time, but I kind of want to quickly get to maintaining those components and, uh, Aaron, if, if you wouldn't kind of mind talking just about testing, why it's important and like what, what, which kinds of tests you would recommend in terms of if someone had to prioritize and oftentimes we do, uh, with, with which tests we are going to be implementing. Um, what's kind of your advice to people out there? Yeah, I have a love hate relationship with testing. I want to love it and I know how valuable it is, but it's just such a process. Um, and tests like TV is such a thing and I think it's great, but I haven't got to that level yet. Uh, maybe one day, but, um, component wise, I think being able to test, um, react testing library is what I'm most familiar with. And to be testing at a smaller component level and then growing up from there, um, I think makes you more secure in these core, like primitive components and to be able to use them throughout your app. So being able to have tests there are super valuable.

Um, I saw a quote or a tweet some, it's a couple of weeks ago, I think it was, and it was, um, you should treat your tests like a contract. So if someone else comes in and messes up your tests, it's not your fault. Smart. That's why I love that. Um, well, thank you so much. I, I took a lot from that. I learned a lot. Um, thank you so much to Erin, James, to deck Natter. Uh, really appreciate you all being here. Um, yeah, I think that's, that's pretty much it. Thanks for moderating. You did a great job. Oh, well, thank you. I appreciate it. This is, this is great. Um, yeah, and thank you for being here at react summit. Everyone. This is a, this is quite, quite the, uh, quite the events. So thank you so much.