How to achieve reusability with React components

Key Takeaways

all right hello everyone i'm alex gregorian i'm a senior director of engineering at walmart labs and uh it was a big crowd coming and i work on the application platform in walmart labs so it's kind of the team that builds the framework that powers the front end experience a lot of the orchestration layers and so this is really about our journey and our journey kind of through migrating to react but more importantly about the reusability aspects um of being able to kind of leverage react components to reuse across different applications different entities and so during we had a transition from kind of this java stack into react the node and uh one of the reasons for that transition was we wanted to really be able to leverage react components and reuse them across the sites different different sites within walmart as well as kind of app teams within and so we ran into lots of challenges kind of different complexities so this is really about our kind of philosophies so we're going to go through kind of the philosophies that we used to uh for our solutions and um kind of go through what solutions we used along with the challenges and and the principles we used to kind of go onto those solutions so the scale that we're talking about is is relatively on large rand so all the solutions might not work for you based on your size based on your needs i'm sure there's other ways to achieve reusability so this is about kind of how we do it in our scale i think we currently have like four or five hundred components um 300 something engineers across like 50 apps so if if you know you have one or two components and a dozen folks i think a lot of our solutions might not pertain to you but hopefully you can at least walk away with some of the guiding principles that we that we used uh for our solutions and uh so we you know this whole talk is about reusability and it's a really key importance for our organization in particular and that's because of kind of the way we're structured and we're structured for productivity and efficiency and what we do is we end up breaking up every almost most pages that are relatively large in scope have their own team dedicated to them and they're they have their own cluster and so they're their own application fundamentally so homepage item page search cart checkout they have their own application on their own cluster with their own team that's focused on building features and capabilities for them so what that means is if we want to share if we want to reuse a component across like homepage and item page it's not like we're sharing across two pages we're actually sharing across two applications so if you take out all the pages at walmart that are larger in scope you know there obviously there's teams that own multiple smaller pages you're really looking at reusing components across tons of tons of apps so if you have something like the carousel and walmart loves the carousel i don't know if you've been to our site but we have a lot of carousels i think at the home page had nine carousels at one point and then we toned it down we're like too many carousels and uh so we have this carousel on the home page and item page and category and all kinds of places and we want to be able to use that across all these places not have to rewrite it over and over again and then you take that and you multiply it by how many entities we have so all of these are different sites as well with their own teams their own components and all of them have carousels too every single one right so you don't want to keep rewriting it so then when you look into other functionality like login well all three of them have a login they all kind of do the same thing they all have carousels they will have carts checkouts item pages so while they look very different we can actually reuse components and the way we use we call this capability kind of multi-tenancy or multi-brand and that's kind of a separate topic of how we go about reusing components and different entities because they have different styling different content and and so i'll just touch upon it but that's kind of one of the really big reasons that we want to use that we want to be able to reuse components and it was such a an important aspect of of our focus and we in our framework that we kind of open source that all of walmart runs on which we call electrode and and that's why you'll see kind of the little alien logo um that's kind of the the key tenants is the ability to reuse components and that's kind of what it's built for and that's the key reasons why we have this this large focus if we even if we have this carousel and we don't reuse it you're gonna have like 20 developers build the same thing across all these different apps and entities um so we let's let's talk about the actual solutions and problems and what we've done that's kind of the context um so we go into the how do you actually reuse code and the technical aspects of actually sharing right you can't copy paste because that's not really reusing it's kind of like forking so the way we go about it is all components are outside the application all components are developed independently outside of the application they're on their own repositories and so we have this we have an organization in github we use github the locally run version and um we have so we have like the react components organization and all components that are developed are not inside the applications there are different repositories within this organization that way you go to one place and you know you can find every component that the company is kind of building all of those components are then published to npm they're all versioned following you know major minor patch and then apps that want to use the component will then npm install them so that's kind of our our method of just using components the and uh so that's kind of like the first basis that's the first thing that you you know that we have to solve is well i want that component and you want the component how would we share it and so this is kind of the the method that we use to kind of go about it and the first thing that happens is managing dependencies as hell right like we're gonna have to manage all these core dependencies um libraries build systems testing linting and if any of them are different in any way the app team can't reuse it and if they can't and if there is any inconsistency in some components versus other components you immediately lose the trust of the different organizations and they might not even try to use it or they might run it and there's like a problem and they'll say whatever i'll just rebuild it and so the consistency aspect is incredibly important and one of the key parts of being able to be consistent is managing all the dependencies so there's one part of managing the dependencies and making sure you know what versions of everything you're using and another part of managing dependencies is how do you upgrade from like react 15.3 to 15.4 across 500 components at once and you know do i really want to send you these 500 pull requests and then you're gonna have to bump them up and and how do we then every team has to kind of look into each component to see what version are they using and it becomes uh very difficult very quickly so we have this up concept that we call archetypes and so if you ever go to the electrode website electro dot io you'll see archetype mentioned a lot and it's kind of the key pieces of of the framework in that the idea behind it is that you have kind of one package that will consume a lot of your other production dependencies and your dev dependencies and that one package is versioned and it's and and so that way you know that if i have you know version five point three point two of the archetype all of them are the same they all have the same core libraries and so if you ever make a change to core library and you were propagated across all the other components um all you need to do is change the archetype and all the other components will get that propagation of depending on if it's a patch and miner and and how they're upgrading and um and so if you want to add a new library change libraries move things around and how you really manage dependencies and how teams have trust and how things are are the consistency of the components is through the archetype so we kind of talked about these the the different entities and they how they have how components you might want a component for walmart to look different from a one component from sam's club and the way we do that is based on the brand that you are the component might build differently it might pull from different css files it might pull from uh kind of different templates it might pull from different content and so the components also have to build consistently and they have to build in a specific way so archetype is really the way to manage hundreds of components uh is the easiest way that that we found and so along with for it to build consistently and for people to prefer to act consistently you also have to be able to kind of generate the component so along with the archetype thinking we also have this ability to generate new components so when you install that archetype you can generate other components they all look the same directory structure is the same and it also solves other problems and and and will kind of continue that um in another area so we so now that we have the ability to reuse technically we have the way to instill consistency so teams have confidence in what they're getting they can use the app we have a way to manage dependencies we have something called a meta team within walmart and what's going to happen is we have a few hundred engineers you need a process to also have kind of cold quality consistency general principled uh consistency in how you build certain things you need and because you're affecting so many people and you're trying to keep so many people consistent you need ambassadors from old other teams because you need to be able to communicate broadly widely you need to be able to discuss changes and so that's where we have this kind of meta team concept come from so we have uh generally a few people from every single team generally the most senior people and these folks dedicate their time to have weekly or bi-weekly calls to discuss things that are kind of coming up with managing components changing libraries if we want to go in the direction and those those individuals can then distill that to their teams get feedback and gives us a source to to really communicate because we're gonna because everybody has to be on the same page the other piece that elected meta does which i found unusual but i feel like it really works is any change that goes into that react components organization in github so any component that's touched there's generally you know react meta folk electro meta folks that will own those components and they'll always be there to review them give feedback give insight and this really helps promote that that discussion uh and make sure things don't fall through the cracks because with so many people and trying to keep everyone on the same page things will fall through the cracks there'll be new engineers that might not know certain things or might be trying to do something and so it's really you have all these ambassadors from other teams that you can use to communicate as well as they can shepherd everyone else and we have something called the proposal process so with all these components you're definitely going to get people that you're going to you're definitely going to want to get possibly duplicates of components and you're going to want to change direction maybe of of upgrading a library or or you have a problem and how do you want to solve that problem and so a lot of these uh problems and and things that we want to really get feedback from our internal community we have a github proposal process where someone will put up a proposal for a direction or a change that they want to do or for a new component that they want to build and the apis around that component and like the you know the apis in terms of the prop types and the interfaces um and and what they want to use it for and this gives this really encourages discussion across the other teams to discuss like oh i'm going to need that component as well and can you and you know can we modify the interface to be more generic or or what not so before every component is kind of created in our we have the system to ensure that the engineers first can talk to others that it's all transparent and open and there could be a collaborative discussion and it does add a little bit of overhead and i'll kind of get into the challenges of that and one of the last kind of pieces of problems is discovery we if we have all these components it becomes very difficult to discover what components you have and and what you need it becomes difficult to find out if is there you know some kind of video player or component or not especially if they're not named properly especially if you might have a repo with multiple components so for the discovery process we have kind of this tool called electrode explorer which are open sourced as well and it basically runs all the components in our organization you know on on the web application that way anybody can kind of sift through every component look at its documentation its dependencies dependencies that it uses um view it modify and like a little there's a little playground where you can modify the prop types and and use the interface so you can really see how it functions see if it fits your needs now for this to work it goes back to all components have to have a consistent way to showcase this so they all have to have the ability to showcase a playground they all have to have a demo app and so that so even to do this that archetype kind of comes into play where it's really entangled into every kind of piece and process that we have because the archetype ensures that all the apps have a demo it ensures that all the applications can build the same they can build in a way for this demo to work um and for them to show up on electrode explorer so that's why the archetype is kind of this uh fundamental foundation for us to move forward and so that's how we went about solving discovery then we gave this to product teams designers that way everyone now has a library fundamentally that gets built naturally as you build components change components and you can go back through the versions of the components and people now are kind of on the same page of what you have what can i use and designers also have something to leverage and what's really interesting is if you have a product team that you want to showcase some components that you've built to all you do is send them links to the explorer and they'll be able to see it and play with it and validate if it's you know if this is what they want or not but then there's like certain problems that we've that we've had and that's around components breaking other teams that's the worst thing about having dependencies and the worst thing about reusability the whole sudden there's this reliance on other teams and they're going to break you and it's only a matter of time you know it's going to happen and um so the only way that we can kind of figure out how to solve this is through cd and it actually there's it puts a lot of you have to put a lot of effort in building proper tests in your application in the component so the first pass of ci cd can be just like component unit tests and make sure that's solid but that doesn't guarantee breakage because you change the component and you make sure it works and you probably tested it on your application and that works great but those other apps you know who cares i got features to release and so there's no real way to guarantee that so i think the only the only way that we could think of to really solve this problem is have ci cd run automatically update other applications and run their tests and run their automation um so if you push if you stand up pr and in the pr you can specify is this is a new you know minor upgrade or a patch upgrade our cdc icd pipeline can you know wants to grab other all other applications that use that dependency automatically bump them and run their automation suite and and and kind of tell the person that's pr and which ones are passing which ones are failing that way before it gets reviewed by the meta team and before it gets accepted you can see what the impact of that pr will do and where we want to get to is we want to get to a place where if things pass we want to automatically upgrade apps that way there's no there's no need for engineers to even kind of go through and say oh these things have been updated i know they work and let me manually you know bump up their versions but where it's much more automated than that that way if you do have a bug fix or some feature improvement inherently all the other applications will get it so cihd's super critical it's even more critical when it comes to archetypes because if you release an archetype and it breaks something you break every single component in the app and we've unfortunately done that a few times and you get yelled at really quickly so you want to avoid really one avoid getting yelled at and getting like a thousand pings on slack with someone broke me and it's darker type because it's like instant and it ruins your day and so the cicd is most important during of checking archetype versions making sure if you're trying to bump a patch or a minor of archetype you're not breaking any component you know any app so the ci cd kind of scale in terms of how many apps it has to run at once for it to do this efficiently grows where you're going to have to you know run dozens of apps in parallel for every pr that you do and be ready for that but that's kind of the best uh machine intensive way that we can solve it that's not human intensive and so the cicd rules they're critical you can't really go about reusability with without it i feel there's going to be a lot of very large cost and so then you'll have you'll end up having the different teams being able to use the different pieces and now these teams ensure that they're not going to break each other and so we call it how this so as you go about let's say implementing the the ability to reuse in terms of technical sharing and then you go about being able to you have the archetypes you're going to manage dependencies and people can discover components and you have a team of people that you can rely on to help ensure that they're going you're going the right path there's still a fundamental problem um that kind of comes about and i call that kind of the ecosystem of reuse and when you want to take reusability on as an organization what we found is that it has to permeate every single layer of kind of management and development because it affects absolutely everything when people when you're going to build something you now have to not think of you know what's specific to you but how can other people leverage this when you want to create a component you're going to have a discussion you're going to have discussion with other individuals and other organizations about can this help can this help them or not and um when you estimate you might have to estimate you're going to make let's say a dozen new components are going to make a page you might lose a day to have the proper discussions and the thinking up front and so this really permeates every layer and it's a change of philosophy so you can't say i'm going to have reuse but i'm going to build things in silos or i'm going to have reuse and i'm going to build my features and i'm not going to put them inside the organization for everyone else to use i'm just going to put them in my app because it's faster immediately things fall apart so even with all of this in place it's still fragile and only i feel the only way to make it robust is if if people feel the same way have the same importance understand what they're trying to do and and why they're doing it so it's really a philosophy change in and how you build moving forward and then there are still challenges that we have not particularly you know um have really good solves for for example when there's new libraries or new technologies that are coming out that you want to leverage and you want to test out is it going to work is it not the benefits the pros with everyone we're using the same thing with everyone on the same common platform how are you able to innovate how are you able to get teams to really try something new versus not and so there are some challenges the the fragility of if of if teams are not out of the same philosophy um and and and what if they're in in a certain team people that really want to experiment with a new build system and if they go down that route everything that they build cannot be reused and they have to rebuild everything from scratch but these are kind of the challenges that you face and that you have to kind of talk through um and and figure out a process and and how to do it and so that's kind of the way in which we have been doing reuse and i think we have 500 something components across 50 apps and a few hundred engineers we currently have three tenants that are on um kind of the electrode platform we have walmart grocery and a piece of sam's club and where they're leveraging this reuse and i think we have a decent system down there's obviously room for us to really help kind of continue the the philosophy and pushing that forward uh improve our ci cd some more but i think that this general concept works thank you very much [Applause]