Components, Patterns and sh*t it’s Hard to Deal with

Hi, everyone. It's a bit awkward because, again, you might hear from everyone on this stage and other stage that we haven't been in front of people for a couple of years now. It's freaking daunting to be, again, on a stage and in front of people. But none of the other speakers asked to speak after Max. That adds up to the stress, to be honest. But luckily, I have a topic that is completely different from his, so that kind of put me in a different ballpark, completely.

So this talk comes from a long way, as well. Max was 2018. Mine is a little further back. You'll see it in a minute. And it all started when I wanted to talk about modular architectures. So that building, if you're asking me, since last time I was at a conference, someone asked and I didn't know the answer. It's called Habitat 67 and is in Montreal. Anyway, I wanted to talk about modular architecture and I was trying to wrap my head around what to say about it, because modular architecture has been something that I've seen recurring in a lot of different jobs I had in the last few years and no one actually got it right. Well, not a company that I was in anyway. It is difficult. And then, while I was talking about the problem that I was trying to look at, I ended up looking at components and classes. So that was where my mind went. Calling a talk classes and components is not really fashionable nowadays, though. So it's like I need a marketing spin on it. Components and modifier, but that sounds very 2012 as an approach. Did every one of you work with a BEM-like approach in your career at some point? Writing CSS and components that way? Yeah, so it's fairly old. It's not something you would do nowadays, maybe. I mean, you might be, but it's not super appealing.

And anyway, the problem wasn't much the components and the modifiers. It was more about the overrides. Like, when it doesn't work. Like when we have to do something to undo what we abstracted, or generalized, anyway. And again, trying to get my head around it, I ended up talking about components, patterns, and shit is hard to deal with. Because this is really what I want to talk about.

So my name is Marco Chedero. I used to be a webmaster. I used to be a webmaster way before it was cool. And I'm now an engineering manager in PhotoBox. We are hiring, by the way. If you're interested.

You might notice that I'm an engineering manager. So I'm kind of disconnected a bit from day-to-day of front-end development nowadays. But I still have an opinion, and here I am.

So patterns, components, and shit it's hard to deal with or I came up with a good use of quotes from Lost in Translation. Who of you have seen the movie Lost in Translation from Sofia Coppola? Okay. A few. Did you like it? Yeah? Okay, a few. Okay. So Lost in Translation, in case you don't know it, is a movie while Bill Murray and Scarlett Johansson are getting into a non-romantic relationship while they are on a trip to Japan. It's a middle-aged man shooting a commercial for a whiskey. She's a young woman married to a, no sorry. She's a girlfriend of a photographer that is doing a shooting in Japan, and they have a lot of free time, and a lot of jet lag. And they start this non-romantic relationship talking about his middle-age crisis and her way of figuring out what to do with her life in her early 20s. So it's a little bit conversational and about finding yourself and your way, your path and whatnot. So this movie brings a lot of different range of opinions from people. I do relate in particular with this one. Sorry for the guys and the girls who loved it. And I do think that my talk, to a point, might leave you with the same feeling. I hope not, but it might. It might. And that's because, as a disclaimer, I'm not going to give you any answers in this talk. I'm going to raise problems to you. I'm going to walk you through some of the ways I frame those problems, and some of the ways those solutions kind of worked or didn't. And then I'm going to leave.

And that's it. So that's that. So, everything, no really, Lost In Translation starts from a comment from Alla Kolmatova a while back. So she said that meaning is complex and often gets lost in translation. Everybody has their own mental model of things. She was talking about design patterns specifically.

So she was talking about creating a visual pattern library for companies, not specifically code components. But I think it kind of represents pretty much how I feel about components in general. It does, so this was an amazing talk she gave a few years back. I think it was 2015 or something. But yeah, like, if you can look it up on YouTube, it should be there somewhere.

So again, as I was saying before, this talk comes from a long way. So 2013. 2013, I just moved to the UK, I'm working in Shazam. We are building stuff with a very unfashionable technologies. So we're doing moustache, some in-house small JavaScript framework when required JS was still a thing. And we use CSS with more CSS really. So we're doing very, again, nowadays unfashionable stuff. And then at some point in 2013, this article came out. Some of you might remember it. And kind of changed the way we looked at design. From that moment on, it revolutionized completely the way people was thinking about how to break down a design and create small units of code and of visual elements called atoms that you would bring together and create molecules and then organisms and templates and pages and put all that together.

And that was the first time some of us from time developers heard about that mindset of creating components. And it was freaking out with technologies that we had at the time. Because we came from a world where PHP would render the old page and you had some CSS sparkled on it, and that was about it. And JQuery on top with the interaction. But that was all you had. There wasn't the concept of small units. It could break down includes and things like that. But it was more thought in the sense of making sense in the server for the PHP blocks to work rather than building up a layout.

So, this changed the way we looked at things. A few years earlier, though, web components were announced. We can say by now that they under delivered a bit. To use an alphamism.

In 2011, when they were announced, they were a promise of a change for web development. We thought we could isolate completely our logic, we could encapsulate our UI, and we could deliver things in complete isolation from the rest of the page. And we were looking forward for it. But we go back a little bit further. Because in the design side of web development, it's not uncommon to have heard about pattern libraries and breaking down the design, even before 2010. So this is a long way coming for componentization for web. Again, most of us experienced it after the article in 2013. But again, it's a long way coming. And that's because, in my opinion, the web became more and more mature and we need more and more abstraction. It's what happened with print. Until we got the movable characters, it was not a mainstream media. And that kind of transition came for web as well. We want portable things. We want 200 developers working on a UI. We don't want a small team of a few, which works pretty well. Don't get me wrong. All the technologies we are creating nowadays, though, are to solve organizational problems, if you think about it. Everything is in the direction that you need less specialization and more people being able to rotate across different technologies. Sorry. I'm digressing. Anyway.

Pattern libraries, what I mean by it, because, again, it's difficult. We get lost in translation. We have different amount of models. I want to specify what I mean. So by pattern libraries, I'm not doing a distinction in this talk about design and code.

I'm talking about a set of components that build your UI. However you frame them. It is something that you have in a tool. It is something that you have in Figma. Wherever you have them. If you have them. But ultimately, it's what you use to declare your UI. Somewhat. Pulling them together. If you code them every single time that there's a new Figma thing and you don't present it in your code, that's fine. It's still a pattern library to me for the purpose of this talk. Sorry. Yes. Apologies.

2013. React got out, and this is the true revolution of components. This is when we actually started doing components properly and in an easier way. This technology changed the approach completely. It took a bit before it became widely used as it is nowadays, of course. It is this moment to me, and that's why I'm in this conference, really, that changed the way we started building things. And, again, of course, then we have other technologies that came out and followed that pattern and announced it. Don't get me wrong. I'm not saying that React is the only solution to it, but this is the first that I remember that actually did that mind shift. So, that is kind of the back story. Sorry. How much time did it take me to go through the back story? Quite a bit.

Let's deep dive in the issue that I want to talk about. So, as Ala was saying in that talk, when you actually try to apply that model approach in your day-to-day, it isn't really that simple. And I have this image in my mind all the time, like when you feel like a kid trying to smash a square into a circle, that's exactly what I'm trying to understand how to not do. So, the issue that I want to target is how do we manage our code to use patterns without making them too rigid for the day-to-day evolution of them, the day-to-day activities.

Or how do we reuse patterns in slightly different use cases? So, this talk is not about React. It's a talk that talks about modularity, it's a talk that talks about the responsibility of modules and how you break them down, how you think about them. All my examples are not in React, and that's on purpose, because I don't want us to get lost into thinking about React specifically as more a broader scope of things. You'll see things that you might be doing in similar ways in React, you'll see things that you might be doing differently in React. But at the core, it's a problem we have in React as well. And all the code that I've shown in the slides is code that I've used in production in one of the jobs I had prior to PhotoBox.

So, the first example, the technical solution to reuse components in slightly different use cases that I've seen and I personally hate, but we'll get to it, is the class name injection. So when you have... Oh, this is a React example. So, when we have a component that disposes a class name prop that you can inject in the underlying children.

A lot of people do it. Don't get me wrong, it's my take that it's bad. It works fairly well for a lot of people. So, this thing allows you to inject a class name, apply the class name to whatever children make sense to this icon button, and you apply your CSS however you want.

There are a few problems I see with this because you have a dedicated, normally a dedicated CSS file, and then you don't know how that interacts with the base of that component. You have custom CSS that gets added to an extension that lives far away from the original base button, and if the base button changes, what happens to this? Like, how does that interact? Maybe this is used only in one place in your website, and you change the base that is used everywhere else, and you break something and you didn't even know about it. Unless you have visual regression. But who does that? I mean, a few people do. But really, in the day to day, do you use it? How many of you do visual regression approval to go live with changes in the UI? Okay, two. That's what I thought. It's expensive. Like, don't get me wrong. It's the right thing to do. It's very expensive to set up and maintain and create a proper build process around that. Like, it's... It's not easy.

On top of that, like, if you have that level of flexibility, you could create things that are not following the patterns that your designer wants. Or maybe your designer made a mistake and they created exceptions that shouldn't be there. Like, there are patterns for a reason. But why is this having different colors for over and active? Is that meaningful semantically? I don't know. It sounds like... It looks like a smudge to me in the code.

So again, it works really well, because it's the most flexible way to extend anything. But the four styles could be written in expected ways and we are creating a lot of variants that are pretty much to the whim of the moment for whoever designed them.

So, another technology is the ad hoc modifiers. I'm sure we use that.

It's when you create a class that is for a very specific use. It's basically masking an ID with a class name. It's interesting, because it keeps the exception into the space of the dialog, in this case, so you still have the context of the change, so you know how the override works in relation to the parent-based component. But they are IDs. They are not classes. How many of them will you have in your website? And, again, this is all real code we add. We were shipping a lot of CSS that was completely pointless to the app, because the game intent, for example, was used only once in a very specific journey for the user, and yet the dialog is CSS, was shipped everywhere. And at the time, we were really deduping CSS. So, it is flexible. It keeps proximity between the extension and the base, but then on the other end of the scale you get that there are a lot of very specific implementation, the file size of the CSS could increase a lot with the news code, and it doesn't really scale up. How many can you add? Which brings me to the specialised patterns, which is actually what we in BAM would say are the appropriate extension of a component, so this is a specific type of dialogue.

It can be used several times, it's not semantically identified to one, it's not an ID, it's a proper class, and it's what you would do as a modifier. This is a normal modifier, it keeps everything in close touch with the original base and has a semantic value that is not an ID masked by a class name. So, it kind of works better in that way.

The patterns and the pattern library gets back to the centre as in you have a few predefined flavours of that basic component that get extended, they're all in the same place and they're used widely across the website. It could drive preemptive abstraction, because you see an exception and you say, OK, this is a new thing I'm going to introduce, and you'll never use it again, making it effectively another ID. But, again, it could drive that. It's anyway not super scalable either. You have only a finite number of those anyway. Again, if you want to translate that to a more reactive world, I wouldn't use class So when you mount them, you know immediately what you're mounting. But you might have used some of these patterns anyway at some point.

So a few things I've seen in the few years, but this was not what I wanted to do when I started writing talk. I told you I don't have any answers. I'm just showing you what we had. So I was stuck. This wasn't what I had in mind. And at this point of the talk, I realized that truly it isn't really that simple. So I went back to the issue, and I tried to redefine it. So this is not much about how do we reuse patterns. It's more like, what am I trying to solve when I create these exceptions? Because this is more interesting. Rather than looking at the technical solution to solve the problem, let's go back to the drawing board. Let's take a deep look at the problem itself.

So I noticed that most of these exception and patterns were related to three things in particular. So the first one was the arrangement with the parent components. So I wanted to make sure that the children component that I wanted to extend somewhat was positioned in a certain way in relation to the parent. And in order to achieve that, another solution could be this. So instead of touching the dialogue, I could make a dialogue that is adapting to the parent size, and the parent component is responsible for applying the constraints in size, for example. So the parent component has the responsibility of defining whatever space the dialogue is adapting to. In this case the dialogue is super generic, it doesn't have to know anything about any type of extension, and the Game Intent page is the one responsible for defining the constraints. Which to a point is really good. Again, the main problem I see with this is that you'll get with a lot of HTML that you wouldn't normally have if you weren't thinking in a component way.

You know, what they called devitis in a non-React conference, this is what leads to that. So yeah, not great. It's a solution, but it's not great. The other thing that we're trying to solve is the space between components. So instead of looking at the parent positioning, it's the sibling positioning. And in this case to me it makes more sense to have helpers, classes that are defined in the pattern library and bring back the thinking there in the design space and have predefined spacing. Again, you might not look at the style here of the CSS specifically. It might be variables in your CSS or whatnot. But ultimately, the point is you're bringing back to the pattern library, thinking about how the distance between items should be and the wide spacing between items should be is not anymore something that you need to solve ad hoc for every single component you have is predefined.

Again, it doesn't scale a huge amount, because the flexibility is not there anymore. Like you have to predefine everything. And it's something that could like if yourself and the designer are not very attentive it could be very quickly stale and not useful anymore and you will end up adding margin and padding again in your CSS. Open components. Okay. So, this is the one I like the most, personally. I think this is the solution for most of the problems. It requires a lot of more attention from an engineering standpoint. It's basically when you define an API for your components. We do that in React all the time. Like, we use the props to do that. But ultimately, here it's done in a CSS, but ultimately it's when you say, okay, this component can take a width and a height for the icon, for example, and I'm going to pass it from outside, and that's it. There is no override. There is nothing specifically that's a prefined behavior of that component. Again, in this case, again, the icon does that. It could be a structure. There are a lot of nice ways of doing it in CSS. There are even better ways in React. Again, the responsibility of being flexible is of the component you're designing, and you need to be attentive to create an API that makes sense for it, and that is consumed by the parent applying the available API. Again, this is what a React component would look like if we did something like that. You can think about how you would do that with style components.

It's a fairly common way of doing things. It does bring back control, and when you see your code, you know immediately what it's looking like. It's not something that is hidden away from you. There is one counter side, which is that, again, it's more complex. It's a slippery slope. I've seen components with ten different prop configuration types. At that point you start asking yourself, how do they interact with each other? It could be weird. You need to be quite strict and not open up everything immediately.

The other thing that to me is more of a semantics question is, if an icon can be whatever size, then what is the point of having a design pattern library? The design pattern library should define those sizes anyway. So, you might want to use variables anyway, not numbers across the board. But in general, I would try to bring back the thinking into how we define patterns before we start opening up our APIs.

Now, does it get easier? At this point in the talk, I'm going to let the movie talk for me. Does it get easier? No. Yes. It gets easier. Oh yeah? Look at you. Thanks. The more you know who you are and what you want, the less you let things upset you. So becoming an engineering manager helped with that. The more you know who you are and what you want, the less you let things upset you. And that, I think, the next sentence is like, I just don't know what I'm supposed to be, which is what Scarlett Johansson answers to that. And I think this is the problem really when it comes to components. We have a need in our company to start communicating with designers better, to start talking the language and to get them to understand our language, creating a shared dictionary to talk about things.

We need to understand how we can understand what they want and convey what we think the meaning of our reception patterns are, because a deception per se is a smell. There are reasons to create exceptions, but every time there's an exception, you should ask yourself is this something that we really need or is it something that again, the designer maybe went on a journey that doesn't fit in the big picture that we're building. And again, don't blame the designers. They know what they're doing most of the time. And sometimes these exceptions make a lot of sense, but just question it. Talk to them. Get to understand what they're building. Get to understand the abstraction they're asking you. Don't go and abstract too early and get involved very early in the design process and give a feedback on what you see. Try to get that relationship with your designers and to work with them closely. Talk to people. Not only the designer. Talk to the stakeholders. Try to understand what you're building. Try to understand the business value and the user value that you're delivering. And remember that. You're not hopeless. That was me.

Thank you. What is it? Oh. All right. I'm a bit long, sorry. You ran a bit over, but that's okay. We can do one question and it's over. So take a seat in my lair. And I will get the list of questions. Which I should have had open. I am a well-prepared real life MC. Not.

A question from Anna. UI can get quite complex, including dynamic styling. The challenge we can face is to make sure it looks like it should. How should we test it? Snapshots are not that great. So this is not an entire talk. It's not an easy question. It is tough. And in my experience, manual testing goes a long way in the UI. I appreciate that it's not always possible and is very difficult when there is a larger state of code. That's why pattern library and code, I think, helps a lot. Because if you make changes to components and you see them on a style book or whatever, it's going to be much, much easier to look at. I agree snapshots are not great. If you rely only on snapshots, something will go wrong. Again, visual detection of changes could help. It's difficult to set up. It's costly to maintain. It's not something I would recommend for any app. There are use cases where it makes sense. There are others where I would be a little wary of introducing it.

Again, in general, again, it's an organizational problem to me. Who is responsible for the UI and across what apps? I would try to talk with your engineering managers and director and see if there's a way of simplifying the flow and the process and the maintainability of things. I do prefer much more vertical teams. So end to end, from database to frontend and have a thin slice of responsibility across that. That simplifies quite a bit, because your domain is then contained to an area for your website. Again, not an easy one, not knowing the context of this question. I'm happy to talk about it after, if you're around.