Chad Stewart 0:07
Thank you so much. I really appreciate it, Brian. Yeah, so thank you for attending my talk, we’re going to be talking about building your front end with intention, just some architectural decisions and tooling, you know, that you can use be an expert front end project. attached to it. I’ve been a front end engineer for about 10 years now worked in enterprise worked on open source worked in small organizations worked all over the place. So yeah. I’m also the founder of tech is hiring, I also have a little label at the bottom that I’m pointing to that is completely invisible to me, because I can’t see myself. If you see a goofy person always asking somebody to retweet their job postings and stuff like that, that goofy person is me. So we just tried to promote jobs and job seekers and information to assist job seekers. So you can check us out on Twitter, and, or Twitter X, you know, Y, Z, algebra? And yeah, you can just check us out there for for promoting jobs and job seekers.

Chad Stewart 7:33
Yep, so front end complexity is sneaky. It’s just, it’s really easy to have like things like components that are being coupled. And it’s really quick for for components that it just be, it becomes a nightmare to, to build upon what you have, like I have a good story. Actually, they work for a previous project, we were we it was a completely greenfield project. And, you know, everything was great. You know, we were we’re developers, we love greenfield projects. So you know, I’m sitting there dancing, my chair. Um, you know, it took, we were working on it for the first couple of weeks, it was perfectly fine to update, you know, add new features and stuff like that. It took about two months, within two months, it was it came to a point where things just kind of grew grinded to a halt. And it was just very difficult to add new features, you know, to the point where I was looking like this. I’m sorry, I’ve been so I’ve been practicing this and every time I see this cat, it’s so so… So what options do we have to deal with? You’re gonna see me giggling a lot throughout this presentation. So what options do we have to deal with front end complexity? So primarily, we want to encourage loosely coupled code, you know, through components through our business logic, which we’ll talk about later. And it just allows us to kind of focus specifically on the use case for like the components that we were leveraging where we’re, we’re building. And yeah, it just makes it easier for for people for us to engage us and others to engage with our codebase. So here are some of the things that we’re going to talk about want to talk about component driven design, atomic design, functional/atomic CSS, and separating presentation, logic and business logic. I mentioned that earlier. Then some of the tooling that we’re going to talk about is storybook and good old TypeScript.

Chad Stewart 9:44
Um, so component driven design. So component driven design is pretty much the idea of thinking about our front end application, as a series of components as opposed to we have this tendency of building things top down, you know, You use open up, you start, like with a page, you build a layout, and then you build the components in a particular section, you know, component driven design kind of challenges us to think of, to build build components first, right? So I’ll give a quick example. This is google.com, you know, probably could have found a better way to express this, but we just think about it as as, as a single page, right? So we want to build the homepage, we’re like, Okay, we’ll just lay out everything we want, you know, we’re not even thinking about the components yet. Okay, now we, we build the components, we maybe build the header, and so on, so forth. And component driven design has challenges us again, to think about the individual components first, and specifically to build them first. So we have like, we these could particularly like I’m pointing at the screen, as you can see, we have things like the, you know, Gmail, images, those could be text or images. Ironically, we have icons, and then we have the Google logo. And we have the search bar, which I didn’t differentiate too much, but you have the icon on the left, and then two icons on the right, that could be buttons, and then more traditional buttons at the bottom. But the whole point is to think about the components individually and build them out individually, and then put them onto the screen. Atomic design is if you think if component driven design is more about thinking about your our pages, or our what we have on screen, as components, atomic design is a battle tested way of, of those of putting relationships to those components. Right.

Chad Stewart 11:47
So if you’ve heard of atomic Oh, so I thought the thought design was coined by Brad Frost, in 2012, or 2013, I believe, or had an amazing talk, I highly suggest you, you go and watch, it was a great talk. And the whole idea is to think of components atoms, molecules, organisms, templates and pages. So um, atoms. Here, we’ll talk about atoms, molecules and organisms. First, atoms are your building blocks, the way I think about them, is that they rely on on nothing else, right. So in this example, you have like your header, you have standard text, strong text, you know, and then like, you have an image hair and things like that. Molecules are pretty much collections of atoms. So here, you would have something like a card where you have a title in the card and understand the text and the card, and then a background or something. And the idea is just like a collection of a collection of of the building blocks. And an organism’s, the way I think of them is a collection of both atoms and molecules. And so we take this, we can take this process process, we can take this component, and we can add, say, for instance, the image here, which would be an atom and these in collect collection would make an organism I want to make a quick point here. So we have a button here, I’m actually going to show an example in code of what these are. But button like, these relationships are important to be consistent. But you can think of certain things, you can add certain things to certain relationships if you’d like to. So for instance, I think of buttons as an atom, I think of it as like the lower fundamental component. Whereas in this example, a button is a molecule I just want. It’s about the relationships and being consistent with them. So templates are where you start putting your your layouts in where I tend to use them is your is, you know, you define like you have layouts that you you want to use throughout your your site. And it’s just a way of doing that. And also, it’s really important that we’re not really important, but you have them, it doesn’t have any data. And the only difference between templates and pages is pages are effectively layouts with relevant data for the page. And yeah, that’s pretty much it. So you have like these things, you have atoms that build molecules that build organisms that build templates that build pages. And this is some code. This is actually from the techishiring website. That’s an open source project, just for for for the website. It’s a little bit complicated looking, this is actually an atom. So you know, it’s the atom using chakra UI, which is a UI library, very famous UI library. You can go look into that. The point I want kind of point out here is that this button outside of chocolate UI doesn’t really rely on anything else within within the project. And it’s fairly simple. relatively simple. It’s fairly simple. But yeah, it’s just a, this is like one of the bare bones components. And then we have a molecule, I want to point your attention to here, notice that we’re importing an atom, and it leverages that atom, obviously, you can have more than one. But the relationship that I want to point out here is that it’s leveraging an atom, right? And it’s like, you can have an atom or multiple atoms, technically, this is an atom as well, probably need to change that. But this is an atom you could, from the chart that we saw before, you could view this as standard text. But yeah, that’s pretty much it. And then we have an organism again, I want to point out here, you look at the import statement, we have an atom at a molecule. And that’s how you build this component out. So I just threw a whole bunch of words at you, right? Like, so why in the heck does any of this matter? Right, like, but live.

Chad Stewart 16:15
So I think the reason why this is important like is, well, I don’t want to say the reason why it’s important. But I had such a great experience, building with with with atomic design, have actually project a couple of projects back, I ended up having to build on onboarding flow twice. Right. And the first time I built the onboarding flow, took a couple of weeks, you know, there was a lot of back and forth a couple of weeks or a couple of days, and it was a lot of back and forth. And, you know, it was, yeah, it was a lot of back and forth. And then, you know, I ended up having to build another onboarding flow for a similar similar project. So I’m sitting there thinking, Okay, I’ve done this before, you know, it’s probably gonna take some time. So, you know, I’m just like, I’m just kind of prepared for that, right. So Friday afternoon, and I sit down and I start getting I get to work, right. So, you know, you enter the flow state as, as you are, as a developer, you just sitting there, you kind of banging away at this, and then all of a sudden, you know, four hours, four hours flypast, and all of a sudden, the components is more or less done, you know, so I say it takes six hours, I sat there for like, maybe four hours and the component was finished, and then you know, an hour of kind of going back making sure that you’re doing and you’ve actually, you know, done everything properly. So, five, six hours, you know, put the whole point is, you know, I, I’ve done this before, it took significantly longer, and I sat down there, and I was literally flabbergasted at how fast it was to turn something over. So why was development like this so easy. And I think it’s because first of all, to be 100% Fair, the project was a bit mature, it was a couple of weeks in. And so we had these components, we had a lot of the the atoms and molecules built out. But I think the main thing is that you leveraging atomic design is very much like putting Legos in the right place. And so you spend a lot less time actually having to build out the components over and over again, which tend to happen. I mean, you know, like you’re using a framework, you may you try to be you try to build things that are reusable, but that tends to that, you know, it’s a hit or miss on whether that happens, this just helps to enforce like, the reusability of components. And so it’s just very much taking the thing that you need, putting it where you need to do maybe making a few edits here or there. And it just, it makes it, it makes the process so much easier, removes a lot of the roadblocks, like so you can rely you so you rely on the idea that the component works and if the component is your code base, and you know, it hasn’t messed up, before you have a lot of confidence in you know, that it will, you can just leverage it and edit it whenever you need to. And this wasn’t even an isolated incident. So you know, as as we’re moving through the project, we tend we ended up having a lot on our plate. And so we needed to pull more people in, or we need to pull a freelancer and try to help with the project. And generally this is a management of managerial, no, no, you, you know, you if you bring somebody new, like the ideas, oh, you know, you have more than one person to help you with development. And generally what ends up happening is you have to train the person and the time that you would have saved that you think you would have saved bringing that person on, you spend having to train the person on the codebase and yeah, and you know, obviously the added cost of bringing that person on there.

Chad Stewart 19:59
That did not happen. In this case, what ended up happening is that the person came in, and they were able to contribute fairly quickly, like, within days, they were able to contribute fairly quickly to the codebase. And my opinion, the reason why that was, is because when you have your components isolated like this, one of the big things that you don’t have to worry about is you don’t have to worry about learning the entirety of the codebase, or knowing all the intricate relationships with the codebase, you can just associate with the associate, you can just think about the things that you need to work on. Right. And so allows you to consume the codebase as as somebody learning it very piecemeal. Right? So I do want to point this out, is there some something that I really stressed atomic design is about the relationships between your components, right? And so atomic design is based is like analogies based off of chemistry, and to be to be 100%. Fair, you know, we don’t necessarily have that type of thinking in web development at all. So, you know, you have to train the person on kind of that thinking, right? So the point I’m making is, if you don’t necessarily want to leverage atomic design, you don’t believe in those relationships, you know, an alternative is to build your own relationships, to build to, to make your own relationships between the different components, it’s extremely important that you’re consistent. And you have a way of sharing this with the rest of your team. But the point here is having those relationships and leveraging them properly. So I just wanted to point that alternative out. So functional atomic CSS, right. So it’s the idea of taking, instead of having CSS that is owned by a component, you know, you make a selector, and then the selector, and then you have styles that effectively the component owns because of the way you write in the CSS, you’ve written to see it. Right. Right. And, again, you’re gonna I’m gonna be giggling presentation. Um, but yeah, so instead of that, you have a suite of CSS rules. And those suite of CSS rules tend to be very small in like a single type of action, and you apply those to your components. And the point is, it switches the ownership, right? Nothing owns the CSS now you will apply will the CSS, you apply that CSS action that you want to your components? Right. And so here’s an example of traditional CSS, again, the you know, in the way I was describing is effectively, this is again, pointing at the screen, you can see it, but again, you have this navbar, obviously, in the menu, and then you have CSS that effectively, the navbar owns by, you know, being named the same way. Whereas functional CSS, this example is through tailwind. I’m pretty sure a lot of people kind of have been approached, approached have heard of tailwind, it’s a CSS library that it calls itself utility. First CSS. And it’s the idea here is, again, you apply a CSS class, you’re applying a class that has specific rules. And the idea is to to apply effectively, this styling, which is seen as an action to your components, right? The example here that I want to point out is, you know, I want this I want all the text in this component to be blue and 600 is just how to tell when it’s decided to do the shade of blue. Again, just said a whole bunch of things to you, you know, so So why does any of this matter but why? Okay, I’m going to entertain this presentation. Um, so we So again, going back to tech, his hiring, we have an open source project, take his hiring. And our couple are a while back, we had a major release. And a lot of that release was based off of was based off of contributions. Absolutely amazing. I like to thank all of our contributors to helping us you know, build out factories hiring, the Texas hiring website. And what ended up happening is that there was just a couple of things that needed to be finished and I decided to take those on. And also, we also decided to update to Nex 13. It was. Net, we were using the ix 12 at the time and that update, I had us, Pat us. We had to change the way one of our components work and it was just like a bit of a CSS thing. And I noticed that there were some other issues that happen had popped up. Now, generally, to be quite honest, in other projects, I would sit there and like, oh, there’s CSS problems, and you immediately go God dangit.

Chad Stewart 25:11
I don’t want to have to deal with CSS, you know, it’s like, there’s so many people hate. Yes, that’s right. Um, but I didn’t feel like that. I felt like this, you know, it’s a breeze, right? I can just, I can make changes, I can make changes, and I can feel very confident in those changes, right? Why is that? Why Why was that? It’s, again, I’ve been stressing this a lot. It’s the relationship between the CSS and the components, right. So the component no longer owns the CSS, the CSS is being applied as if it were an action to the component. And so that, that allows the CSS allows the CSS, but it makes it so that the changes change, primarily that component, and it makes debugging really easy. So if there’s a CSS issue, more than likely, and not even more than likely, I cannot even think of a case where the CSS was caused by something else unless it was maybe like a neighbor, right. But generally, it the CSS is whatever problem is being caused is being caused by the CSS that you apply, that has been applied specifically to that component. So it just gives you so much more confidence in making changes to your component. Knowing that, like, you’re not going to blow another component up, even if there is is an issue. It’s either the component that you’ve changed, that is causing an issue, and it’s or the neighboring components. You know, there’s also I do want to point to point out that it also kind of makes the, I don’t want to say it makes the code tidy, but it just makes it easier. You put all your presentation logic in one area. And we’ll get to that in a minute, we put the all your presentation logic in that in one area just makes it so much easier to deal with, you know, working with your presentation logic. And yeah, and then you can make really, it’s really easy to make refactors. And you’re not going to stop selling books or faces, I really like it.

Chad Stewart 27:09
So separating presentation logic and business logic, so self explanatory, keep your presentation logic and business logic separate. Now I want to explain what presentation and business logic is. presentation logic is pretty much anything that displays that display something on the screen. So in the web, the way we think about the way we think about this, what it says is HTML, CSS, obviously, you can use JavaScript to put HTML and CSS on into it to add markup, but it’s just whatever logic that you’re using to display something on screen. business logic is generally to the way we think about it is to how we think about is enforced, like a business case. But it’s just like, the best way you can think about it is how to like, if you need to do like fetch data or something like that, if you need to do something functional, not necessarily like you want to manipulate data, you want to get data, you know, like, the reason why it’s called business logic is it usually is attached to a business business use a use case. So say, for instance, you know, you want to you want to get all all rows, I guess this database example, get all rows from from orders, you know, like, that’s what would be the that that code that does that would be considered business logic. So here, so we have an example here of colocating. business logic, and presentation logic. This is this is react. We have a component here, that’s a button. And when you click on the button, you go and you fetch a cat image from the cat API, because I like cats leave me alone. I clearly like cats. I thought it was neat stuff. Can you see me giggling? We get the cat image. And for whatever reason, I’ve decided that we’re going to replace test button with with the cat image, right? So here we have, we have the fetch data function, literally in the component. And there are a couple of problems with this. Problem. One, the way I tend to think about it is if you want to test this, it becomes fairly difficult, right? So you go and you for you to test this, you’d have to render the component, then you have to have your test runner, click on this button. And then you have two options, right? You can either mark the fetch data and check if it’s been called. Or you can wait for the fetch data to get the you know Your image, and what you call it, get fed to data to get your image, and then check if things have changed. And that’s not even actually a really good thing that you shouldn’t be doing anyway. But like, also, if you need to change things, this is a very contrived example. But you can imagine, if you have a large enough, if you have a large enough component, or elaborate enough component, you can you have multiple business, you have a lot of like business cases in that component, if you’re colocating all of this code, and it’s it just becomes hard to manage, right?

Chad Stewart 30:40
So yeah, that’s pretty much it, like you have it, testing becomes really difficult. It can be like, once a component gets really large, it can be really difficult to, it can be really difficult to manage both the presentation and business logic, you know, and then also, I want to point out that you have this tendency of, of coupling on presentation logic and business logic. So if you write them both together, you have this tendency of I’m going to write my business logic specifically for the, for this to this component that I’m using. And so obviously, it becomes really hard that say, for instance, if you need to use that business logic elsewhere, you know, you either go right over again, or it just becomes a little bit difficult to pull out, you know, it just becomes a bit of a pain. So just want to point so we have separate the presentation logic and business logic. And I do want to point out that the code has not functionally changed. In fact, the only thing that’s really changed effectively, is this line, this line has been had been has been added fetch data, but no, we can test this lot of this the presentation logic separately, you probably wouldn’t test this. But say, for instance, um, so the thought that I immediately have is, you have like a drop down, and you want to make sure that the drop down renders properly, you know, so you can test for that specifically, you know, otherwise, you don’t have to worry about testing. Well, I don’t want to say, you know, if you have other ideas of testing, that’s fine. But no, say, for instance, this fetch data, you probably won’t test this specific thing. But say, this is another, this is actually significantly more elaborate, you can focus on testing this separately, right. And I’ve been talking about tests all the time, you know, you become you have you build a much more robust test suite, this is actually technically from a node application, but it’s the same kind of thought process, you know, you have your code split out, so that it’s doing, you just have it split out to do specific things. And you can just build a very robust test suite, and you can, you can pull more value from your test suite you can be, you can be a lot more confident about the things that you’re that you’re, you’re testing, right. And you can also organize your business logic.

Chad Stewart 33:08
So this is technically from the techies hiring. What you call the tech is hiring open source project. As you can see, you know, we have we have everything kind of sorted out in its own its own folder components is pretty much where all the presentation logic is images, obviously, where images are, interfaces, is where, you know, all the interfaces are, this is TypeScript. And then I try to put as much of my business logic as I can into a lib folder. And here I want to highlight is I have an API layer, and then everything that that involves API layer is here. So this is technically layered architecture. And the idea for layered architecture is that you co locate all the code that does one type of functionality into its own its own layer, you it’s very easy to do. Um, there are other ways of organizing your your business logic, or just your your code base in general, I don’t want to get too much into them, because that can and has been a whole talk on its own whole books have been written on this. But I just wanted to point out that this is a benefit that you get you you get to put your thing your your all your code in what you can consider what you consider logical ways. And it just allows you to to interface with the code a little bit better. Right? Right. So I would like to start talking about a little bit of tooling that supports this that supports this architecture. Right. I primarily and primarily want to talk about storybook right so storybook is a way of documenting your design system.

Chad Stewart 34:52
And here’s an example of this. This is actually from this is literally BBCs design system they have a storybook if If you’re interested, you can literally go to this link, it’s a little bit small, but you can go to this link, and you can just literally see their storybook instance that they have live, what you can do is you can see the components that they have in their design system, and you can interact with them, you know, with with these things called knobs. And you had, you’d notice that there’s various ways you can interact with them. Oh, used to Yeah, I can play button. Yeah. But the primary way, like an A good example is clicking the disabled button. And that will show you a disabled version of the link, which I believe is a grayed out version of this link. Right. So you document all the behavior of your component. And it also serves as a visual smoke test. So you don’t necessarily have to split up the entire project, you spin up storybook, and you can just go and look at the component. And it’s like, okay, this is doing exactly what I intended to, I intend for it to do.

Chad Stewart 35:58
And I’ve heard of this as a controversial take, I don’t know why. But you can also leverage storybook as a way of is as an isolated development environment. Right. So in terms of an isolated development environment, I’m pretty sure everybody who’s done front end long enough has had like a large enough application where you have multiple screens, and you have to you have like a flow through those screens, it’s not particularly easy to get to some point in in your application, and you get you, you have to do some work on screen three, right. So what you do is you go to your router, and you start dynamic with a steak, and then you you come up with some convoluted way. So that you can just immediately go through to your to screen three, or you do the other tiring thing. And you just click through to screen three through all the things that you need to do. And then you start working on your code, right. And I guarantee you, if you’ve changed your alter, you’ve probably at some point done all the work that you needed to do.

Chad Stewart 37:09
And it’s like I’m done. And then you know, you completely forget to change your router back and it’s like, okay, now I just messed up the whole thing, you know, whereas with storybook, again, as you can leverage storybook where it’s like, you just have an environment there where you can build your components in isolation away from your project. And it helps again, we talked about or again, but we talked about atomic design and component driven design, the idea of building your components first, you know, this just kind of gives you a blank canvas to build your components first. Right. And I just want to point this out, I just wanted to give a quick shout out to Condi Shakur, who, from GitHub, she’s talking she was she wrote a blog piece on on GitHub Code Spaces, which is something that I’ve been leveraging recently, and just kind of being able to set up a particular workflow through that the using code spaces. And then I’m sorry, so I should make sense. I should say this, again, this is the tech is hiring, open source project. And she has this setup where you know, you install all your dependencies, you pretty much everything, everything’s ready to go. But you also spin up an instance of storybook, and it opens what you call it a tab to the storybook instance. So you can just immediately get to work. And I just thought it was absolutely amazing. I wanted to point this out. Thank you so much, Felicia. Yeah, so I’m pretty sure everybody here is has heard of TypeScript. You know, it’s a superset of JavaScript sits on top of it. And its primary job is, is adding static typing to JavaScript, one moment. So, though, the thing that we want to leverage from TypeScript is, of course, the enforcing the shape of the data that goes into the, the components that we use, right, so it’s like, I’m pretty sure you kind of pull in a component, and you’ve expected that you can pass something into it. And then it turns out that it just doesn’t use it at all. And things blow up, you know, you’re all sad face, right? So TypeScript kind of helps with that by you know, saying, okay, these are the things that you can pass in into the component, right, and you don’t have to like you, these are the things you can pass into the component. But a really big deal is also that TypeScript technically acts as the first line of documentation for your components, right. So you know, you import a component, you go to leverage it, you get it, you can get IntelliSense on a component, it will tell you what props, it may it may use, obviously, well, this is more from a React standpoint, but it will tell you what it means you know, all the things that are necessary things that may not miss that that are available but are not necessary. It just acts as a really good way of being able to kind of interface with these, with these components, right. And also, you know, using the component incorrectly, you get, you get a yellow squiggly or red squiggly based on your Ts config, which is, you know, pretty much tells TypeScript how to run. And it’s just, it makes the development experience so much easier or better. Right.

Chad Stewart 40:29
I do want to point out a little bit of an alternative. I’m pretty sure what I’m not pretty sure. But you know, if you’ve been on Twitter for Twitter first, yes, Twitter first. You’ve heard like people talk, you know, saying that they’re, they’re not really interested in using TypeScript. Primarily. To be fair, these are like people who are doing, who are using npm. But I do want to kind of point those alternatives. If you’re not as excited to use TypeScript, you know, leverage, storybook, more write. So storybook is an excellent way of documenting your components, you know, excellent way of showing like how your components work, what you can do, yet what you can do with them, it’s like, you can definitely lean more on that as an alternative. Right? So to recap, you know, we have component driven design, you know, which is pretty much viewing your, your pages as a collection of components. And you focus primarily on building those components first, atomic design, which gives us a battle tested way of, of a battle tested way of thinking of the relationships between the components, functional atomic CSS, which is pretty much flipping the ownership of flipping how you do CSS, where CSS no like actions, as opposed to being owned by components and separating presentation logic and business logic. And then we just talked about storybook, you know, documenting your component, your design system, and good old TypeScript. Right? So what do these things, what do these things enable you to do, and maybe a little bit beyond the scope of this talk, you know, I just want to point out some interesting things that you can leverage with, with this kind of type of stuff. So beyond this, you have things like, the idea of having an organizational component library, this is a primer, this is get hubs of design system primer, and this is their React components for that, and you can literally just npm install, this is at the bottom, probably should have highlighted that. But you can literally npm install it, I’m pretty sure GitHub uses this for all of their all of their projects. And the idea here is that, you know, if you have a very structured way of how you do these components, you don’t necessarily have to just have them be for one project, or you just have to repeat the code. And it’s actually I have a good example of this, or good example, I have, I worked on a project where we had to build out a mobile or mobile app drawer, and for whatever reason, we just couldn’t, you know, pull one from from the web. And the person who was building out the app drawer knew that they had a friend who had built it up previously. And so he went to them. And he had to, he just sent him the code, and that and then he just had to adapt it to our project, right? Like, that’s silly. Like, if you have, if you have something like this, you know, you can, you know, host your NPM library, you know, either in your organization’s network or even through, you know, NPM. And you can just pull this and install it and leverage it, and you have components ready to go right. And specifically for for whichever organization that you’re working for, you know, say for instance, you have a particular use case, you have a component that only does a particular thing, you can know, um, you can, like, you can add a little bit more coupling, there was like, Okay, I want the component to do this specific thing. And you just have all of your developers have access to this now, right? And not only that is like, you know, somebody builds a new component, they can just add it to this library, and now the entire organization has access to this. Right? Go that go away. Um, yeah. And then we have this idea of server driven UI.

Chad Stewart 44:32
I heard of this, mostly from Netflix. And the idea here is that the the, your your front end app, your client side application is just a collection of components. And the server literally tells you what component to use, and how to structure that component as well as passing the data through it. And the use case that I heard is I first heard of this is you know, you have a mobile application, you, you, you, you send it to the App Store, and then you want to make a particular change to hold the application is, right. And so, you know, do you just you want to publish it again to the App Store, you know, maybe not. So what you do is, you again, you build your client side as a blank slate and the server as the something the thing you control, that can send, can send things can send responses to this application, the application will build the UI on the fly, based on those responses. And the only way you can really do that is to have this structure, you know, to have these, like, have the structure in your your front end. So that your your served, excuse me, your server knows what components are available. Yeah, knows what components are available and what you can do to those components you like, it really becomes infinitely harder when you’re building things very haphazardly. Yep. So thanks so much for you know, attending my talk, I really appreciate you taking the time to listen. I do want to point out that the tools and techniques are I brought this up a lot. But the tools and techniques that I spoke about have are being used for the techies hiring open source project. And you can go to the repo at github.com/TechIsHiring slash tickets, hiring dash website, and we have a storybook that’s live, you can go to stories, that tech is hiring.com. And check that out. Just to kind of see an example of this stuff in action. I do want to give a special I do want to give special thanks to Rizel and Roman who wrote who runs a Twitch stream for people to come and practice their talks. I was on that Twitch stream twice. This is technically my first time they should have pointed that out. This is my first official talk. And they really gave me the space to kind of practice this. And I just wanted to, you know, I wanted to thank them for for for just encouraging me to do this. I do want to point out a point I want to give a special shout out to conditio occur, who, again, works at GitHub, wrote the blog post for for the GitHub Code Spaces, and was also gracious enough to add a contribution and awesome contribution to the open source project. Thank you so much, Felicia. And I also want to give a shout out to Jeff Beck. He works at Mozilla. And to be honest, the talk wouldn’t be the way it is without his input. I just want to give him a special shout out. Thank you so much, Jeff. Yeah, so where you can find me? I’m Chad on the score on the score steward on Twitter, X algebra. I’m gonna call it algebra. Find X. I’m not Yeah. So yeah, you can find me on Twitter. You know, um, you can find me on Twitter there. I’m also on LinkedIn, linkedin.com, underscore slash in slash chat. Our Stewart also tech is hiring us on both LinkedIn and Twitter. You can find us on Twitter on tech, he’s hiring at Tech is hiring and on LinkedIn dot com slash company slash tech is hiring. Again, thank you so very much for for, for attending my talk. I really hope you learn something. Thank you so much.

Brian Rinaldi 48:44
Thanks, Chad. That was great. There’s so much good information in that talk that, you know, I have to go, I want to go back and review it again. Because I think, you know, many of us don’t necessarily put enough thought in advance in when we’re developing these things, you know, developers just like, Oh, I’m just gonna start coding and I’ll get in, then it works. And you know, and it’s just like, you end up getting stuck in many senses. Later on trying to go back trying to go back and fix this is not necessarily an easy task. Right. So first of all, I do want to get to questions from the audience. We did have one but it folks if you have additional questions, we have a few minutes here for you to ask your questions. I’ve got some, but I do want to get to the audience questions first. So Dominica asks, Can you use CSS nesting in this approach? Or does it beat the idea of atomic design?

Chad Stewart 49:42
Um, I don’t think you can use CSS nothing. I’ve had this conversation before. And I’m going to be quite honest with you like my interface with functional CSS has really been tailoring I Though I did want to point out so you can build your own, like, functional suite of CSS, but I would. How do I put this? You, I would refrain from it just from my understanding of functionals of like the ideas of functional CSS, like, ultimately, you can do whatever you like, the way they try to present it is they try to have it like you have like one or a small amount of styles per action per class. You know, you if you’re interested, you know, you can, you can do how you can build that class, however, but I would keep it from keep it to like, a single action, or, like, I wouldn’t leverage nesting personally. But again, like my my main interfaces with tailwind, so you can try it out. But I don’t know if I don’t think it would be the best idea.

Brian Rinaldi 51:01
Okay, okay. Um, so I’m curious, you talked a lot about, like, in the atomic design part about, you know, particles and atoms and so on, right? Like, how is there any kind of rules that you use to determine what makes something a different, like, an atom versus a particle versus, you know, I can’t remember all the different terms, but, you know, a molecule, like, is there are is it more like, up to the developer to kind of determine what fits where,

Chad Stewart 51:36
um, so the way I think about it, so Brad Frost, they he’s very, was very specific about, like, you know, you have a collection of atoms, you have, like an atom is fundamentally doesn’t rely on anything, then you a molecule is a collection of atoms, and an organism is a collection of molecules and atoms. And so what I do is I kind of think about that, and then my own experience will kind of determine that the, you know, what those relationships look like, right? So, you know, the way you think about atoms is like, you don’t want your you want your atoms to, I should point out that so like, as you go up in that kind of hierarchy is the use case becomes significantly more specific, right? So like, organisms will tend to be, you know, like, more specific, you know, atoms will be much more general, right? So, the, you know, you think of atoms as your general things, you know, buttons, you know, tax stuff like that. Icons, things like that, you know, things that you can use everywhere, right? Molecules are more like, say, you know, I’m looking, I’m trying, I’m looking at literally the UI, like your input box, your input box, where, you know, it’s, it’s a, it’s input, and then it’s a button, right. So I guess I go with kind of like, what brought the Brad Frost example. And then I just use my experience to determine, you know, how I feel what I feel kind of fits that that. That idea? I’m not sure if that’s helping, if that the answer is yes.

Brian Rinaldi 53:24
That does help. I think I would have clarified it to me was this idea that it gets more specific as it goes up the chain? Yeah. Because, you know, the, the, when you get to what is it? Particles? Where was atoms? Then? Molecules?

Chad Stewart 53:44
Yeah, atoms and molecules and organisms. That’s when, yeah,

Brian Rinaldi 53:49
organism. So you know, when it gets to the organisms part like that is probably more specific to a particular implementation on a page, right? Like, as opposed to everything else gets, like more reusable?

Chad Stewart 54:06
Yeah, yeah. So pretty much. Yeah, that’s the best way to think about it, though. The lower you are in the chain is the more reusable The thing is, right? As you go up as you get to templates, templates, you know, templates and pages, obviously, they’re very, that even though they’re they like templates can be reusable, they tend to have like a particular use case. Right? So as they go up, you know, the use case becomes more than that more narrowed.

Brian Rinaldi 54:32
That makes sense. That makes sense. Yeah. And so and as far as I’ve never used storybook is so storybook is is something like you have to pay for or is it?

Chad Stewart 54:42
Oh no, it’s open source. So you can just literally npm install, you know, and you just UK you get an answer. Well, NPM MPX, whatever. Like you, you can definitely install it into your project. You know, you don’t you don’t have to do anything elaborate. Well, you have sent it out, but Um, yeah, and it’s just you. Um, could you elaborate a little more like what? Like, yeah, yeah, sorry.

Speaker 2 55:08
That’s okay. So okay, so it’s open source, there’s no, there’s no cost. They do have like a, I guess there’s an enterprisey thing.

Chad Stewart 55:16
Yeah.

Brian Rinaldi 55:18
Okay, but I like for for personal for these kinds of projects, like you could do it without necessarily utilizing this full.

Chad Stewart 55:25
Right, right? Yes. I just literally have like something set up, I have like a GitHub action that’s set up. So that you know, whenever I, whenever I update my, whenever I do a pull request, it will just update the incidence of storybook and just send it off to oversell to be live. But yeah, I didn’t have to pay for anything. It’s just open source.