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 has 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 puts 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, by the way, 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 it's 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 in the companies 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. So 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, shit is hard to deal with. Because this is really what I wanted to talk about. So my name is Marco Cedero. 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 the day to day of
frontend 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 has seen the movie Lost in Translation from Sofia Coppola? Okay, a few. Did you like it? Yeah? Okay, a few. Okay, a few. Okay, so Lost in Translation, in case you don't know it, is a movie where Bill Murray and Scarlett Johansson are getting into a non-romantic relationship while they're on a trip to Japan. It is a middle-aged man shooting a commercial for a whiskey. She's a young woman married to a photographer. 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-aged crisis and her way of figuring out what to do with her life in her early 20s. So it's all a bit conversational and about finding yourself and your way, your path, and whatnot. So this movie raised 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. And that's because, as a disclaimer, I'm not going to give you any answer 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, 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 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. But anyway, 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 were 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 the 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 to do 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. But 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 this is, again, 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. It's 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 mental 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. Is it 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 is 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. So, again, sorry. Yes. Apologies. 2013.
react gets 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. But 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. But 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? Or how do we reuse
patterns in slightly different use cases? Last intersection. 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. So 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 the similar ways in
react. You'll see things that you might be doing differently in
react. But at the core is a problem we have in
react as well. And all the code that I show 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, 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 this. 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 the 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? How does that interact? And 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 don't even know about it. Unless you have visual regression, but who does that? A few people do. But really, in your day to day, do you use... 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. 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. It's not easy. On top of that, 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. There are
patterns for a reason. 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 smelter to me in the code. So again, it works really well, because it's the most flexible way to extend anything. But the full 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. And 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 dialogue 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 then again, they are IDs. They are not classes. Like, you can have... How many of them will you have in your website? And again, this is all real code we had. 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 dialogue 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 a news code. And it doesn't really scale up. How many can you add? Which brings me to the specialized
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's not... It can be used several times. It's not semantically identified to one. It's not an ID. It's a proper class. That is 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 in the center, as in you have a few predefined flavors of that basic component. They 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 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 way, I wouldn't use class names. I would use probably specialized components that are like to mount that and hide the class name or the type behind the hood, 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 I've seen a few things I've seen in the few years, but this was not what I wanted to do when I started writing the talk. I told you I don't have any answer. 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 and let's take a deep look at the problem itself. So I noticed that most of these exceptions 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 dialog, I could make a dialog that is adapting to the parent size and the parent component is responsible to applying the constraints in size, for example. So the parent component has the responsibility of defining whatever space the dialog is adapting to. In this case, the dialog 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. I already said that. 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 a component way. What they call divide-ties in a non-
react conference, this is what leads to that. So yeah, not great. I mean, it's a solution, but it's not great. The other thing, another 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 like 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 that you're bringing back to the pattern library, thinking about how the distance between items should be and the white space in 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. You have to predefine everything. And it's something that could, if yourself and the designer are not very attentive to it, could very quickly be 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. And it requires a lot 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. We use the props to do that. But ultimately... Here it is done in
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 gonna pass it from outside and that's it. There is no override. There is nothing specifically. It's a predefined 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. There is... 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. And you can think about how you would do that with style components. You can think... 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 counterside, which is that... Again, it's more complex. It's a slippery slope. I've seen components with ten different prop configuration types. And at that point you start asking yourself how do they interact with each other? And it could be weird. So, you need to be quite strict and not open up everything immediately. And the other thing that to me is more of a semantic question is if an icon can be whatever size, what's 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 gonna 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's, 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 needs 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 reception, 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 of what we're building? And again, don't blame the designers. They know what they're doing most of the time. And sometimes this exception makes 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... Thank you. All right. I'm a bit long. Sorry. We're a little 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. 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? Snap shots 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 it's very difficult when there is a larger state of code. That's why pattern library in 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 gonna 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 is 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 of your website. Again, not an easy one not knowing the context of this question. I'm happy to talk about it after if you are around. If Anna is around. Well, then you can now vote for the best question for a T-shirt. Anna. Anna. Well, I have a T-shirt for you available. We thank you a lot. We now have a break of 10 minutes. Correct me if I'm wrong. 20 minutes. So there's snacks right outside and some drinks. So see you back in 20 or go to the other track and enjoy the little break.
