 Hi everybody. I'm going to talk about how we, for the past year, created several libraries of short components for Client I've been working on. I'm working with. First, let me introduce myself. So, hi. I'm Xavier Lefebvre. I'm French. I live in Paris. I'm a team leader on React and React Native Projects for a company called BAM, indeed. Overall, it's a consulting and development agency. We work for any type of companies to accompany them to build some successful products. And so, as any of you in this room, I do love tech as much as I love traveling. So, being there with you today is quite nice. It's like quite an amazing opportunity to go to India. And like that. Good. You're less going to hear the breathing. Now it's good. Like that. Do you hear me well? Yeah? No, no. Okay. Thank you. And I do also love, among other things, motorcycles. But why do I put motorcycles here? Because I have this little image of a motorcycle and all its components. And it made me think of that. What we're doing is a little bit of that, because it's like many different components with different sizes, with different responsibilities and scope that we need to assemble together to make a website. Or to make several websites. And depending on the motorcycle, some components can be reused on other websites. So, what I'm going to talk about, I'm going to talk about why we started this project of shared components and how we tried to tackle this topic. Then I'm going to deep dive in some of our design decisions that helped us make this a success. And at the end, I'm going to tell you, it's a little bit of a business part. I'm going to tell you how we consider that we're making it a success. And how we organize ourselves to tackle the issues that other teams or our teams meet while developing on this project. So, it started from a wish last year. Our client, which is a big bank, said, it would be awesome if we could finally and successfully, because we already tried. Create shareable components in order to read them on different apps, give them to other departments or even one day, potentially, sell them outside. We didn't reach this place yet. We're approaching, give them to other departments. So, why did they say that? It's been a long time we worked with this client, and we developed a lot of different websites over the past seven years. And it happened quite some time that we redeveloped the same kind of features. Slightly different, but in the business of the bank is always the same behind. And so some features can be accessed, could be reused and are reused effectively on websites which have a different user target. So, let's see a little bit what I mean by that. So, that's an example. That's an example of one of those features. It's a full page feature. It's called a fan sheet, a fan being like a source of money that's used to be invested. And it's part of life insurance, for instance. And this specific feature, it's a full detail of the fan. So, it can be interesting, and it is interesting for B2B, for internal purposes or B2C. And this fan sheet has been, for instance, made several times for different websites. So, our first attempt, which was named Commando. So, the setup is a team is working on one website, another team is working on another, but they have to share a component. There is something there that they could reuse. So, what we did is we created out of the blue like that a command code base which was called Commando, and both teams were contributing. From that, we output a simple, huge JS bundle that was served directly as a script, which was directly downloaded by the website. The problem was that the code base was growing without specific architecture. So, a lot of components really didn't follow the same syntax or the same architecture. The JS bundle was huge, same, just one for every purpose. And in the end, at this time, there was no versioning strategy. So, if you had, if you pushed a new version with breaking changes, you could be pretty sure it would break your website. So, after that, of course, it didn't work out, we ditched it. After that, a second project was called Tapas, which is, I don't know if you know about Tapas, which is like a little Chinese dish, food that's meant to be shared. So, same setup at the beginning, but this time, one team started to own the project. So, they were the one taking care of its architecture and its improvement. Or the other team, for instance, team two or more, were contributing to the project directly. Then, this time, we versioned, of course, our JS bundle on GitHub directly, and we packaged them. So, they could bring it directly into their code base before bundling the final website. It still had some issues. First issue is, once again, the first team, the team one, but first and main objective was to take care of its own website. So, they didn't really think enough in terms of reusability, and they didn't really have this focus. Second one being that, once again, it was a big JS bundle. So, any type of components, even if you didn't use, need them. You had to bring them into your final bundle. And last one is that the versioning system was on GitHub. So, you needed a GitHub account to be accessed to our private GitHub team to be able to access them. So, it was clearly not perfect. And there were solutions for all of that, but we didn't, at this time, try to use them properly. So, last attempt, last year, at the moment where our client said the quote I told you, we launched this project which is called Component Studio. Same setup at the beginning. So, this time, with a specific core team, like you would have for any open source project. And other team contributing. After that, we created and split architecture in several libraries. And same at the end. We packaged it in order to be reused on the host projects, on the websites. But this time, for each of the solutions, we, for you, for managing several libraries into one repository, we use Lerna, which you might know, which is a mono repository manager. And for giving our packages to our users, we used Verdacho, which is a private NPM open source. And this made a big, big difference. Thanks to this, we can say, and I'm going to give you a proof at the end, that it works. So, that's a demonstration of what we have right now in our project of reusable components. It's, we use Storybook. It's our basis of development, of validation, and it's our showcase as well. Everything is accessible from there. So, a developer, when he's going to develop, he's going to develop, thinking, even though it is from another team and he needs to contribute, he's going to develop thinking about reusability because he's going to develop directly inside of Storybook. Apart from his own project. Storybook is extremely convenient in order to, to, to play around with your components. You have the knobs, so it's a props of your component. You can play around with them and see the impact it has in live. And, and it's also used for our own product owners to validate and to, to show what the capability and what the components are available in, in our project. So, let's, let's dive in for some tips of what we think made the difference. So, if we can, if we come back to this, this part of the, of the, of the diagram. First, I want to, I want to dive in a little bit into how we organize our packages and components. Then let's dive in a little bit more into our code structure of each of those components. And finally, how we limit the impact of breaking changes because it's a project for instance, there is six other teams working with us on the daily basis and pulling, pulling requests of changes on the, on the code base. So we are not capable as a core team to, to check all of them. The thing is that we want to be agile and go fast. And so we, we had to set up an automated process, a strong process and with, with formation to, to, to make it work well. So first, how we, we cut down our packages and components. We follow our atomic design. So I don't know if you, if you know about the atomic design principles. It's a, it's Brad Ford who, who created those principles. And it's, it's, it explains you how to cut your UI components in, in a hierarchy. So the, the biggest one, I'm starting to start by the biggest one. It's called in our, in our case, we used the organism as the biggest one, which is almost a full feature. They're a full page feature. Then inside you have the molecules. A molecule can be composed in order to make an organism, of course. And then you have the atom, which is a simple UI component. So let, let me come back to that. The impact it has on our code organization. So UI, as I just told you, as you've seen before, it's an atom. It's pure UI. There is no business in it. So this is the party you would expect in a design system like material UI, for instance. It's completely customizable and composable. Then what comes next? We called it widgets. It's business connected directly this time. It's, it still has a pretty, a pretty small shape and it's composable when it shares a common business purpose. So for instance, I was talking about funds. Funds, it's a specific business data. So all the widgets about funds can be composed together to make a bigger product. And at the end, you have the organisms, for instance, the friendship I told you, or, or chatbot. So that's the advantage. And they're full page features and they do satisfy by themselves a user need. So a friendship is a composition of widgets. But we also, for instance, have a chatbot and this chatbot needs to answer some, some questions about funds. So directly, the chatbot is going to retrieve those widgets and display them as, as it would have done it with a friendship. Let's take a deeper look at the code now of each of those parts. So that's, that's impossible to read. So let's, let's go a little bit in it. At the bottom, so you have the UI UI is pretty simple. There is not, not a lot to say about that. You have a component, you have its style. So it's not connected, so you don't have much more. And we do have a theme, a theme setup and feature. I didn't, I'm not going to talk about it now because I'm not going to have the time, but I would love to talk about that later if you're, if you're interested. After that, so you have our widget, our widget on the, on the right of it, you see it's called components. So this is the UI place. This is where you have your JSX. It's a composition of UI components, mainly that's being fed with data from a container, which is, which is classical. The container is going to fetch this data from a service that we created in order to, to optimize composition of widgets at the, at the, at the organism level. And it's, it's using what we call a modellizer, which is an adapter of the data that comes from the back in order to, to, to just to clean it and to, and to have calculated the, calculated the variables if necessary. So this, this widget, we export it in three ways. As a standalone. So you just take it, you put it inside of your website, even if you don't have reactive work, it can work and it displays, it displays directly the data. It fetches it, it closes it, of course, and it displays it without you thinking. And we export it in two, two separate pieces as well as a dump component without any data and the, the data fetching service by itself for you to be able to recompose it from the top. So for instance, the friendship, an organism is composed on the, on the right side, as you can see with the purple of widgets and of UI components on the left part, because our stack, our stack of our website is made of Redux. We decided directly inside of those, of those organisms to, to put Redux. So in order for the, for the, for the host projects to be able to embed the store of this product in case, for example, inside of their own, to do optimization, not have to call twice the same, the same, the same data or reuse it somewhere else in the, in the application, if the data is already available. And this Redux store is using our fetch widget data service to be able to, to, to get the data that is necessary for the widgets you're using. So now I wanted to, to, to dive a little bit into breaking changes because it's an interesting topic and even more for us that any team member, any outside team member can, can do a request, merge its code in its own, with its own team directly. So there is a risk of, high risk of breaking changes because if they change something that another team is working on and without communication, it can be, it can be problematic. So breaking change just for reminder is a change in one part of a software system that causes other parts to fail, which happens when you change the existing API of, of libraries without one user even, of course, even more. And what should I pay attention to? So for instance, your, we expose components, we expose some functions, but mainly we expose components. So the signature of your components, if you change it, if you delete some, some parts, some props, for sure you're going to have issues. So the exposed components and function names are their props or the function parameters. That's part of, of the potential breaking changes you could make. The component style as well. So it's, it's the style by itself. So I don't know if you change a color or a font. It's, it's, it is somehow a soft breaking change because it's still going to have an impact for the end user. It's not going to break your site, but at least if you change a font, it might be real. But beyond that, the space it takes in terms of height, weight or margin is, is might funds in this case might break a website. So this is part as well on the, on the little things we need to, to pay attention to when we talk about breaking changes. And last part, when we break the peer dependency, which has a breaking change, for sure the whole project we will have, normally we'll have to, to update this peer dependency, but we'll have to pay attention to the same breaking changes. So you need to warn them. The example here being for instance, style components. We do use style components to develop, to, to take out the style of our components. And you can, it's a peer dependency because you can only have one version running on your code. So if they, if they push a new version with breaking changes, we will have to make sure that our host projects use the same version and fix the same problem with the same type of breaking changes. What we set up to help developers anticipate. We use flow. It could work with TypeScript in our whole code. And we expose in the same way as Flowtyped, our API with Flowtypes connected directly. That's, that's a nice advantage because Flowtyped is really, is, is connected completely to the, to the base project it's supposed to type. It's very, we, we provide directly the types with our libraries. So they're connected directly. So if a developer changes the signature of a component, changes its props, it's going to break in his ID because he's not going to have changed the exposed Flow API. So then it's going to break, he's going to need to change it. He doesn't have a choice. The CI will be read. He's going to, he's going to adapt his, his Flowtype API. And if he didn't pay attention, his pull request will directly, thanks to dangers that runs in the CI, tell him that he changed a Flow API file and that it might mean breaking change. So he needs to pay attention. And it did help us in some cases to, to anticipate breaking changes. There is also an automatic semantic versioning system based on the commits, like was mentioned a little bit earlier in another, in another talk. And so when the developer knows he's making a breaking change, he's capable of seeing it directly at the commit level. And he's going to be, it's going to create a major directly. So people know that if, if there is a major to bump, there is potentially a breaking change. And thanks to that, at the same time, there is an automatic change log generation with all the details directly coming from the commits, using commitism. So how do we know that such a project is successful? The little business part I think is interesting for, for all of us, because even as, as tech people, we need to be able to potentially find a way on the, on the speech to convince business managers to do such, such kind of projects. So our return on this investment formula is, is quite simple. It's for sure, improvable. It's the same for all components we expose. Of the cost it would have, if it was redone on a normal project, times the number of times this component has been reused. And to this, we subtract our project by itself, full cost, our team, but even the time that the contributors spend to contribute. So as a tech team, our main focus is on the right part. It's not on the left part. The left part is the sales part. It's the fact that you find, you find people to reuse your components. It's mainly on the right part is to reduce the project cost, meaning that it needs to be faster and easier and more robust to develop on this website with less, with as many as, as, as a few bugs as possible. But we did not arrive to this point after a year without struggling. So what we did, we started tracking the issues, like the issues we would have on a GitHub repository. That's pretty complex graph, yeah, of our issues. So at the bottom of the bar, you can see that all the issues, it's orange plus red, all the issues that were made, for instance, for by the other teams that they wanted to share with us. And on the blue, it's a contribution. So it's activity on the repository. It's to see if there is correlation between the number of issues and the activity we have. So there is a correlation, for sure. We can see that at the middle on the number four, we did, before that, set up enough actions and positive, positive tools and, and, yeah, improvements on our code base to, to, to have a flat number of issues, even though the activity was, was a little bit increasing at that, at that time. Why did it increase three times? We discovered lately that it was mainly because there is a lot of turnover, because we're an agency. So the developers, there is a lot of turnover in the developers. And each time that there is an increase in issue, it's mainly because our new developers coming on our project and they didn't know all our flow and how it worked because it's quite, it's quite dense. So with these issues, with this graph, we started tackling them. How did we organize ourselves? So first, every day, like, like, without missing a day, we would take at least an hour to take a look at the ongoing actions of some, some fixes we wanted to set up to make sure that it was on track. We then prioritized based on the type of issue. So if it's a bug, it's more important than if a developer just was blocked for five minutes. And the developers lost time. So thanks to this prioritization, we are capable of then tackling the most important ones every day. And going to the, into the depths of each issue and to the root causes to understand exactly what's in the flow, which can be the training of the developer. It can be that potentially it's meeting, it's, it's missing a little tool to, to, to allow, to prevent him from doing a mistake to, to do. And then every week, we took weekly actions to make sure that in our, in our development flow normal, we, to make sure that those biggest root causes, as we call them, wouldn't come back. So this is an example of, of our diagram of our graph of, of main root causes. And the top one, for instance, lately is we have a lot of issues with YarnLink. It's like, I don't know if you know YarnLink, you connect your, your own library to a host project to see directly the impact it has live on your host projects. So it's, it's useful if you want, for instance, so you're, you're developing a website and you're using a library, but something doesn't work well or you want to improve it and see the impact it has on your website, you use YarnLink. So is it worth it to do such, such a project? We consider, thanks to the little formula you saw before, that really we saved 18% of development costs for those projects since almost a year ago. So for us, this alone is enough to tell us that it's worth it and we're going to continue. And a second side effect that, that rise naturally was the fact that it's, it created a consistent UI, UI, UI, UI design across all the platforms. That was not always the case because each team was separate. You don't really enough talk to each other and organize themselves well to have a consistent UI. Now that they shared a common base of, of components of any size of components, the UX team at the same time had to, to start synchronizing themselves by even more. So first it is a success and we're going to continue in the, in the coming year. That's it. That's it for me. And I wanted to thank the people that worked on this project because it's not, I wouldn't be here if, if we didn't do that all together. Yeah. Yeah, we have, we have one here. Micronus. Okay. So I wanted to know how you guys are managing the versions of the component for the library. So suppose a team A, uh, suppose you have a component in library, tap component, which is an internal component. And team A is using version 0.5. And there are some bugs and something like that in that component. You fixed it and you expose the new version or whatever. So are you asking all other teams to upgrade their components in their project best or what, how you guys are managing that? Yeah. For the, for the moment, it's like, it's really an internal company project. So all the teams, we're not that far from each other. So we do have a WhatsApp chat and we do, we, we, we do give news when, when something is changing, but we're not, we're not obliging anyone, no one to, to upgrade. They do as they wish, like they would for a normal library. So, so we, we trust them in making the right decision based on, on what we, we change and what we improve if they see the value in it, because they have to prioritize their own development roadmap as well. Okay. So on a second question, when you ask your other teams or other products, let's say application team A or two, what you say. So you guys are exposing it through some gate directory or you are creating an NPM bundle for that. Or okay. So you guys are creating NPM bundle. I didn't want to put this. Yeah. This one is huge. But yeah, we do. Is it, is it, is it, uh, yeah, on the right side, you can see the, the little vids, it's Verdatio. So Verdatio, it's, uh, it's a private NPM. So it means that we, uh, we, we each, each package is, is pushed on this Verdatio. It's really like NPM. And then the other teams, when I need to, to take the latest updates, they do a yarn, yarn add, uh, the name of the thing with the right, the right, uh, number, the right version. Hi. So when I'm writing my code as components, I always get, uh, confused about, for example, if I have a component that takes some text and renders it with the box shadow and with some font color and all those things, I'm always confused about how much customizability should I expose on props for that component? Should the box shadow be also customizable? How much of the styling should be customizable? So how do you guys look at this problem of when you build components? How much is, uh, inherent to the component and how much can be custom customized using props? Okay. Um, what do I have there? No, no, no, no. I didn't put it there. Um, I was expecting a diagram. I don't, I don't have, um, how we do that. So there is those three layers. There is UI. There is a, so we call it UI, which are the atoms. There is a molecule and then there is organisms for the, for the atoms. We consider that. So first, first, of course, they're already compliant with the UI, UI design of the company at first. So most of the time, this is going to be enough for the, for the, for the other projects. But then as the really simple components, we allow, um, full, full, uh, customizability of the component by itself for the other teams. They can do whatever they want with it. We expose, we expose most of the, of the style. We use a specific themes, uh, system we did by ourselves with style components. Um, then at a, at a higher level, when you go through the molecules and the organisms here, it's different for, for instance, because we don't want it's, it would be too customizable and too complex and too crazy after to, to, to anticipate some breaking changes. So here we do a lot of some stuff, but based on what was really necessary, based on the, on the, on the questions that those team asked us in terms of improvements they wanted to make in the style. So it's mainly, it's mainly like color, color of text or font, um, and sizes, sizes of them, of the components, for instance. And it doesn't go further than that. We want to set the style at the same time that, as I told you, it does set the, the UI, the UX for all of those projects. And it's a good thing. Uh, one, one second, please, uh, please do not leave the auditorium till the QA is done because we have few announcements to be done. All right. Yeah. Next question, please. Hello. Yeah. Thanks. Thanks for the presentation. It was a nice one. So, uh, how do you tackle the inter, uh, these components, communication that you guys are doing? What's the strategy that you guys followed for that? The communication between these components when they communicate or if, if there, if there is a communication happening between these components. Yeah. So here, here, for instance, so the friendship. So that's, that's the little thing I didn't explain here because it would have taken more time. So friendship is made of, of widgets of different widgets that are supposed to be connected indeed. Uh, and the, the fight, how our backend is done is that it's one route, when huge route that, that gives all the necessary data data to create a friendship. So of course here you wouldn't want to have to, if you call 10 widgets, you wouldn't want to, to make 10 calls to the same route. So that's what was that way we created. And it's pretty, it's pretty raw and straightforward. We created a full service with all the, all the, the widgets that compose a friendship in it. And, um, for, and this service, when you reuse it, you call it and you give it the name of the widgets you're composing with. Okay. And it's, it's going to, for you make the call with the right parameters. And the difference is there is several routes. There is four routes in total. There is some other stuff I didn't mention. And it's going to, you're not going to have to think about that. It's going to put this, all the data properly with the modellizers I told you, so the adapters for each widget inside of a, of an output object with the name of the widget and the data it needs to, to, to get to properly get displayed. And, and then you just have to reduce the connection. So you don't, you don't care at all yourself at least about how it works inside. But then if you want to create a new widget, it's, it's another problem is way more complicated because it's, it's like a big function with a lot of if else. Yeah. Next question. Hey, Anand here. So, uh, of course, uh, nice presentation and we asked about the versioning and all right. So someone asked from there about versioning. So, so it's like you are, uh, managing monodepo and how you are actually building these components because you are having atomic molecules and organism, right? So you might have different build process for these components and how extensibility is working for these components. You think that they might have different build process. I'm talking about like what build process approach you have taken, uh, for these components. And suppose I need to tweak a bit of, you know, the, so for example, I take one atomic component and I want to write something on top of that, right? Which might not be the part of that repo like atomic component, but I want something to be changed. So how to extension is going to work for those components where I'm trying to use it. So I don't know if it's, I'm going to answer your question. You tell me, right? I think you put it there. Did I, did I not? I did. So we have, we have a, it's, it's a tree. You cannot, I'm sorry, you cannot see it well. I'm going to tell you. It's a, it's a tree. It's a decision tree that we, we gave to all the peers, the product owners and the developers, uh, for them to be able to make the right decision before making any change inside of the, of the project. And the first, the first step is to make sure that the change they want to make can be a change on something that already exists or it can be a new feature. It has, they have to prove that it's going to be reused by another team. If they make a change directly to a component that's not going to be reused, we tell them to, to customize it directly or extend it directly on their own project. First, if they do prove that, then they need to make sure that the UX UI is compliant and validate it with the UX UI once again. So for this whole UX UI, uh, um, working together well. And then last step, it's a technical step and we do, uh, workshop with them of like, it depends on the complexity of one hour to ours to, uh, to understand where we're going to fit this feature on architecture to, to put it at the right place. All right. So, and what about the server side rendering? Like, uh, how you guys are way we didn't, we didn't, we didn't for the moment. It's pure SPA. It's a good question, but we didn't tackle that yet. Yeah. Next question. Mentioned a tool that you use in production for monitoring. I was unable to catch the name of that tool. Can you talk more about that? A tool for what? What was it? It's a for monitoring your production issues. Yeah. Issues. You use a tool. We use the handmade tool with Google spreadsheets and Google scripts. And it's working pretty well. So all the issues they're shared on it. We use Trello a lot, Trello boards a lot. Our development process is on Trello board, but our, and it's some specific from my company are solving process, issue solving process is also on Trello on another board. So when a team has an issue, they create a card with a specific template inside of the Trello board at the beginning of the flow of, of resolution. And we connected directly Google script to the API of Trello to be able to get the right data and to, to, to show it this way.