Hey, everyone, Welcome to another episode of React Round Up. I will be your host today, Paige Nee Dringhouse, and we are joined by one of our panelists, TJ.
Van Tool.
Here everyone, and our special guest for today is Katherine Grayson NaN's Katherine, Do you want to introduce yourself and tell us a little bit about why you're famous? Absolutely?
First out, thank you so much for having me. I'm super excited to be here.
I am a senior front end engineer at threat Connect and I'm here today talk about component libraries. That's been kind of my jam recently, a place that I've really enjoyed, kind of working, getting to combine some of the skills from my design background with some of the technical aspects of being a friend end engineer. It's kind of been a niche I've found that I've really enjoyed and gotten the chance to give a couple talks on and build
a couple libraries at a couple different companies. Now excited to share that's actually really interesting. I have used a number of component libraries Bootstrap, ant design material, UI. How do you actually go about building a library? Though? That is that seems like a pretty large undertaking. It is and I think it's worth saying first that it's not
an undertaking that everyone needs to do. Like you said, there are a lot of really great libraries that really exist, and if you're just getting something off the ground or really trying to iterate quickly, then there's a lot of value in material design or ant design, they're good libraries.
But it's also true that if you are at a larger company, or you have an application that has some different requirements or has a lot of custom components that you find yourself using and reusing that might go beyond your basics, your button, your drop down, then it can be beneficial to have all of those in one place. Really get to control the design, control puts, the props that are passed in, getting to handle all the things that are kind of custom to your library. And you forgive me, you.
Know, as I said, inputs, which is because I've swapped recently this new job. We're working in Angular, which I know is probably heresy to say on the reactor. So I'm in the weird place now where I'm using all the React terms when I talk about Angular, and now using all the Angular terms when I talk about React, messing.
Up both that actually gets me into question like how deep when you like when you say component library, right, like what specifically are we talking because does does this actually get into like React code are we talking about just like CSS and HTML or does it kind of depend on specifically what you're implementing At least in.
My case, I'm definitely talking about code, so creating those kinds of custom components, and it does also include jsex and CSS or whatever your flavor of styling is, sass or less or whatnot. There are definitely component libraries that you can create fully in Stigma or your design platform of choice, and those are valuable in that they help you narrow down your design style, your colors and your type faces and really getting that kind of cohesive look happening.
But when it comes to actually being able to reuse those components that React is just made so well to do, they can help to actually put those all together into one shared library and be able to important max building so fast. So have the libraries that you've built are
they actually built with React? Because I've there's one in my company that's built with web components, because we have teams who build with Angular with few with React, and they wanted something that could kind of work with all of them, and it's it's okay, but it's been a little bit painful to implement because it's not actually React code.
So is yours? Like, is it specific to a particular framework the kinds that you've built. Yes, I've done one in React and I'm currently in the process of doing one in Angular. I agree.
If you're in a situation where some of that stuff needs to be shared across you gain a little, you lose a little. It's about that kind of compromise.
But if you are just working in one framework, then it's nice to be able to have that specificity and really build things in the way that you know exactly how they'll be used.
So I'm wondering if you could help paint me a picture of like what using a component library like. Well, first of all, is this like if for internal usage or these things you're like publicly documenting. And then then I'm sort of curious, like what's the use case like internally, Like I'm I'm an employee, I need to work on a new app. I need a button, Like what's my experience like, is it like using like a material or a design button? There is it a little bit different?
What do I install? And I'm sort of curious about that sort of stuff.
Yep, for sure. To the first part, whether it's something you want to share publicly or not, it kind of depends on the company. I know that that's super common now, and the idea of like, oh, we'll make it and we'll open source it and then everyone can use our components, which is one of those things that I think, honestly
is nicer in theory than in practice. The idea of sharing your wonderful work with everyone and contributing to the design world sounds great, but you actually give yourself just a whole ton of upkeep and new variables to consider when you're not just building for your own company in a limited use case that you have probably a stronger understanding of, right, So you then end up in this situation where you're like, well, we know that we're going to use our component this way, but what if someone
else wants to use it in some other way? So you broad things and you end up kind of creating I think, less specific and useful components because you're catering to a potential audience that you don't really know. If you have yet.
So I would say if you have a library and you want to eventually go back and open source it, and especially if you're working somewhere you know, real big, you hear about kind of the you know, the Airbnbs of the world or whatever that share THEIRS. But not not to sound dismissive, but I'm not sure every company
needs to share THEIRS. I think it's a huge accomplishment and a great thing in and of itself to build something for your company that suits the needs that you have and it doesn't need to be global.
Honestly.
Yeah, it's actually some interesting points I didn't consider, because I mean, the whole idea behind doing this is you're customizing something more than what you'd find in the general web. So I could totally see conversations of, well, we want to bring our logo into this component, but oh wait, this is like for the open Web, and what if they don't want our logo? Now we have to make
this generic. And it seems like you get yourself in the more complexity than you cared for concerns that aren't specific to your company right away.
Yeah, I will also say my last company, we didn't share our code publicly. So it was not open source and that other people could use our library, but we had shared it publicly so that you could go look it up online and you could go look at all of our components and like see the styles, and that helped us when working with freelancers and explaining things to clients. We used it a little in fact, for doing some like quick prototyping and click testing with users, which I'll circle back.
To because I've got a lot to say on that one, but it'll I'll track us.
But even then, just knowing that it would be out there on the web, we ran into some things where we were like, we're not really sure that we want to make that even visible, some questions of like IP or things that were super specific to our app or things that we wanted people to you know, pay to have access to, and be like, well, we are we giving too much away? Are we're showing too much? You
kind of start to walk that line. I think in addition to that fear of generalizing the components, we ended up solving it there by basically creating two versions of the library, like a public and a private. So the version that we actually put out that you can type in the URL and see does not include some of the more private and specific components that we wanted in the library for developer use but didn't want to be on the on the global stage. Basically, gotcha, it's really interesting.
So one thing that you mentioned towards the beginning was when you got to a point of components having very specific functionalities that you know generally you couldn't find in like an existing library. So can you give some examples of what that.
Kind of functionality might be that you that you encountered that you're like, we just we need to build this ourselves because nobody else really does something like this currently. Yeah. I found a lot of those to be a kind of specific to what your company does and what you're building.
The last company I worked at was a place called Hermann, and they do what's called a thinking assessment, which is kind of similar to Myers Briggs, which they'll hate me saying if they hear this, but where you kind of take an assessment and then it gives you some information back about your thinking preferences and how you tend to problem solve. So let's be a personality thing more of a thinking thing, but in order to share those results there's kind of a visual language and even just an
act technical language that's used. There's a specific set of colors that's used to designate strengths in different areas. Those things were just so specific to what the Herman platform needed to communicate that there's no way it wouldn't make sense for anything like that to be in material design.
But at the same way, there were components we were using over and over and over again to show people their strengths, their weaknesses, their dominant you know whatnot the way their profile broke down, their preferred methods of communication, the stuff that came up over and over again within the application that we needed to kind of get down and codify in that way for the ease of our developers. Yeah, that totally makes sense when you when you describe it
a little bit. That's really interesting though, So when you are or have been working on these libraries, are you building the library and then also building an application that's using it, or have you been able to like focus specifically on one or the other, because it seems like those are two full time jobs by themselves.
Usually it has been more not usually both times, it has been building both the application and the component.
Library, which I actually think is the right way to do it. You're right, that is a it's a lot of work, and I want to be clear that I'm not the only one contributing to these projects on these teams. In both cases, I've been kind of the project lean and I've gotten the opportunity to kind of shape it and come in with that expertise and say, here's how we're going to do it. These are the steps we're
going to take. But it would not have been possible without my teammates and the other folks that were equally invested in getting it off the ground and in building components and testing components and filling in that kind of
knowledge and expertise that's needed. But kind of circling back, I think it's best to work on both, honestly, because you need to have a feel for how the components are really going to be used, and you need to be putting them into use to be able to kind of validate that they are needed, because a lot of times when you start you kind of think, oh, I need all of these components, because you know, material design has all of these components, but you probably don't need
every single component that's in material design, but you know, designed to look like your brand. You can pick and choose things that you'll actually use. You can narrow down use cases rather than like creating everything and just hoping it will be used. If you're actually in the application and you're working with the application code all the time, you can get a better feel for what's really needed and what's not needed and what's just going to be filler that you'll have to maintain forever.
So thinking of the components and developing side by side with another app, so are these components that live like in like their own repo sort of thing, and like is each individual app that your company uses like pulling them in or there's some other sort of workflow in place.
That is how it's been set up in both cases is to have them in their own repo that does kind of come with its own lift that I know worries a lot of people at first, because again, when you're starting off, it feels.
Like a huge task to begin with to put together a component library, and then you have to think about and I have to have this whole other repo and how am I going to bundle these things?
But how am I going to export and import. Sometimes the easier mode is to just have a subfolder in your application, especially if you've got like a mono repo thing where all of your applications can kind of share that. That can be a really great place to just kind of get your feet wet and to kind of prove the need for a component library and to get other people invested, which is a huge, huge, huge, huge part
of the lift. It's just getting other people to see the value and to get on board with the idea.
Yeah, I'm actually wondering if you could talk a little bit about like the corporate politics of this, because I have to imagine, I think Page It's really where you were maybe going with this too, because like I think all of us on this call sort of get it
right because we're coming from this sort of background. But I'm curious if you've had run into problems of trying to get teams, like especially in larger companies, right you have different teams doing different things, Like what sort of issues have you run into trying to get everybody to use these components, like contribute to them, stay consistent and that sort of thing.
I think the biggest issue is getting everyone on board it first. Because most companies, without kind of realizing it, have started to build a library, without thinking about building a library, Almost every almost every application I've poked around and has that shared components folder. That is a good start, and it's where you should look. And if you start seeing that get really, really busy, then maybe that's a sign that a component library can be a good fit
for you. But there's a huge lift in terms of splitting that stuff off, right, because once you pull those out into their own repo, you have to make the decisions in terms of what part of this component needs to stay, what of this is really business logic it needs to be in the application versus what's presentational. How is the refactoring process going to work. How are we going to handle just getting everything swapped over that first step.
The first steps a doozy, But what I try to do to get people on board is to really focus on the outcomes, right and to kind of be realistic about what that first step is going to be. That you don't go in with delusions of grandeur that we're going to have this setup in a week and then.
It'll be amazing.
That this is going to take some upfront effort and that every small victory kind of along the way is something that we should celebrate. And in the end, we're aiming for this goal. We're aiming to have x number of components in use in the application, and it will
help us in these specific ways. And the more you can kind of nail down we're making a component library because we need visual consistency, or we're making a component library to help us coordinate with the design department, or to help us do user testing, or to help us tackle accessibility issues, like the more you can set specific goals for your company and use the component library as a path to meet those rather than the component library being the goal in and of itself, the more you'll
be able to give people on board with kind of your vision and why you're doing it and help them see the value in the long game.
I really like that angle because I think every single company I've ever worked for has had the issue with oh, look, our header looks different in these eight applications in these ways, or what do you know, we're using seven different fonds, or like our button, there's no consistency. So I like that sort of as an inroad to making the argument is like it's a path to getting there rather than just trying to share things for sharing sake.
Yeah, that's definitely, and in fact, that kind of discrepancy in the UI is one of the first steps I like to take in terms of sitting people down and helping them figure out what components will be valuable to start with, because again, the best thing you can do is to start to show that value as soon as humanly possible. As soon as you can start to get.
That ROI on your library, then the more people will be invested in kind of snowballs, And that's the effect that you want. I like to encourage people to sit down and run basically a UI audit on their application, and to go through and take screenshots of all the different heads and all the different buttons and all the different dropdowns, because when you see all of those in one document next to each other, it's usually enough for people to go, oh, okay, yeah, I see what you
made me. Maybe we do have a problem. That's where I can ask, because how would you go about doing a UI audit if you if you're you've never done one before, because I have not, so I'd be interested to learn, like, what are the steps for that? So credit where credit is do the idea of a UI audit is Brad rost Okay, so I want to throw that out there. He's got some really good resources on
running one. But the way that I like to do it is to basically almost make it like a game, set some time aside and kind of make some different categories in like a shared board, like a mirror board or you know, a Google slidestock, be like, all right, here's the page for headers, here's the page for buttons.
You're going to go on a scavenger hunt in our application and take pictures or screenshots of every single one that you find, and it ends up being it's kind of a fun thing because you go and everyone's see yeacking while you do it. And then when you get that and you have everything documented, you have the woe moment, which I think is important for everyone to see, like, wow, we have twenty of these, and then you can really start to talk through well why do we have twenty
of these? Is this one serving a different purpose than that one? Does this do something the other one doesn't?
Is there a feature that's a part of this? You know, both of these look like dropdowns, but one's actually a multi selector in a list, you know, and we need that, and that's a separate component that I dropped down, and that helps you kind of isolate what's happening and where it's being used and if there was any reason behind all those different versions, because a lot of times, you know, we think like, oh, someone was just lazy and coded their own styles, and there's usually like a bit of that,
but more often it's people trying to solve different use cases with the skills that they have. So they see a button and they're like, oh, this button is almost the same, but I actually also need it to do something else when it's clicked. So you end up with a button that looks a little different because they took a button, but then they tweaked it because it had to do this other thing, and then you hit up with twenty buttons.
Wondering could you talk a little bit about some of the tools you use for making this sort of thing possible as well? Or is this just quite literally you have like my company component library and then like a folder for each components. Are you using things to sort of help you build this.
I'm a big, big, big fan of storybook in terms of building out your component library. They have a really great system. They make it really easy to pick up and start going in terms of organizing your components and seeing that youI preview and getting your documentation all in
one place. That is definitely I think the way to go if you're going to have a full on library in its own repo, if you're kind of starting off a little bit more basic, like we're just going to have this shared folder, then I think it's okay to also not be swayed by all the bells and whistles of stuff like Storybook. Again, the more important part is
you get it out there, get it used. Once you go down, once you go down the rabbit hole of looking for things that you can use in your component library, they're going to find a lot of great stuff, because there's a lot of great stuff out there in terms of right not just Storybook, but all the add ons that you can add to it, all the ways that you can customize it, whatever you want to use to output, or using roll up or using this, or what icon st are you using, And it can escalate so fast,
and I think a lot of people get mired in that swamp of too many choices. My trademark that the swamp of too many choices. That's a legitimate thing for sure.
You see, if that domain is available, that's what.
I need another side project domain to sit.
So, Catherine, how do you how do you deal with either requests like people need specific components that your team hasn't built, or you have an open source project and people are contributing, like how do you manage that part of it? And getting people to contribute and then helping manage the contributions to make sure that they, you know, meet the requirements and are going to be useful to more than just one person who built it, and stuff like that.
I think in terms of getting people in it can help. Because I've been doing THEWS in a corporate setting and not in an open source setting, I have had the benefit of less optional participation. Maybe the nice way to say it, if you decide as a team that this is your goal, and you have whoever's leading the team on board with your idea, then it's just a project like any other project. It might not be everyone's favorite. I've built features that are not my favorite, and it's
just part of your job. I think what's important is to not look at the component library. If you decide to do it, then it's not a side project. It's not an offshoot or a pie in the sky. One day, we'll get back around to this thing that you can keep back burnering. It's a project like everything else that you're running right now. It has a different user base, but it's a project all the same. And so I really advocate for building it into your sprints in the
same way that you would build any normal project. Work, break it down, estimate it, throw it in the sprint, assign it to someone. It's just work. The fact that it's internal work shouldn't change that.
You know.
Yeah, I'm curious, do you're running too struggles where can totally see some project they need some new component and the quote unquote right way to do it would be to build it into the component library. But the faster way to do it, whether it's for deadlines or for whatever reason, is just to like, let's just toss it in there and go with it. Do you find you run into that struggle a lot sometimes?
And I think it is also okay to just throw it into the app and circle back to it. You just need to document that, and again that needs to be its own story that comes up in your next sprint, and you can't.
Back burner it forever.
If it really is like we have to get this out build it, you can always come back and pull it out into the library later and refactor. But usually the idea that you're giving your future self more work is enough to dissuade folks from doing it that way, unless it's a real emergency, because who likes to do Probably some people, not me. But I think the better way, the ideal way to handle that is to actually just estimate that story component building work.
Sorry, won't try it again.
The better way to do that is to just estimate that component work into the larger story. So if you're saying we need to build this feature, and we know this feature will include a component that should realistically be in our library, then building that component putting it in the library is part of building that feature, and so when you look at it, you don't say, like, well, you might have to add a couple of points to
get the component library work accounted for. But the other truth is that once you've got your component library up and going, the overhead of adding new components and putting them into the application is really really small. You're building it in the same way you were going to have to build the future anyway, you're just building it a different repo and adding an import statement. Better to I think, knock it out than give yourself work down the road.
Doesn't save you as much time as you think it would.
Oh boy, I can totally agree with that. There have been many times when we should have done it in a better way that we didn't, either because the requirements changed further down the road and we didn't know that's what was coming up, or like you said, because we needed to get it done in time of sprint. But that's a great segue. I was wondering how you handle documentation because that's something that my team has always struggled with, and we're not building a component library, So how do
you document something beyond Storybook? Because I know it has a lot of great interactivity, so that other developers on other teams can use it and understand what the components can do for them. I would actually say that that is a part of Storybook. They've got a whole kind of feature set devoted to writing documentation and showing examples, and it's pretty much up to you how much you take advantage of that storybook will automatically generate documentation, but
realistically that's not going to be what you want. It's just going to give you kind of an output. It'll show you the component and the props that are passed in. Can I give you the controls so that you can see like, oh when it changes? That change? Is that?
But the kind of documentation that you need in addition to that straightforward technical documentation is the design and UX documentation. So you've got three different buttons. How do you know when you're supposed to use this primary one as supposed to the secondary one? How do you know when I need this header as opposed to a subheader or whatever?
All those those contextual pieces are just as, if not possibly more important than the technical documentation, which is pretty easy to write honestly, right if you're checking your prop types and you're defining things well as you're writing them, then generally the technical documentation is minor and it's more the design documentation that's going to take the heavier lift.
And it's one of those things that I feel is not fun, but it's just part of making the component in the same way that like maybe you don't enjoy writing tests or maybe don't enjoy, you know, going back and cleaning up your code after you've got something working.
But it's just part of.
Good hygiene, I guess, good code hygiene, making sure that you're not just coding to get something done, you're coding for the developer after you.
With that in mind, when you so, I like the bit you said about the contextual the UX sort of background. So do you have like do you work with other design like UX people to sort of create these components and do those sorts of roles actually get involved with some of the documentation and such as well in terms of how these things are going to be used.
Yeah, I've kind of been in both situations. In one case, I was the loan design person on the team, so I got a little bit of free reign, maybe for better or for worse, in terms of getting able to
establish and build those things on my own. In my current position, I'm lucky to be working in a team that has multiple other designers in it, so we get the chance to bounce those ideas back and forth off of each other and really collaborate on making these kinds of components, which is a nice place to be, so, yes,
I do think that that's part of the documentation. The way it works currently, we have a designer who's really focused on putting together a design system, which we're building at the same time as our component library, because you know,
we like to be ambitious, I guess. So she'll go through and kind of take a look at the design side of components and say where they should be used and when they should be used, any kind of guidelines in terms of something like the amount of copy that should go into a tool tip, or kinds of options that we should present to a user if we're giving
them choices in a pop up model or something. Those kinds of design decisions that can be a little harder to make from a technical perspective, So she'll kind of go through and outline those aspects and she usually just includes them as maybe comments or lines in the PIGMA file.
And then we have a couple of folks who we call ux engineers, which are kind of like me that get to have a foot in each world and we kind of get to be that bridge and look at those components and say, all right, we'll build it in this way. Because she only wants, you know, a max of this many characters. We can prevent that, you know, we can set guidelines and kind of blockers in the way that we build the component that prevent it from
being used in a way that it's not intended. You know, we can have inputs get validated and things that prevent you from just blowing through. Even if you opt not to read the documentation, which hopefully you do.
Documentation is tempting. That's usually where I'll go. Well, I shouldn't say that I go there pretty quickly, but it really depends. But that's really cool that you get to kind of be a little bit of both both the designer side and the actual engineering side. Have you always been in a role where you kind of get to span both or has it kind of progressed since as you've been doing development.
I feel very lucky to be in a space where I get to do both. Actually, and it honestly came from the other side. I started off in the design world.
That's actually what I went to school for. I have a fine arts degree, which you know has helped me tons I say sarcastically, but in all sincerity, it really has, and that it's given me that I for color and design and hierarchy and balance and flow and that kind of edge when it comes to working with clients and understanding what a user wants and what someone's looking for and how to kind of give it to them in a way that will be intuitive and satisfying and hopefully
enjoyable to use. So I started off on that end and have actually been slowly making my way into development because, as it turns out, it's just more fun.
I completely agree with you. It is more fun to be built, and in your case, designing it as well. That's I think that's such a useful skill to have, honestly, and I wish I had more of a design background because I feel like it would help my own side projects turn out a lot better than they probably currently are.
I firmly believe that it's a skill that anyone can learn, like anything else. I think, especially in the arts, we're quick to look at something and say, but you just have to have the eye or have some kind of innate talent, And I think that's a good starting point. Some people absolutely do, and they'll have that level of native talent just kind of automatically. But the same is
true for development. Some people have a really amazing kind of logical mind that can break things down and can see the kind of pathways and relations between these components. They can see the way things get passed through functions
and how things will return. I don't have that, but it's a skill that I've been able to cultivate just through doing it and hard work and messing up the But I believe there are versus is true as well that if design is something that developers are interested in, then absolutely there are places you can start in skill sets you can learn and it benefits your work at the end of the day.
Yeah, I think it's sort of akin to like the closest example I can think of is like sports, Like there's some people that naturally and I see this with my kids, right, certain people just pick up on things faster than others. You throw them a ball, they know what to do a little bit better. But anybody can learn it, right, Like, it's just a matter of you have to actually put in the time. You can't And I'm guilty of this too. You dismiss it of like I could never draw anything, so I'm not even going
to try sort of thing. Like I said, it's totally a sentiment I'm guilty of too, But it's totally easy to have that gut reaction. It's far harder to actually put in the time and the effort to try to learn a skill yourself.
Absolutely definitely, I'm in that same camp of like, I'm honestly not a great drawer. My pen and paper skills are are lacking. I suffered through a couple painting and similar courses in college so that I can get to the design classes I was interested in, and I don't feel that that in my lack of ability to draw much more than a stick figure has actually impeded me much.
So I do have one question to bring it back
to the component library a little bit. I'm curious how you handle, say, like more complex components, right, because I imagine, so you build a button, you build some of these things like those are something like any web developer can do pretty decently, but I imagine there's a complexity level where you're probably not going to write it sort of yourself from scratch, Like I'm thinking like day picker, Like you can even go crazier than that, right, you can
go into like charts and graphs and grids, and it's all yeah, tables exactly. So I'm curious if there's a line where like you would say like, Okay, this is too complex, and then at that point, would you like wrap some other library out there and sort of like Chris and that is like this is the standard solution we use for this or would you just leave that up to like individual apps. I'm curious how you'd handle that sort of scenario.
Yeah, I think it really needs to be kind of a breakdown of what again, what you need that might be different. I think there's no value in reinventing the wheel. You know, D three is a great library that exists for charting. There's no need to remake D three in your component library, right.
And I also think it's totally fair game to import it into your library and customize the bits that you need and make sure that it's only being used in specific ways that reflect the needs of your application, right. And I think that can even be really helpful rather than just giving someone free ran Like we use this charting library, here's twenty million charts that you can choose from, twenty million different ways that you can present the same data.
The component library can help you narrow that down. Okay, in this case, we use a barograph. In this case we use a high chart, and it kind of removes that mental lift I guess, which would really be.
Tangent.
I think that would really be the primary benefit of a component library if I had to, like really sum it up, give you the elevator pitch on why you should make one. It's that it removes so much of that design decision making fatigue that you do over and over in terms of do I need this, does it need to look this way? What styles does it need? What's the best solution for this?
You can make that decision once and then pull that component over and over and over again and know that it's been thoughtfully created and I can just trust that it's the right choice.
That's a good point, because it's you just tell a bunch of people, yeah, go google react chart and see what happens. Right, You're gonna everybody's going to come back with wildly different ideas of what to do, and you'll end up with the same situation as the header. Right, everybody's got different ideas for what's best and what we're using, and it'll be chaos.
Yep, No, there's just as much value in my last place. We had no real illustrator on the team and no real person whose passion was making icons. So we chose an icon SPT and we built it.
Into a component library, and you said, this is what we use if you're building components, if you're using it elsewhere, we use in that case found awesome, you know, and that that narrows down that feeling of I need to go find something, or having icons from twenty different sets scattered across the application. Yeah, it's done. You don't have to think about it.
If taking that approach, do you run into any issues like getting dependencies to match up? Like so I'm imagining you have like five apps using your component library, right and you're like, oh, app one needs a new version of found awesome. Then does that sort of imply then the net So then the other four apps right when they go upgrade, they're going to need to pick up the new version has And I could see that going
both ways. That's kind of curious, Like I could see that being like a forcing function of keeping people up to data and dependencies, but I could also see it being like a blocker, like oh, we need to update something, but we don't want to have to test the new fun, awesome version for everything too, So I'm curious what your experience has been with that.
Yeah, it can definitely be a little bit of a roadblocker. I'm maybe lucky that I haven't quite been in a situation where I have to manage five I think that most have done is two or three different applications playing from the same component library, and it was a real motivator for us to keep everything as up to date
as possible. But it did also mean that there were some things that we didn't update in the library because we didn't want to mess things up in the application, and there was a little bit I think it's honestly just the same way that you judge whether you need the update in the application itself. You look at it and you say, what does it offer for other features that are in this release that are really important for us, that make the effort of jumping up a version or
you know, five or ten worth it. And eventually you get to the point where you need to and it's important, and you make the time and you make it happen. But it's really just a question of version management in the same way that you version manage every other dependency. I think in your app. It just kind of has that trickle down effect. Like you've talked about, you're really
doing version management in two apps. But I think the decision making progress process in terms of when do I do it, is it worth it, it's more or less the same. So you've talked about some really interesting stuff that you're doing at work. Is there anything that you're working on on the side that is equally exciting to you?
I find equally exciting if anyone else of actually in the process of building a web application called bubble up that's intended to help COVID nineteen social bubbles coordinate their
kind of activities and share information with each other. So the hope is that you know, in an ideal situation, you say that people in your bubble or your pod or your quarantine, whatever you're calling it, don't ever interact with people outside of that, But the reality of that is much more complicated, and that there will always be exceptions that come up, and rather than pretending they don't happen, I'd love to be able to build those into the
planning process as a realistic way for people to still be able to meet up and do so safely, and do so honestly and kind of put all of that communication into one hub. So that's my current that's my current work in progress. I'm hoping for an end of year launch on that.
So is there like beta test going on right now or are you looking for help? Like as an open source type of project, it's currently a bit of a one man show. I am definitely open to folks that would like to help if they're interested. I have a user survey up right now, trying to get a feel for what features are important to people, making sure that we prioritize development in that way. You can find that
at bubbleupapp dot com. It's also wait list, a mailing list that you can join, and we'll keep folks informed when we are ready to start doing some beta testing, when we're ready to start doing some some just kind of general user click testing. The UX person and me won't launch an app without that, and of course when we release properly, that's awesome. That's such a I mean, not only such a good side project to learn in, but also such a potentially useful one. Are you are
you building it with React? I am building it and React The major question. No, I'm definitely the job I'm in now is an Angular, but I think my heart will always be with React personally. I started off an Angular and I am much happier building almost exclusively and React.
So I feel you, at the end of the day, they're all just tools in the toolbox, but I think it's also totally fair to have favorites.
Curious too, do you find like the React to me like because you build component libraries in both as well? Right, are there any differences like specific to component building that make you prefer one or the other.
Hmm, that's interesting. I'm not sure. Trying to think through React seems a little bit more intrinsically built to kind of handle that component style breakdown. Angular does too, so it's definitely not, you know, a roadblock, But I think the way in which you kind of learn React and things are, at least the way I was taught to kind of break things down into components and components really
modular is a really good fit. I'll also say that a lot because React is is UI focused and not you know, full framework no way that Angler is, it can be a little simpler. You kind of have narrowed your focus a little bit, and a lot of the tools that are out there for building component libraries tend
to be a little more React focused. I've run into that a little bit with Storybook, which again is great, I've used it for both, but a lot of the documentation, a lot of the examples are going to be targeted towards folks coding and React. There's been a little bit of a bumpy road to kind of figure out how exactly that translates. Well, Catherine, it's been a pleasure talking to you. Is is there anything that we have not talked about that you think that we should I don't think so.
Trying to like, I mean, I've pulled up the discussion points and noother thing.
It's like, was there anything? I don't think so.
I feel like I could talk about component libraries for hours, but I doubt.
That's what you want. So no, I think this has really been interesting. That kind of makes me want to revisit my own team's decision to use AUNT. But oh man, we're already really committed to it, So I probably shouldn't open that can of worms. I don't know. It's a fun can. So if people want to get in touch with you or learn more about you, how where can they find you. You can visit my personal website, Kagreyson dot com. I'm also on Twitter perhaps too. On Twitter
also at Captain Grayson. Was there probably the best race? Awesome? Okay, so now it's time to move into our picks for the show, and this is when we talk about cool websites. We've found things, we've been using, TV shows we've been watching, really anything. So TJ, would you like to start us off this week? Sure?
So I've been I've an app recommended to me called Strava. I don't know if either of you've heard this before, but it's it's almost like almost like a social network for exercise things like runs and bikes and stuff like that. And I'm far from like an elite athletes, Like I get my bike out twice a week so and I
consider that a victory. But the kind of fun thing I found about it is since it encourages like social stuff, it's a way of me keeping up with people that I don't see in my life anymore, right, like coworkers that I'm not seeing. It's just like another way and it's outside of like you know, as discussed like I'm sometimes too much on Twitter also and it's kind of fun to just take that out of the equation and just have a fun little thing to see what your friends are up to.
So that's my pick. Very cool. That sounds like a great way to stay more active, too, which is something I've definitely been struggling with since the pandemic and my gym shut down and that I didn't feel comfortable going back to the gym after that, so that's good. My pick today will be a standing desk that I just bought last weekend and am very already very excited about. It's called the Tresante or Trasanti, and it is from Costco, although I believe that you can buy it on Amazon
and possibly Wayfair also. But it is an adjustable height desk. It is a powered one, so you just it's got like three different settings that you can pre set for you know, however, whatever your preferred height of working is. It's been really really cool so far, and it's it was only three hundred dollars, which is way less expensive than most of the other powered or unpowered desks I've seen, so I am a big fan of it and I would highly recommend it. It's not too large, it's not
too small. It's pretty great. I would definitely recommend checking it out if you have a cost co membership and you need like a real space, because up until this point I was working at the dining room table, and after seven months of that, it seemed like it was probably an investment worth my tie. So that's going to be my pick for today. Catherine, do you have any picks? I know this is a little last minute for you.
My pick would be Notion, which is probably a familiar platform for some folks, but just in case, through one of the two people that have never heard of it. As someone who is currently managing my own personal life and building an app and building a component library twenty million other things, I've created Notion databases for all of those, and I feel like I'm pretty much living out of
that app now. I've got, yeah, one for the app and one for like family recipes that we're all sharing, and one for just personal things to do list my calendar. I feel like if if I didn't have somewhere, I could doulp my brain lose all of that. Notion has been just a lifesaver in that regard.
I'm one of the two people that hadn't heard of it, so maybe the other person is listening here. I'll have to check this out because I'm currently my life revolves around one single text file that I keep on my laptop, which I mean works better than you might think, but it doesn't scale the greatest.
Going to say that just gave me a little bit of anxiety.
Mary about It's okay. I have sections to it like. It's not pure chaos.
Mine's more of the disorganized. I have some notes on my phone, I have some notes on my laptop. I've got a Google doc, I've got Google Keep, I've got stuff everywhere, but no centralized system for where anything goes.
Really can I make a second pick? Actually, because that propped it us. Yeah. Something I recently picked up is a product called Rocketbook, and it's basically a reusable notebook and you can troll on it.
You've got special pens. It actually feels a lot like paper versus some of the ones that feel like dryaries. But the cool part is it's got an app with it, and it comes with like a little QR code in the bottom of corner and it'll scan it and automatically upload to wherever you have set things to go. Some
mine go to like my dropbox. It's been really great for wire framing, especially which I like to do on paper because I don't know evidently eighty so I like to draw anything out on paper freation and then upload it and then I'll have to sit and you know, actually make a real wireframe out of it and design software. And being able to skip that like awkward scanning or like photo taking with my iPhone face of it has
been super nice. No, that's awesome. I'll have to check that out because I'm kind of the same as you. If I am trying to design something, I just really like to do it on a piece of scratch paper and then yeah, I'll end up hauling that around with me everywhere until I've finally gotten it designed.
I'm sort of fascinated by this. I'm just looking at the pictures and videos of it on the site. It amazes me how far the technology for this has come. Like even like back in our office, back when offices where a thing like we had some stuff like similar not quite like this, but like a whiteboard that was like you said, it's not like technologies come beyond dry erase, which sort of fascinates me, Like there's stuff that actually like comes off and doesn't leave marks till the end
of time. So it's kind of cool that I didn't realize you could get this in a book that's like individual thing you can take around with you.
Yeah, jig, but it's like my poor man's iPad. I could probably accomplish similar with like an iPad and apple pencil, but this was, you know, a couple hundred dollars cheaper. It seems like it'd be a lot less distracting as well, because the iPad is as bad as my phone. Honestly, that's true. And you do get that feeling of drawing on paper instead of drying on a screen, which, again, I know I sound like very old fashioned, but it does make a difference I think totally. Well, Catherine, thanks
again for having us on. It's been a real pleasure to talk to you today. Thanks very much for inviting me. Had a great time. Alrighty, so we've talked about how to get in touch with you, so I guess we will see everybody on the next episode of React Round Up.