web. So React Native provides us with one feature to be running on one feature or one page or component running on all three platforms. And we have the native fields intact. Since React Native tweaks the native elements of the respective platforms, we have the native fields of the user experience intact there. And also we have capabilities to fix issues in real time with over the year updates. And we have our own in-house dynamic update system for that. And also those who are not familiar with React Native for web, these are the abstractions written over web API which helps you use React Native components and APIs using React DOM. So many companies are today using React Native and React Native for web for writing their application. But what we did extra here was building our own abstraction layer or own kit which is called the cross-platform kit. Our aim is to write components inside that kit which abstracts the user or a developer from the implementations and these components are guaranteed to run on all three platforms. So I'll take an example. These are the three pages which have a similar component or a reusable component which is like a sticky footer here. And we have three pages and this sticky footer capability is added to the React Native Recycler List View which we have open sourced. And now you as a developer can directly access it, write your code over it and you did not know how this part was actually implemented. So there are several other components that we have incorporated in the cross-platform kit. And this is how we want to move on with the cross-platform development from now on. So the current state of this dimensional graph we just eliminated the access by writing one code which runs on all the three platforms. Now the next access I want to talk about is the page-specific development. The problem statement I feel here is how a developer develops for different custom layouts. For example, you are on a product landing page which looks a bit different and then you are on the payments page which looks a lot different. So you as a developer should not be restricted to okay, today you cannot build that page because you don't have that domain knowledge. So we took a very standard approach here of digitizing our page. We have now divided our page into basic building blocks which are horizontally and vertically scrolling which we call widgets. Also these are reusable and extensible across all pages and it was easy to add and update the number of widgets that are entering on a page. But what makes this framework a rich multi-digit framework? So for example, these are two pages, page X and page Y and these are the widgets that are entering in horizontal or a staggered layout whichever way you want. It might have a header and footer to this page, custom to this page. So we have a custom header and footer support. You can reuse these components or these widgets across and you can add new ones. Also we support inter-widget interaction here and to optimize the payload on the wire, we also give time to live to these widgets as well as the page.  So let's see how on a high level it looks like. So these are the data providers for the backend systems. We have, I'm taking example of Flipkart, data providers that we have and this is the data flowing to the content aggregator service. This is the place where all the data from different backend systems would be aggregated and you have a layout console which connects to the aggregator service and this is the layout console, this one, where your product manager would actually go and make the changes. And as soon as the changes are made, the data in the form of the widgets or the building blocks flow to the front end systems and gets reflected. So ideally you are not making any UI engineer interventions here or deployments here and the changes get reflected in the front end systems. So now the state of the graph comes out to be one vertical axis and this particular axis is subjected to your product. It might or might not exist. For us it does and we're still in the process of solving this and this still exists for us. So the slide that we just saw that where we want to be the ideal world, let's see with the concept of cross-platform using React Native and React Native for web and using digitization, where are we? So we are one feature, one code on all platforms by the use of React Native and the cross-platform kit that we have built in-house which you today should also build at your end. We are solving this problem of replication of code. Also, by the dynamic update system that we have in-house and the over-the-air updates capabilities of React Native, we are able to fix issues in real-time. Also, by the concept of digitization, we now view the page in form of components. It's no more a design. It's more about components, how the API power these components if it's in the order of 1, 2, 3, 4, 5 or it's in the order of 5, 6, 7. So whatever API gives me, I render that. And I am page agnostic as we discussed. I also pointed this that we have enabled different stakeholders to make the changes now. The UI is not completely dependent on any UI deployment there. We are still in the process of onboarding more and more pages in React Native. Flipkart is a hybrid application right now. And we need our core UI teams to work on different app-size optimizations and network layers. We have definitely improved developer efficiency. We are like 75% efficient now. It takes a lot less time to develop pages when we have digitization and when we write one code. And having said all of this, React Native and React Native for Web allows us to build even the beautiful animations that we have today. For example, if you see Flipkart's gaming platform, you will see we have done a ton of animations even on web. So these are a few pages that we have on Flipkart today and there are more of them. You can just go and have a look. And what are the challenges ahead here for us? We're still trying to close the gap between the native and the React Native components. The React Native library, as Parshuram said, that we are still in the process of, we need contributions from the community. And bundle size splitting and reductions as more and more pages are getting onboarded on React Native. The bundle size is increasing and that increases the JS passing time. And we need stability on certain devices. We are still to be browser compatible. So these are some open source tools you can look at which we have open sourced in Flipkart and it's an appeal to the front end community to build cross-platform tools and share all amongst us. Thank you very much. Yeah, Q and A, questions please. So do we have questions? Yeah, sir, can you please turn on the mic? Hi, my name is Ajit and I want to know how you fix the real time issues especially for the Android application like in case of the big billion day and all that. Yeah, so well, since I told you we're a hybrid application but the parts that are written on React Native we use our dynamic update system that we have made in-house and we can just update the bundle there but in case where the parts are native we will have to wait for Android releases but that's not a very big chunk. Yeah, any more questions? Yeah, so that... You mentioned that you've not yet solved the products part of the thing. What is the challenge in that segment if I may ask? So I talked about the verticals. For example, I'll take example of a vertical which is grocery and so if some changes come on that particular vertical the people or the developers who have that domain knowledge of their work that with vertical grocery they will have to make the changes. We're still not there that okay, a grocery product manager can go and make those changes and just render it there. So I think if it's electronics, if it is a different category like footwear that might be different UIs that might be needed. Okay, so yeah. Rana, can you hand over the mic? Hi, my name is Satish, very good session. So I have a question that your widgets, right? So you're planning to use them maybe substituting them in different pages. So what are the benchmarks that you follow for creating these widgets? Because say for example, a widget is taking say 500 milliseconds or something to load. It might be okay for a thank you page or something like that but it might not be okay for a search page or something, right? So we make the widgets customizable that way. Sometimes we do give height and width from the backend the data that comes for the widgets. It will have the margin, the height or sometimes the color as well. We might tweak the basic UI part from the backend in terms of color, height, size or if it has to stick to bottom, if it has to stick to the top. We do keep these contracts intact in the data part. And how dynamic are these changes? Because say for example, I'm trying to evaluate the performance of a page and you are repeatedly changing widgets around this. So obviously every widget would have a different rendering time, right? So how do you track those things and how do you make sure that things work well? So my main point to know here is like what are your benchmarks for creating a widget? Because there has to be a standard to work across different pages. Yes, definitely. We do have those benchmarks. For example, a widget will have its own TTL. I just mentioned it here as well that as you're talking about optimization, we might have a TTL for that widget. If the data for that widget is expired, then only we'll render it again. Otherwise it won't come up on the payload at all. And if the particular widget has not expired and it still can be reused with the same color or maybe the same image for that matter, we just send, we don't send the data over the payload. So that optimizations that you're talking about has been taken care. But yes, the benchmarks vary from widget to widget. And as I told, a widget will consist of the actions or the behavior. The data, that means the data that has to be displayed in the widget and the tracking that we have to do with that widget. So these three are the standards that always come with the widget. And according to your use case, you can always have those optimized whatever are the requirements. Thank you. Yeah, that's it. Thank you, Doshi. Yeah. So guys, do you know one thing? There's an option called silent mode in your phone. So somebody's phone is ringing all the time. I don't know who is it? So if you don't know how to put your phone on silent, please come and ask me. I'll do it for you. Yeah. Okay. To speak. Cool. So Xavier will be talking about kickstarting a library of internal React components for multiple teams. Yeah, Xavier, up to you. And this? Closer, yeah. So, hi everybody. So I'm gonna talk about how we, for the past year, created several libraries of shared components for our clients 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. It's 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 gonna hear the breathing. Now it's good. Like that. You hear me well? Yeah? No, no. 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 gonna talk about. I'm gonna talk about why we started this project of shared components and how we tried to tackle this topic. Then I'm gonna deep dive in some of our design decisions that helped us make this a success. And at the end I'm gonna tell you, it's a little bit of a business part. I'm gonna 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 team 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 still at, 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, okay. 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, remade 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. So which was directly downloaded by the website. Problem was that the code base was growing without specific architecture. And so a lot of components I really didn't find, didn't follow the same syntax as 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 we 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. And 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 their 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 is 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 Verdatio, which is a private NPM open source. And this made a big, big difference. Thanks to this, we can say, and I'm gonna 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 gonna develop, he's gonna develop thinking, even though he is from another team and he needs to contribute, he's gonna develop thinking about reusability because he's gonna develop directly inside of Storybook, apart from his own project.  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 it's also used for our own product owners to validate and to show what the capability and what the components are available in our project. So let's dive in for some tips of what we think made the difference. So if we come back to this part of the diagram, first 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 a daily basis and pulling requests of changes on the code base. So we are not capable as a core team to check all of them. The thing is that we want to be agile and go fast. And so we had to set up an automated process, a strong process with formation to make it work well. So first, how we cut down our packages and components. We follow our atomic design. So I don't know if you know about the atomic design principles. It's Brad Ford who created those principles and it explains you how to cut your UI components in a hierarchy. So the biggest one, I'm starting to start by the biggest one. It's called, in our case, we used the organism as the biggest one, which is almost a full feature, 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 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 part 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 still has a pretty small shape and it's composable when it shares a common business purpose. So for instance, I was talking about fans. Fans, it's a specific business data. So all the widgets about fans can be composed together to make a bigger product. And at the end, you have the organisms. For instance, the fan sheet I told you, or chatbot. So that's the advantage. And there are full page features and they do satisfy by themselves a user need. So a fan sheet is a composition of widgets. But we also, for instance, have a chatbot. And this chatbot needs to answer some questions about fans. So directly, the chatbot is gonna retrieve those widgets and display them as it would have done it with a fan sheet. Let's take a deeper look at the code now of each of those parts. So that's impossible to read. So let's go a little bit in it. At the bottom, so you have the UI. UI is pretty simple. There is 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 setup and feature. I'm not gonna talk about it now because I'm not gonna have the time, but I would love to talk about that later if you're interested. After that, so you have our widget. Our widget 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 classical. The container is gonna fetch its data from a service that we created in order to optimize the composition of widgets at the organism level. And it's using what we call a modelizer, which is an adapter of the data that comes from the back in order to just clean it and to have calculated the variables if necessary. So 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 React, it can work and it displays the data. It fetches it, it closes it, of course, and it displays it without using it. And we export it in two separate pieces as well as a dump component without any data and the data fetching service by itself for you to be able to recompose it from the top. So for instance, the French hit, an organism, is composed 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 organisms to put Redux. So in order 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 data, or reuse it somewhere else in the application if the data is already available. And this Redux store is using our fetch widget data service to be able to get the data that is necessary for the widgets you're using. So now I wanted 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 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 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 libraries without one user, of course, even more. What should I pay attention to? So for instance, 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 gonna have issues. So the exposed components and function names are their props or the function parameters. That's part of the potential breaking changes you could make. The component style as well. So it's the style by itself. So I don't know if you change a color or a font. It is somehow a soft breaking change because it's still gonna have an impact for the end user.  But beyond that, the space it takes in terms of height, width or margin is might, for instance, in this case, might break a website. So this is part as well on the little things we need 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'll have, normally we'll have 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 take care of the style of our components. And it's a peer dependency because you can only have one version running on your code. So 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 Flow typed, our API with Flow types connected directly. That's a nice advantage because Flow typed is really, is disconnected completely to the base project it's supposed to type. 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 gonna break in his ID because he's not gonna have changed the exposed Flow API. So then it's gonna break, he's gonna need to change it. He doesn't have a choice. The CI will be read. He's gonna adapt his Flow type 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 anticipate breaking changes. There is also an automatic semantic versioning system based on the commits, like was mentioned a little bit earlier 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 it's gonna create a major directly. So people know that 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 all of us because even as tech people, we need to be able to potentially find a way on the speech to convince business managers to do such kind of projects. So our return investment formula 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 people to reuse your components. It's mainly on the right part. It's to reduce the project cost, meaning that it needs to be faster and easier and more robust to develop on this website with as 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 you would have on a GitHub repository. That's a pretty complex graph 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, 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 tools and improvements on our code base to have a flat number of issues, even though the activity was a little bit increasing at that time. Why did it increase three times? We discovered lately that it was mainly because there was a lot of turnover, because we're an agency, so there was a lot of turnover in the developers. And each time that there is an increase in issue, it's mainly because there were new developers coming on our project and they didn't know all our flow and how it worked because 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 into the depths of each issue and to their root causes to understand exactly what in the flow which can be the training of the developer. It can be that potentially it's missing a little tool to prevent him from doing a mistake to do. And then every week, we took weekly actions to make sure that 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 our diagram, of our graph 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.  So it's useful if you want, for instance, so 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 a project? We consider, thanks to the little formula you saw before, that we saved 18% of development cost 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 gonna continue. And a second side effect that rise naturally was the fact that it created a consistent 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 components, of any size of components, the UX team at the same time had to start synchronizing themselves even more. So for us, it is a success and we're gonna continue in the coming year. So 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 we didn't do that all together. Yeah. Yeah, we have one here. Micronus? So I wanted to know how you guys are managing the versions of the component for the library. So suppose team A, suppose you have a component in the 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 based or what, how you guys are managing that? Yeah, 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 WhatsApp chats and we do give news when something is changing, but we're not obliging anyone, no one to upgrade. They do as they wish, like they would for a normal library. So we trust them in making the right decision based on what we changed and what we improved if they see the value in it because they have to prioritize their own development roadmap as well. Okay, so on 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 Git 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? Yeah, on the right side, you can see the little bits, it's Verdatio, so Verdatio, it's a private NPM. So it means that we, each package is pushed on this Verdatio, it's really like NPM. And then the other teams, when I need to take the latest update, they do a Yarn, Yarn add the name of the thing with the right number, the right version. Hi, so when I'm writing my code as components, I always get confused about, for example, if I have a component that takes some text and renders it with a 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 inherent to the component and how much can be customized using props. Okay, what do I have there? I don't know, I didn't put it there. I was expecting a diagram I don't have. How we do that? So there is those three layers, there is UI. So we call it UI, which are the atoms. There is a molecule and then there is organisms. For the atoms, we consider that. So first, of course, they are already compliant with the UI design of the company at first. So most of the time, I see it's gonna be enough for the other projects. But then as a really simple component, we allow full customizability of the component by itself for the other teams. They can do whatever they want with it. We expose most of the style. We use a specific themes system we did by ourselves with style components. Then at a higher level, when you go through the molecules and the organisms, here is different for instance, because it would be too customizable and too complex and too crazy after to anticipate some breaking changes. So here we do a lot of some stuff, but based on what was really necessary, based on the questions that those teams asked us in terms of improvements they wanted to make in the style. So it's mainly like color of text or font and sizes of the components, for instance. And it doesn't go further than that. We want to set the style. At the same time, as I told you, it does set the UIX for all of those projects and it's a good thing. One second, please. Please do not leave the auditorium till the QA is done because we have a few announcements to be done. All right? Yeah, next question, please. Hello? Yeah. Thanks for the presentation. It was a nice one. So how do you tackle the inter- 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 there is a communication happening between these components. Yeah. So here, here for instance. So the fun sheets, so that's the little thing I didn't explain here because it would have taken more time. The fun sheet is made of widgets, of different widgets that are supposed to be connected indeed. And how our backend is done is that it's one route, one huge route, that gives all the necessary data to create a fun sheet. So of course here, you wouldn't want to have to, if you call 10 widgets, you wouldn't want to make 10 calls to the same route. So that's why we created, and it's pretty raw and straightforward, created a full service with all the widgets that compose a fun sheet in it. And for in 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 gonna, for you, make the call with the right parameters. And there is several routes, there is four routes in total, there is some other stuff I didn't mention. And it's gonna, you're not gonna have to think about that. It's gonna put this all the data properly with the modellizers that I told you, so the adapters for each widget. Inside of an output object with the name of the widget and the data it needs to get to properly get displayed. And then you just have to reduce the connection. So 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 another problem and it's way more complicated because it's like a big function with a lot of if-else. Yeah, next question. Anand here. So of course a nice presentation and we asked about the versioning and all, right? So someone asked from there about versioning. So it's like you are 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 for these components. And suppose I need to tweak a bit of, you know, the... So for example, I take an 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 extension is going to work for those components where I'm trying to use it. So I don't know if I'm going to answer the right question. You tell me. I think you put it there. Did I? Did I not? I did. So we have a... It's a tree, I'm sorry, you cannot see it well. I'm going to tell you. It's a decision tree that we give to all the peers, the product owners and the developers, for them to be able to make the right decision before making any change inside of the project. And 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 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, working together well. And then last step, it's a technical step and we do a workshop with them. It depends on the complexity of one hour to hours to understand where we're going to fit this feature on architecture to put it at the right place. All right, so and what about the server-side rendering, like how you guys are managing? 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 was it? It's for monitoring your production issues. Yeah, issues. You use a tool. We use a handmade tool with Google spreadsheets and Google scripts. And it's working pretty well. So all the issues that are shared on it, we use Trello a lot. Trello boards, a lot. Our development process is on Trello board, and it's specific from my company. Our 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 resolution. And we connected directly Google script to the API of Trello to be able to get the right data and to show it this way. Yeah, any more questions? Thank you. Those were some really good tips and atomic design principles. That was really good. All right, so how many of you folks are going shopping this weekend? Hands up. Okay, so we... All right, and those who bought ReactFu t-shirts collected from the counter at the registration desk. Then the event hashtag is hashtag ReactFu. So if you're posting on social media, please use the hashtag ReactFu and post your photos or whatever you're posting. The next thing is flash talk session is from 3.5 to 3.25 p.m. So we had four slots. Now we have three slots for five minutes of presentations. So flash talks are five minutes each. You can talk about anything, but you're not supposed to pitch your product. Your products are do hiring over here. So any site projects, open source projects, something like that. I got an idea today for an open source project. So in a hall full of auditorium with people with mobile phones, if they're connected to the network, just turn their phones on silent mode. So you can build that with React. All right, I want to do flash talk. Please write the topic with your name and phone number on a slip of paper and hand it over to me, Herschel or Todd. So that's me, Herschel, yeah, Herschel's there. Or Todd, Todd was here. All right. Yeah, selected speakers will be informed during lunchtime. So whoever gets selected, you can come and give the flash talks. All right. And one more thing is just before the lunch, there will be two BOF sessions. And after lunch in the BOF area and room one. So volunteers will assure you over there. Yeah, so that's it. Please go and have your lunch and please come back again. We'll have a great session. Thank you. Hello everybody. I hope you had a good lunch. Let's settle back in. So there's some announcements. There are two tracks of BOF sessions going on upstairs in the BOF area and there's one more going on in room one. If you go upstairs, there'll be volunteers to guide you. There is also an impromptu BOF happening on building AR and VR applications. So if you're interested in that, AR and VR applications with React, obviously. So if you're interested in that, that'll be from 4pm onwards. And again, I want to remind you guys that I saw some of you guys bringing in food and beverages. The venues strictly prohibits that, so please cooperate. Up next, let's welcome Vivek Nayar from Trusting Social. Hello everyone. Am I audible to everyone? Perfect. Everyone's back from lunch. I hope you guys are not sleepy as such. But even if you are, you'll just avoid some of the mistakes that I might just make. But I'm just very happy to see such a huge number coming up for the conference. Everyone, including the speakers, organizers are, everyone is really happy to see you all in this huge numbers coming up here. And I'm really honored to be speaking for React 2. Slightly up. Okay, perfect. All right, so the topic that I'm gonna talk about is a very fancy background and a very fancy topic as it looks like the magical land of ASTs and with baby Lea Slinton code mods. The purpose of this name was when I initially started coding in React or let's say any framework or JavaScript as such, Babel, ESLint, and these things looked really magical to me. Things were getting auto corrected. Prettier was auto indenting my code. And really, I didn't have to do much here because this was all magically happening behind the scene. Async await was working, even though it wasn't supported in some browsers. Internet Explorer was working well with even Async await and promises. So these things were all happening behind the scene with me being completely unaware of how Babel is doing all of these. So that was really magical for me how these things were happening. And the purpose of this talk here is to reveal that it's not that magical. And ASTs, as the name suggests, sounds really complicated at the beginning that you need to understand how machines work or how bits and bytes work. It's not as complicated as it looks like. And hopefully once the stock is over, once the entire conference is over, when you go out of this room, you will all understand how to create Babel plugins, understand how to create ESLint plugins and be better in writing your code, writing better optimizations, writing better organization-wide linting rules. And you probably will no longer require to do a find and replace into your entire application as something changes. You would probably use a code mod to do a large scale refactor on your code base. So that's what the purpose of this talk that it will open a new wide spectrum of possibilities for you. You can obviously do a lot of open source contributions if you learn how to write Babel plugins. You can write ESLint plugins for your organization. So a lot of opportunities that will become available if I'm able to convey the message of this talk and be able to help you understand how easy it is to create these plugins. So how many of you here have actually created Babel plugins or have worked on any sort of AST parsers or ESLint plugins? Is there anyone who's created one? Oh, so there's one I can see and okay, two here, perfect. So, three over there, right, perfect. So then for the rest of you, I think this is gonna be a really interesting session and I hope you learn something out of it. And that's what the objective is. I'll quickly go through the introduction part. My name is Vivek Nayar and I work for a company called Trusting Social. We are a fintech organization working for doing credit scoring and producing products. And if after the talk, there are any other questions which are unanswered. We have a BOF session as well, which is specifically targeted to Babel plugins, ESLint and code mods. But even then, if there are certain questions which are not able to ask here or in BOF, that's the Twitter handle where you can ping me and it will be, I'll be happy to chat on any plugins that you create. I'll be happy to contribute to them. And there are certain plugins that I have created then you can obviously do your open source contributions to them. So that's the Twitter handle you can follow me. And if there are any questions that are unanswered, that's the place to find me. So an interesting question that immediately comes up is I've been talking a lot about ASTs. I've been talking that everything with Babel, ESLint and code mods revolve around something called as an AST. But what is an AST? How do you explain it to anyone in very layman terms? What is an AST? So abstract syntax tree, a very simple thing. But if you see here, I've written a very simple code snippet which says const A equal to three and A plus five. So the very first line says it's a variable declaration that I'm doing and then I'm assigning it to a value which is a numeric value which is three over here. And then in the next operation, what I'm doing is I'm doing an addition operation. So it's A plus five. So it's a very simple thing that I'm writing in my VS code or any editor. There's an assignment and then there's an addition that's happening. But this is what you write you and me write in our editors. But this is what the computer gets to see. So if you see, this is a JSON representation of what an AST tree might look like. So some of the keys have been removed to help you better understand what are the important points in it. But the main thing to focus here is the type declarations that you see. So every plugin that you create with ASTs have certain AST nodes, AST types associated with them. So in our example, we had const A equal to five. So that was a variable declaration, which is why you see the very first is type variable declaration. So that is the first AST node that we created. Now, variable declarations can be many. It can be const A comma B comma C. So which is why this const is a variable declaration. And then you have a key called as declarations, which is an array of variables that you have declared. And all those have a type called as variable declarator. So these types are associated with everything that you write in your code, be it a variable declarator, be it an assignment expression, or you write a sink await, which is an await expression. They all have certain types associated with them. So here, we see we had declared a variable called as A. So there's an ID with the name A here. And then we had assigned it to a value, which is five, which is a number. That is why it has a type called as numeric literal. It could have been a string. In that case, the type would have been a string literal. And then finally our variable had a type called as constant. So that is why the kind is const here. It could be let or where. So this is a very simple representation of what the computer gets to see when it parses your code into an AST. And this is a flow chart of how things work. Every Babel plugin, when you write a Babel plugin using Babylon as the parser, it always starts with a root node, which is program. In our example, we had a variable declaration. So you see a blue box with variable declaration written in it. Then we had two declarations, which was A and assigning it to a value called as three. So you see two nodes on the left side of the tree. One is an identifier A and the other was a numeric literal three. And then we did an addition operation, which is an expression statement. And because it's two things involved in that operation, A plus three or A plus five, it's a binary operation, which has a left side to it and a right side. The left side was an identifier A and the right side was a value, which is a numeric literal five. And then there's an operator, which is plus. So this is how your AST tree actually looks like when you, in terms of the flow diagram, this is how it looks like when your code is actually parsed. And whenever you're creating Babel plugins, if at all you can do this diagram on your paper, it will help you better understand writing Babel plugins. So be it Babel plugin, be it ESLint or be it code mod or be it any Java compiler or a Scala compiler or anything, all these compilers follow three important steps. One being take the code which you and me understand and parse it into an AST, which is an abstract syntax tree. Then you want to do certain transformations to it. For example, I want, maybe want to remove certain notes from it. Let's say I've written a code which has debuggers in it. And I do not want those debuggers statements to make it to production. So this is the step where I'll remove those debuggers statements. So you can either add, edit, delete your notes of one AST and transform it into another AST. So this is the second step of any compiler. And the third step is finally you have transformed one AST to another AST. Now it's important for you to convert it to back to a code which you and me understand. So the final step is generate the code from the new AST that is generated. So three important steps, parse, transform and generate.  So the same thing to better understand things. You write a code like this, you parse it. There's a tree that's created. You see three blocks over there. One is a green node, the other is a blue, then is a red node. I do a transformation on it and I'm swapping the red and the blue node. So this is a new tree that got created. And finally with generate step, my code is getting generated with the new AST tree. So this is basically, I'm repeating these three steps because this is the building block of any plugin that we're gonna create today. Parse, transform and generate. And precisely the talk would focus on the basics of AST. It is gonna talk about how do you create Babel plugins. It is gonna talk about why ESLint and why not other linters which are available. And we'll be doing a lot of live coding. I'll be coding few Babel plugins, few ESLint plugins and at the end, code a production ready code mod for react applications. So that is how the talk is structured. What we are not gonna focus about is we are not gonna go deep dive into how lexical scoping works or how tokenizing works. That is the topic of discussion for some other talk. So some of the production ready plugins which I use in my applications and probably some of you might also be using, one of them is Babel plugin, Lodash. Majority of the time when we see our final bundle that get generated, it's usually bloated because it's either moment JS, which is taking a lot of time or it's either Lodash, which is occupied a lot of space for us.  So this plugin helps you with that. This plugin will only import what you're using in your particular code and will not bloat your production bundle. So this is a production ready Babel plugin with someone has created with the understanding of ASTs. Another important plugin which has been used is Babel plugin transform react remove prop types. Prop types, people working with react would understand that it is something that we use for while we are developing our application to make sure that we see if you're passing a prop of a different type to a particular react component or we throw a warning or an error to us. But you do not want your prop types to make to production bundle. So this particular plugin will remove those prop types when you're generating a production bundle. Another plugin that's very useful is react class to function. We have been talking a lot about hooks these days and people are running behind converting all their class components into hooks. But this plugin had been already there long back. What it basically does is you have a class component, you give it to this plugin and this plugin would convert it into a functional component. This is a plugin that I was recently working on which is better async await. This is inspired from Golang because that's what I'm recently started learning. So usually when you write your async await syntax, this is how you write, you put them in a try catch block, api.getdata. If there's any error in this API calling logic, the catch block will call it and you call handle error. But if you have multiple of these APIs in your function, you either put one try catch or you have multiple try catches, which is eight increases the lines of code and probably is difficult to read as well. So this plugin was inspired from how Golang does it. So you see there's an api.getdata on the left side. There's an array expression whose 0th index is an error and the first index is a response. So you just check if error is populated, then something went wrong in the API. And if response is populated, then you got the response and it was a successful 200 okay. So you don't have to do anything. This plugin basically makes sure that when you make an await call to an API, error or response either or fit will be populated. So you don't have to put try catches now because that plugin had already put it in the code that it has written. So we'll quickly do a demo of few Babel plugins to help you better understand how all these things work. This is all theoretical at the moment, but these plugins will help you understand. So one important thing when you're developing any Babel plugin or ESLint or working with AST, this is the most important site that you have to be on. It's AST Explorer and the advantage of the site is that it will tell you the AST representation of what your code will look like. You can transform it here. So majority of your time you will be spending writing your code on this particular AST Explorer and then taking it to NPM or publishing it somewhere. But first you do your experiments on this particular web page. So what we are gonna do is a very simple plugin to start with, let's say, is it clear to everyone? Is it now? Perfect. One more. So one thing to notice here is you can choose different parsers for your AST tree. There's Acorn, which was initially available, which is Babel ESLint for your ESLinting. You have Babelon 6, Babelon 7, Esprit is the parser which ESLint uses by default. Babelon is the one which we are concerned about because we are writing Babel plugins at the moment. So I'll go to Babelon and select this parser. And what this very simple Babel plugin is going to do is, in your code you might have a syntax like this. You write const a equal to five and then you might have a debugger statement somewhere and then you do a equal to a plus six. Now there are a lot of companies and there are a lot of organizations where there are no proper PR reviews in progress. There is no pipeline where in people could figure out that there's a debugger statement which is making it into the master branch or going to production. So in all those scenarios, you can write a Babel plugin which will make sure that if there is debugger statement anywhere in your code, this Babel plugin will remove it. So how will we do that? The advantage is first for this AST Explorer, you click somewhere on debugger. Let's say I click on debugger here. It gets highlighted on the right-hand side and lets me know which AST node I have to target. So it says I have to target a type called as debugger statement. So I go to VS code. This is the bare minimum of how a Babel plugin should look like. It exports an object, it returns an object which has a visitor key in it. Visitor key is basically because it follows a visitor pattern which is a different topic of discussion. But visitor pattern is an object, is a visitor key has an object and here you basically say what node do you wanna target? So I wanna target a node called as debugger statement. So when Babel, Babelon will start traversing this tree when it reaches this particular path, when it reaches a debugger statement, I want this Babel plugin to remove wherever there's a debugger statement. So I say when you reach this path, remove this debugger statement. So a very simple example, there are complicated plugins also which we'll do but this is a very bare minimum of how you can remove debugger statements. So you say part.remove and anywhere there are debugger statements in your code, this will remove it. So let's test it. Let's add this Babel plugin to our plugins array here.  And now let's run this. The file that I want to execute it against is remove debugger.test. And you see I have a const a equal to five. There's no debugger statement which is present over here. There was a debugger statement initially. This is what the code was const a equal to a plus five and a debugger statement with this Babel plugin. It has removed the debugger statement which was present in that code. And if you run it against your production bundle everywhere there is a debugger statement, everything will get removed. All the debugger statements will get removed. So this is one simple example of how things, how Babel plugins could be written and how you can target different nodes. Another example that we can go is a lot of times it happens a very simple thing. You write const a equal to five and then for debugging you have alert statements in your code. Let's say you don't want to put, you have alert statements and now again, very similar to our debugger statements, you do not want alert to go into a production ready application. So A, you do how you did with debugger statement, you remove them or you convert them to something like a sentry reporting or you report it somewhere. Here we are going to convert it into a console.log statement which is harmless for us at the moment. So what we want to do is we want to convert this alert statement. So I click on alert and I see that it is something called as a call expression on the right that I see.  But if you are doing an API.getData which is an object and a property and then you calling a function that is called as a member expression. So the two important things that we need to understand is what a call expression is and what a member expression is. So any function call is a call expression and any object property, then a function call is a member expression. So we understood that we need to target something called as a call expression. So we quickly go to our code and the bare minimum is ready. I say the thing that I want to target is a call expression. So you say, okay, this is what I want to target. And now I have to do something with it. I need to replace it with console.log. Now, how do you do that? You click here and you figure out that, okay, this call expression has a cally and that cally has a name alert.  So I go here and say, if path.node.cally.name is equal to equal to alert, I want to do something with this. So now what I want to do is I want to replace it with a console.log. So let's see how that looks like. So this will look like console.log. So again, I click over here and figure out that a console.log looks like, again, a call expression. But the difference is that the cally here is a member expression, which has an object, which is console, and a property, which is log. So now I understood that I need to replace it with a call expression. So I say path.replacewith. I replace it with a call expression. Call expressions, cally would be a member expression. Member expression has an object. So I say that's an object, which is an identifier with a name console. And it has a property with an identifier called a slog. And this call expression, if I see, takes a cally in arguments as well. So arguments is A. Now how do you get arguments? Because in alert statement, you already have arguments. So I take the arguments out of that alert statement, say const arcs is equal to path.node.arguments and pass it to this new replacement that I've done. So this is a call expression. If it's an alert, take the arguments which are passed to alerts, now replace it with a call expression, which is console.log, because it's a dot operator. So it's a member expression, which is console, log, and then you pass the arguments to it. So let's add it to our plugins area. It's inside dot slash plugins slash convert alert to console. The code that I'm trying to convert is this. It's an alert I am here. I want to convert it into console.log I am here. So I'll go and run this code. This is inside convert alert to console test. And you see alert I am here got converted to console.log I am here. So the alert statements everywhere in your code will now get converted into a console.log statement with this plugin. So far, so good. Perfect. Another complex example that we're gonna do is most of us write things like this, one comma two comma three. You map over it. You get a value and you say value into two. Let's say you want to just multiply it by two. This is an arrow function expression here. And there are scenarios wherein your browsers might not support it and you want to convert it into a function expression. So you would want to convert it for any number of reasons. Let's say you want, you do not want arrow function expression and you want to convert it into something like this. So you want to convert it into something like this. Oh, oops, okay. Yeah, so you want to convert it into something like this. So now we click here as always we figure out that note that you want to target is an arrow function expression. So we go to our code arrow to function. We say the note that I want to target is an arrow function expression. Get me the path of it and we'll do something with it. Now I need to extract this value that you see over here because this is the same thing that needs to pass to this function. So how can I get that? It's inside params as you see on right. So it's arrow function expression and params. So I extract this out from here. So I say const params is equal to path.node.params. I also want the body to be same because that's exactly what I'm gonna do. Except the return statement, everything is same. So here if I see the body is a binary expression which has all the things in it. So I copy the body as well. I say the body is path.node.body. So get me the body, get me the params and now I will replace it. I'll say part.replaceWith. I want to replace it with what let's click here and it says I want to replace it with the function expression. So I go here and say I want to replace it with the function expression. Babel types is the place where you can figure out what is needed by home. So what are the parameters needed? I see function expression takes an ID. It takes params. It takes body generator for generator function and async if it's an async await. So I know that function expression here would need an ID which can be null for now. Params we have already extracted. So I say, okay, just copy paste the params that I've got. Now I can't place the body directly here because the body here looks slightly different because there are parenthesis here and that parenthesis basically means it's a block statement. It's a block of code. So when I click here, I figure out that the body is a block statement. So I say, okay, replace the body with a block statement. That block statement if you see takes a body which is a return statement. So I say, okay, the body will be a return statement and the body would be what I've already extracted above. So this is my plugin. Now let's try to add it to our run.js file which is our array of Babel plugins and we say it will be plugins slash, what was the name of the file? Arrow to function. Arrow to function. Okay, now when I run this file it should lead to an error and why I'll tell you test arrow to function. Okay, it leads to an error as expected. It's saying property key expected but got this thrown new property body expected of type array but got an object. Your body can have multiple statements in it and it cannot be a single line. It has to be an array of statements. But what I've done in the code that I've written, you see the block statement that I've written it just has one line in it return statement. Instead, it should be an array. So let's just convert it into an array here. And now let's try to execute this. And you see your arrow function expression is now converted into a function expression with a return statement with everything and you return an arrow function got converted into a function expression and with very few lines of code. So this is what ASTs, if you understand ASTs this is what you can do with them. These are probably a smaller example. So what all could be done but you see the bigger production level Babel plugins which have been used they all follow the same fundamentals target certain nodes and modify things in them. So those were the plugins that I had for demo for Babel. Most of the things that you saw I was adding plugins into and particular array of plugins. Your plugins and presets go to a file called as Babel.rc file. It's where you specify your presets and your plugins. This is how a very simple Babel.rc file looks like. I have react ENV and I'm using a plugin called as transform object res spread. So now a question that arises that immediately came to my mind is I've understood what plugins are but what are presets? So Babel presets are array of Babel plugins. So you can either publish one plugin or you bundle them all together as an array of plugins and publish it as a preset. So if you want to look at what Babel preset ENV comprises of this is from my code base it may vary for you but this is what Babel preset ENV has. These are the plugins that come bundled with it. You can enable the debug mode in your Babel preset ENV and you'll print the plugins that it is using. Async to generator because I does not support Async await so that is why this is there and there are a lot of other plugins as well. So presets basically being an array of plugins and another important question that immediately comes to mind is what is the order of execution? Are plugins executed first or are presets executed first and how does that happen? So plugins are executed first in top to bottom and presets being an array of plugins are executed in the reverse order from bottom to top. So the order of execution is plugin from top to bottom and presets from bottom to top. So yeah, so that is that is all about how Babel plugins are created. One quick question that comes to my mind immediately after this because it's related to the next topic that we're going to go on. How many of you are actually using linters here to actually have linters in your code? Oh perfect, almost all of them which is really great and are you using ES lint for it or are you using something else? How many on ES lint? Oh perfect, then I don't need to explain what other linters were available, okay. Okay, so this is happened with most of us, right? You write a code in ES lint tell you that you weren't supposed to do that and this has happened with me recently because I started working on a code which was in Hapi and Hapi node, Hapi's framework for some reason has some weird, weird ES lint rules which is at most of the time it used to give me an error saying you're not supposed to do that. So I turned off all of them rules and then put mine in it. So this is usually what happens with people when we are really started working on a old code base being maintained by someone else. But linters is a very good practice and why is that? Because static analysis of code if you're not really into reason or you're not really got into the type script but you still want your production code to be lesser buggy as compared to as compared to what it could be. So have linters in place because that will give you a static analysis of your code that will show you your errors if you have undefined variables which you're using if you're trying to import something that does not exist. So static analysis of code it will encourage best practices you can have Airbnb style guides or Google style guides to enforce better practices in your code. And finally, if you're using let's say a prettier which most of us are using at the moment or a prettier or standard or anything it will enforce certain style consistency with ES lint also it happens you can say that I do not allow semicolons or I allow tab versus spaces so all the styling consistency can also happen with the linter. The other JS linters which I think none of us care about at the moment were JS lint, JS hint and JS CS. JS lint was the very first that came with was created by Douglas Crockford the some of the cons of it where that it was not there was no configuration file available for it so you cannot really turn on or off a rule you cannot put in your own custom parsers or rules to it which is why it didn't really work out so JS hint came into picture which was a forked version of JS lint it had a configuration file but it did not allow you to write custom rules so again people really didn't like it and then finally JS CS came in which had configuration files which allow you to turn on and off the rules but also allowed you to write custom rules but then it was not catching errors like an undefined variable being used somewhere so it was not finding potential bugs in your code but it was telling you if there is a style inconsistency so JS CS I think recent not recently but got merged into ES lint so finally ES lint came into picture which almost everyone here is working on which is great and using in your applications you can write your own custom rules you have custom formatters custom parsers a very big example of a custom parser is Babel ES lint ES lint had it own parser called as Esprit but then Babel wanted to make sure that all the new features that Babel supports also are shown problematic by ES lint so they created something called as Babel ES lint as a parser so that's ES lint's parser taken plus Babel's functionality is added to it and then you have a new parser for linting things which is Babel ES lint so very good you can write your own custom parsers you yourself can write your own custom parsers you can turn on and off the rules which are not available for different the linters which came before ES lint you can set them to one or error you can specify whether this will be a warning or an error this is how an ES lint rule looks on my VS code editor it will look different on you but this is such a detailed message that it gives you that there's something wrong in your code and ES lint when you write an ES lint rule this is how a basic structure looks like you have a meta which says type type is suggestion, problem or layout suggestion can be, this can be problematic but it will not lead to a buggy code if you say type problem then it will be a buggy code 30 minutes, right? okay, it will lead to a buggy code and then when you say fixable code this basically means when you do an ES lint minus minus fix this rule will automatically fix your code and the create function is the place wherein you actually write your rules when you're working with ES lint rules you always create three files one is your actual rule file one is your test file and one is a markdown file which basically is for documentation so if you have to do this thing so we choose an SPRE parser we go and transform and say I wanna do an ES lint transform and the code that I wanna transform is I don't want to allow anyone to use promises because async await is in place so I say cons data and I say get data.then response and then response so I don't want to allow anyone to use promises so I will throw an error if someone uses .then I'll tell him or her that you should use async await syntax so I click over here and figure out the thing that I need to target is a member expression and that member expressions if that member expressions property is then so I say I wanna target a member expression and if that node.property.name is equal to equal to then it will help me identify that it's a member it's a promise call and then I say I will throw an error and how will I throw an error? I will use something called as context I'll say context.report and throw an error the message would be use await over promises this is the node that I wanna pass okay so you see it's throwing an error on the right it's saying use await over promises okay check it okay use await over promises but you see there's a problem here it's pointing the error at get data instead it should be pointing the error is at .then so a quick fix to that we say the exact line of code that you wanna point an error to we say node.property.loc and you see now it's exactly pointing to the place where there's an error so use async await over promises this is what that ESLint plugin does it's a very simple plugin which you can use in your apps at the moment if you do not want to allow promises the last bit so celebration time it worked successfully I'm running out of time so last bit of the talk is about code mods when you wanna do a very large scale refactor of your code base this is what you use for writing code mods we use something called as jscodeshift jscodeshift is a library provided by Facebook which will help you do a large scale refactor of your code and how to use jscodeshift you do a global install you specify what your transformation file is and then you specify that I want to transform everything that is in the src folder so I say transform everything that's in the src folder and it will convert everything so yeah so that's it for the talk these are the certain resources that you can that will help you understand ast there are a lot of them documentation is the biggest resource then there are certain jscodeshift has all node level APIs which you can follow to understand what APIs it provides and how to use them and finally there's a Babel handbook which is like the greatest resource to understand anything about writing a Babel plugin so yeah that's it thank you everyone for listening to it and if you have any questions around this then please demo like that hi so you mentioned that jscodeshift is for large scale transformation but like technically do something extra to handle those large scale transformations or it's similar but so if that question is can I do the same thing with Babel exactly so yes you can definitely do that with Babel as well is just that jscodeshift provides you certain APIs which makes it easier for you to do the transformations so there are certain level of abstractions that jscodeshift has provided you for you to easily modify them and plus recast parser which will help you do the formatting and pretty printing of it as well so that is also something that comes with it so but yes it's very much possible you can do the same with Babel as well you can write a Babel plugin and do a transformation but with jscodeshift what you can do is you can do a dry run of things so you will understand what the modifications are going to be and whether to commit them or not and it will give you proper statistics off to how many files were modified and then you can actually manually check if these are correct or not and then finally merge it to your master one more we don't have enough time for follow up questions so he will be around actually we are running out of time so you can catch him offline so yeah there is a bof session that we are doing outside so if there are any more questions we will catch up thank you so much till the next speaker gets set up let's play a game do you guys know the person who is sitting right next to you on the left and the right unless you are sitting with your friends why don't you introduce each other let's do that right now I am not kidding let's do it right now can we remove this yeah let's come back to it part 2 of it make sure that the phone of the person sitting right next to you is on silent we have been mourning you since morning but there are offenders and I will promise you stickers if you find a culprit so let's do that I am not kidding let's do it right now I want hands raised oh this guy next to me is the culprit just put your phone on silent and show it to the person next to you I am not kidding do it right now okay I am trusting that you have done it let's go on hi everyone can you hear me everyone fine yeah so good afternoon again and welcome to re-add foo I am Santosh Gramprohit and today I am going to talk on delivering the re-add yes applications at scale yeah so before we move on to the topic let me introduce a bit more I work as a developer at Walmart and for past few years I have been working on React and some other frameworks and libraries like Angular or Polymer and so on below is my Twitter handle and the personal and the official mail IDs where you can contact me on so let's get back to the topic when we talk about delivering the applications at scale there are multiple meanings to how can you scale the applications as a developer you can write efficient code you can write performance code and then scale your application or from a diverse perspective you can increase the number of servers when the traffic increase and then scale it but what I am going to talk today is how are you going to scale the applications by having a proper architecture and the CI CD system to support it and then scale all the multiple applications to explain a bit more we worked on a solution to host multiple enterprise applications under a single entity sort of like hosting portal and we worked on scaling those applications which were built by different teams so our agenda is going to be something like this we will start off with the challenges and the opportunities that we faced when building this approach then we will move on to the basic UI architecture of it and the CI CD system to support that and we will talk about something called as CDD that is Confit Driven Development and we will finish it off with the performance benefits of using this approach so let us start with the challenges as I told you this is a sort of a hosting portal where you have multiple applications coming inside it so what it means is that these applications are built by different teams and they have their own roadmap and they have their own release cycle so you cannot tell them to release their applications today or tomorrow or day after tomorrow what it also means is that these applications might have their own text track as well so we had the challenge of supporting the existing applications which were built on AngularJS on top of these challenges we also found out we could build on some opportunities like a single sign on where the user logs in one application and he or she need not login to another application or say user analytics where the application team will get to know how the people are using their application and some benefits like high availability of the application and faster development and time to market so let us start with the basic picture that we followed so as you can see there is a main application here and then you have these child applications 1, 2 and 3 now these child applications are npm modules and these modules are added as a dependency to the main application as you can see the application 1 is at 1.0.2 while the application 3 is at another version 1.4.5 because these applications are built by different teams and they are coming inside the main hosting portal that is the main application now one of the obvious question that you would have is why would you go with this approach of building npm modules for your application so let's see the benefits one of the benefits is that npm supports versioning by default so you know something called as semantic versioning where you have the major update the feature update and the patch update if you do a breakable change you update the major number if you do a feature update you update the middle one or if you do a bug fix or something like that you update the patch version so you have the versioning capability built in on top of that npm allows you to reuse the components very easily so you can just add the components that you have created inside your package.json and you are good to go so the whole dependency thing is also built we also found out that when people write npm packages for their application they tend to write modularized code so if I am doing, if I am breaking my application into multiple npm package I want that those packages should be used by other teams as well as by my team so I will try to write more modularized code also our npm module consisted of the usual source code and the distribution code the source code was written in the jsx react while the distribution code was the esy code which was transformed by bevel another advantage of using npm is that the dependencies between the packages can be shared what it means that if the main application has one UI framework dependency then all the child applications are going to use the same one so you have the consistent styling and you have the consistent theme across all your applications inside the portal now that was the theory part of how you can build your applications and divide it into npm packages but how are you going to do that in your code base? now think of this scenario where you have multiple repositories for your packages so if I divide my application into 3 or 4 packages and if I have 3 or 4 repositories in github then if I want to release the application I would have to go to each of the repository send a pull request, get it merged and update the version number and so on so that's a bit of an overhead task so there's a concept called as mono repose wherein you develop these packages in a single code base and it's not new, there are many open source projects that use it like say react or angular or just you can go to the source code of react in github and get to know how are they doing it and there are multiple ways as well if you are using yarn support doing that something called a workspaces so you can have multiple workspaces in your code base and you can develop these packages we use something called as lerna because we were using npm client and lerna allows you to do the same thing that is managing multiple packages in a single code base so as you can see on the screen we have the main folder here we have the mylerna repo folder and inside this folder we have the packages folder so this packages folder consists of the package the npm package you are doing for your application and each of this package in npm module and these packages are added as a dependency to the main one so you are developing these packages inside a single code base instead of having multiple code bases another advantage of doing this is that you can add these dependencies at local, test it out and then publish it to the npm repository that you have now we used internal npm repository for publishing the packages not the public one and we used lerna for management of the packages in the code base that's fine, another approach that comes to mind when we talk about using npm and dividing the application into multiple packages is the micro front end let me explain the micro front end a bit think of this application about the product where you have the description of the product, you have some filters and you have some reviews now this application, this product application is being built by multiple scrum teams so you have team A working on the description part the team B working on the filters part and the team C working on the reviews part how would the development be here so these teams would create the custom element for their package it will be independent code base and this custom element would in term be developed by say angular react or the framework of their choice that's how mono repose works and it would look something like this where you have the product description custom element, the product filters custom element and the product reviews custom element and you are going to pass the product tidy to each of them and based on this product tidy it is going to fetch the description or the filters or the reviews for it now however approach differs from this is that when I showed you the previous slide we had the main application and the child application so we work at a higher level we consume the applications as a node packages how these applications are being built whether they are using mono whether they are using micro frontends or they are using monolithic approach the single SPA approach does not concern to us that's one of the main advantage that we have we do not govern how the application teams are building their apps another distinction is that you don't exactly know how are you going to share the components that you have created in micro frontends by using the MPM approach we already have the framework to reuse the components we have the framework to share the components as well on top of that we provided a robust CI CD system which checks all the code quality that is going into the code base and by having this MPM approach the styling the theme of the portal was consistent and that's how this approach of using MPM differs from using micro frontends that's fine we talked about having MPM approach but it is of no use if you don't have a robust system where application teams can easily put their package in the repository so for that we had to build a robust CI CD system in place and how did we do that so we provided a boilerplate repo to the application teams now this boilerplate repo had all the code quality checks written so all the links and the test would run whenever you send the GitHub pull request and when these child applications are published with a new version whether it's a feature update or a patch version it would also trigger the build of the main app so if I want to tell you the CI CD workflow from the server perspective it would look something like this where you have the child application at version 1.0.0 and the application teams are doing some parallel features that is feature 1 and feature 2 so once they are done with the development they would send a pull request to the dev server and the reviewer would check it and do the code review and finally merge it so it goes to the dev server and depending upon the servers that you have it will go to QA or stage and finally it would go to the prod 1 now in the prod server the feature number that is 1.1 is updated because you have done 2 features and not the bug fix or the breakable change and how you increase the version number is again dependent upon the teams they can do it manually or you can parse the commit messages and also do that and finally once you update the version it is going to create the build of the main app and if I want to show you the workflow from the developer perspective how do they release the applications it will look something like this so you have to clone the boilerplate repo this is a one-time process on-boarding process once you have clone the on-boarding boilerplate repo development team has the development branch where can they do development so the development team would take a feature or a bug fix shortly branch do the code changes and send the pull request back to it so the quality checks would run on the delta code that they have written and once these automated checks are passed it would be going to the reviewer who can review the code and finally it goes to all the service that I mentioned before and it gets published to the npm repository after running all the code quality checks on the entire corpus and not on the delta code and once it published to the npm repository the internal npm repository it is going to create the build of the main app and when I talk about the code quality checks I mean as simple as this this is a sample screenshot from the Jenkins server where the links and the tests are running and you have this report the test report that is generated this is a sample report where it tells you the coverage by statements or by branch or functions or lines of the individual files and you can also have something like say a threshold and if the threshold is not met then it would fail when you talk about the branching strategy there are multiple ways again you can do it in your codebase we follow something called as trunk base development where you have the main branch that is the trunk branch and you take short loop branches out of it daily do some bug fix or a feature update and send the pull request back to it but there are other ways you can also do it in your codebase like say git flow and again the application teams are free to follow their own strategy if not tell them how are they going to do development but yeah they can follow git flow or they can follow trunk based as well and for continuous integration we use an internal tool of Jenkins called looper which is built on top of Jenkins and for continuous deployment we use an orchestration tool called conquer now for this orchestration engine or tool does is to take the artifacts from one server to another server put it there or spawn a server and run the test and all there are many open source engines available as well you can check like facebook chef it does the same thing and also provided the link for conquer at the end of the slide so you can learn more about it and also implement it in your project if it fits well so that was about the architecture of the portal as well as the CI-CD system to support it but we found out another way where you could also scale the applications that is config driven development in ADD now what it means as the name suggest is that you are developing your applications by writing more configs and by writing less core now how does it help so we found out that there are teams many teams who do not have a dedicated UI developer so they want to do a quick prototype of their applications without investing much time into it and in order to fasten those development we created a standard set of components now as I mentioned in the previous slide where the application teams would divide their code into multiple packages and create these packages so that it can be reused by other teams there it helps because we have already have the code base of these components created the standard set of components created why do I mention the word standard because there are many components you can create for each of the use case you cannot tackle for each and every case out there so we focused on solving for visualization or the reporting solution we do not try to solve for other solutions like say building the layout and etc and by focusing only on the visualization aspect we found out that many teams could use it in the code base and do the faster development and put it in the production faster there are two parts to it first is creating the standard set of components that is already achieved how are you going to use these components in your code base so for that it looks something like this where you have the micro services API created for your application and you map these micro services API to some visual component that is out there like say bar chart or it can be a pie or a line or any of the chart and then you export that code snippet and then you consume it in your project it sounds very simple let me show you a short demo of how does it look so this is a replica of the app that I have created let me expand a bit so that you can see it properly fine it's not the full-fledged app that we have built but it's a replica I want to showcase only how you can export the components and consume it in your project so you have the standard components here on the left-hand side you have the bar chart you have the pie chart and you have the line chart now these components are created by the application teams it will be very last set here depending upon the visualization components that you want to use and you have something called as configuration ID what this means is that this configuration ID is tied to some micro services API so when you fill in some configuration ID here it would fetch that data from the micro service API so this is a replica and there is no server running behind the scene think of this as a configuration ID where you have ID something like this sorry and when you click on submit it's going to fetch that data here and then you have the visualization of the bar chart created and you can as well toggle between the pie chart and the line chart and do the different visualization for the same response data and when you click on the export component you have the code snippet available for you and use this code snippet in your project and consume it so where does this help one of the advantages that the application teams do not have to write the transformation functions require to transform the response data to the format that required by the line chart or the pie chart and the advantage is that they can just copy the snippet and use it in their project without downloading the dependency etc because we provide a boilerplate repo the package which does the line chart or the pie chart is already there in the code base so they need not download it again and they can quickly do the development of their project so that's how the consumption of the components the standard components works in config-driven development so that was the demo of how CDD works let us see the performance benefits of using this npm approach so I told you we are using the npm modules for sharing the dependencies between the application what it means is the dependency payload that is downloaded when you move from application 1 to application 2 is going to be less and because you provide a boilerplate report to the development teams all the code that is required for say minification or say obfuscation of the code or say the dead code elimination or tree shaking everything is built in by default so the developer need not invest their time on writing the code for say lint or minification etc they can quickly start doing their business use case so all in all the developer experience is better in conclusion as I told you we had the challenge of separate code bases by separate teams yet all of these code bases all of these applications were hosted together in the portal and we followed the npm based module system where in the dependencies were shared between the applications and because of having the robust CI CD and having the config driven development we could provide the high availability of the applications as well as faster development and faster time to market these are some of the references that I have written you can learn more about Concord here or how the learner works there are some links from micro fronted semantic versioning and trunk development where you can go and learn more about it again the contact information and thank you now I open for the questions that you have yet my name is Anand so one question is so it's fine like it looks fine and presentation was good so you have suppose two or three components that you publish to npm right yeah either being internal or something so once you use it right how each component can interact with the other one so suppose suppose any component has some event that got triggered and based on that some other component need to update how that part is being handled in your framework so if you have seen the slide where I talked about the mono repose we are using learner so you can easily add the packages as dependency and you can even share the packages between them so if there are three package and the package three is a dependency for one and two you can just add it in there and you can do that did it solve answer your question kind of but the thing is then you are creating a dependency between one component to another component right so then it's not whether that package has to be created or not so if you have these dependency between the packages it makes sense to have it in a single package once you have it in a single package so if you see your application and you can think that I talked about product application then you can logically divide it into three modules I cannot divide it into other modules where you have dependency or cyclic dependency going on so you need to properly if you properly divide the application into modules 90% of time you will not face that problem so super interesting concept but I am having a lot of scenarios running I want to know is how much granularity is Walmart going to is it based on product feature level like a product search product filter or is it at like a very smaller level something like search which is used by product search or you know and review search that is one question how much granularity answer that okay so as I told you we work on a higher level where you have the applications coming inside the portal now how granular that application needs or how they are doing development what branching strategy are they following that is not a concern for us this is a portal where the teams are coming application teams are coming in performance as I told you we have provided the boilerplate code developer experience is good improving the developer productivity but I am talking about the performance in the when the app actually renders in the browser so did you see a lot of performance benefit like the load time increased or the load time decreased or you know interactions became much more fluid and the dependencies which are common across the packages are shared so if there are two applications which share most of the dependency then it would not require downloading it again but if you create an application which has which has complete dependency different dependency tree it would again have some performance implications so I would say because this is a portal because at a higher level then we could solve for some of the application performance but most of the the ownership of improving the device at the lower level we did what we could do at a higher level hi thanks for the presentation my name is Sakeer I had a question around the boilerplate code so you said it's like a one-time operation you just copy the boilerplate and then start development I am assuming the boilerplate contains all of the webpack configs something like react tab where you download everything so the question is if you make an improvement in the boilerplate repo how does someone who has cloned it and like development has moved forward significantly how do you back propagate these improvements so that's where the versioning comes in so if we do a breakable change you update the major version if you do say a bug fix you update the patch version so because we also have the versioning done we also release it consistently like say every three weeks or four weeks depending upon the changes that we have and the teams would get to know these versions have been released and based on that they update their codebase if it is required for them they can do a merge as well depending upon the changes that you have so if we create a breakable change you have to create a new repo but if you are doing say patch versions or say minor feature update then it would be sufficient for that or we can talk more about it later after this sure we can catch up in the burst of feathers as well could you could you throw some light into micro frontend what use cases that did you use it for we don't use micro frontend because the micro frontend approach sounds similar to the approach that we have so as I talked to you about dividing the applications into multiple packages you have the application divided into multiple modules so both of these approach sounds similar I wanted to show the difference that we operate at a higher level and this is at the application level so how do you do the application is not a concern for us the application might be using say multiple scrum teams or they might be using single SPA something like that yes you can take follow up questions offline he will be available so how will you get something like code splitting in your node modules kind of framework we provide the boilerplate code which already had this code splitting so you can't code split the code from node modules folder that's not possible so you have to do it in the boilerplate itself you provide the provision to do that in the boilerplate code you can take up later so one more question you are publishing the NPM packages so for example I publish one NPM package which uses React one uses Angular we are using React for this entire approach so you are not having the approach where I can have different kind of packages that I can publish no not currently so for the framework for the applications which are built on different frameworks we are using I didn't get as a single link so for the existing applications like AngularJS the support line is deprecated we are adding it as a link that's it we are not including it as an NPM package yeah so the question that I have is around common services like settings and all so these common services is something that is shared by like most of the components so how do you resolve duplicates like I have a common service which fetches the settings of a user let's say like settings as in it can be anything the default language that I have the preferences part yes and it fetches from somewhere so I have a common services package which does so the common we also have a mono repo but the common problem is if anything changes in the setting service because it is used across all the components either all the components have to upgrade to a new version or there might be multiple versions of the same setting service sitting around in the code which will cause our bundle size to increase so how do you solve this kind of problem so you are saying that the preferences would be a separate package and it is shared by multiple applications yes so that depends upon again the application team so we are working on the framework for supporting these applications if two or three applications have their own individual package then it's their ownership of making it proper versioning you don't we are not concerned about the versions of the packages that they are using those of you who have given your names for flash stocks can you just come forward we will get you set up let's keep the questions going if there are any more also a lot of you have bought t-shirts along with your tickets itself so you need to go and pick them up a lot of t-shirts which are already bought have not been picked up and if you would like to buy react food t-shirts they are available I have a question for you so you mentioned that let the user paste in the configuration and then configuration id could be used to render yes so aren't you making an extra network call in affecting the overall performance for all the pages that are using such things because a configuration id would then load a configuration and then on top of that configuration id is tied to the api anyways you have to make the call to the api to get the first the response data there won't be any extra network call for first to get the configuration and based on the configuration get the data it gets the configuration to load that response data in say pie chart or the line chart is already built in in the boiler plate the extra call that we make is to face the response data which is dynamic for different scenarios you definitely make a call for getting the configurations also right based on the id there is an extra call we have the data required so the data that comes is the data required to visualize that component so if I have the pie chart I need to render three columns I will require the data for that there we make the this network call to face it so isn't it an extra network call affecting the performance or anything of that sort how is it an extra so normal scenario if you want to do if you want to visualize the component you of course have to call to get the data right so configuration in the sense the chart configuration that is built in what we call is for the data render it visualization data hello hi just once this side this side so are you stitching the whole thing on the server side or the client side client side everything is like so the main app loads first and then it loads the smaller apps are there any more questions are there any more questions alright thank you so all the people can can you just comment and fill in the seats like sit next to each other everybody quickly we will just do an activity so that we are not sleepy anymore can we please stand up people stand up yeah just sit next to each other fill up the spaces in every in this rows guys stand up okay standing up Shankar will be giving a flash talk first flash talk now yeah hi everyone I am Shankar I am from Blockstack okay this is exercise not because of me so but this is true this is for you anyone can notice what is this this image so this is going to be a disruptive talk okay this is penopticon it's a jail architecture the reason why I am saying is that we are all living in jail in terms of application development okay and what we are solving is centralization centralization means like say if you take facebook or any application that has been developed today it stores your identity and data it stores its own cloud and doesn't leave that that's the problem of centralization you know this thing happened quite some time we know that facebook it's of a continent it's own where the biggest threat apart from Trump it has been said to Mark Zuckerberg the reason is that he holds all our data and he is kind of ruling it so we are trying to come out of that so how we are solving this is that just see this image this will be useful for this talk so here the data identity is locked in and what we are doing is that we are releasing this identity and data to not be locked in into your application that's what we are doing and say it is based on blockchain so the talk is about how you develop a decentralized app using react this is what it is about and I will quickly run through it so this is the architecture this is the blockchain network it can be Ethereum or Bitcoin anything so whatever application you develop will be sitting in a virtual chain so this is off chain computing is what we are kind of doing and innovating in the block stack so what it helps you to do is that you as a developer you can concentrate only developing on your application for example consider it as a Facebook say why we use Facebook is mainly because to connect with friends and share our post but what really happens is that Facebook owns our data owns our post they sell it that party but imagine that tomorrow Facebook is not there what happens or if you don't want to share your data but you have you got an identity from Facebook and you kind of delete Facebook what happens is you lose all the connection you have made that's right so the application space is storing all the identity and data that is the problem we are trying to solve so this is something an whichever we are built up I will quickly go into the demo I wanted to give okay so this is block stack browser it has an identity for example Shankar dot personal dot ID is my identity this identity is being saved on the blockchain for example you consider it's a bitcoin identity and a name has been mapped to it so what say being at react conference what we do is say consider this is a small app just like a text editor maybe so here I am storing do you like internet where it is decentralized so I am trying to save this post what actually happens is that this post will be saved in a cloud of my own choice okay it will be encrypted and saved in there whereas this data will not be saved in any of the applications or it will not be with respect to application context okay there is one more application I would like to mention is like spring roll here so what happens is similar to LinkedIn where you can create your own private note say if you are sharing with your friends or anything say hi there okay and save it or you can create a reminder or whatever you want say actual data has been stored on AWS cloud but it will be encrypted so for the cloud player the data is just like what you can it's just like a black box for him okay so this is what we have done thank you all I am Saurabh Bairani I work with Druva data solutions I would like to give one small talk on common library Javier covered all the things but in Druva we already did the similar thing and we did it on a huge scale and yeah it's a successful so there are some points engineering pitfall as a developer which you should consider so I wanted to share those with you I haven't prepared anything so please go easy with me okay so as Javier covered what are the problems so example we have three products right now all are migrating to reactjs from older technologies so all are having their own components they are using the same components most of the time like tab or something like that but they are building via their own ways or own approaches so it makes sense to give one library to them which they can use and the whole product of one company should look similar behave similar so like that so that was the one problem which we wanted to solve solution build a library simple one word solution okay but it's not that easy library converts its own problem so I have tried to list down some engineering problems that we faced and we overcome and that we think everyone should consider first one we discuss on this like two or three times in previous sessions about versions so as I raised a question to Javier also suppose team A is using one library having version one one component is having version one and library team try to upgrade it or fix some bug now there are two versions of that particular component so do you want to ask all consumer that is products to upgrade their library no you cannot do that so one thing that you must take care of that these all components they should be backward compatible no other product should break if you update those things so semantic versioning is the perfect choice for that which we eventually landed on that the second one is decision so I want to use example for a tab component but product B says I want tab with these these functionalities and I don't want to use this so you that is a big challenge where you want to where you need to pick all products into same platform agrees them and carve a component which fulfills the needs of all components so that one also a challenge which you should take care of third one is usage so how you ask other products or other consumers to use your particular components from your library so there are two ways either you should the first thing you can do is create a NPM package out of that and ask them to do NPM install whatever your name is and the second approach is which is quite okay to create a Git repo and inside the package.json directly mention that Git repo but a disadvantage that comes with this approach it will be just like dumping the data it will just copy that repo and put it over there so you won't be able to compile the library over there so in that case you can use hooks like post post installation and all that things you can check those with NPM documentations so so these are the things that one should consider while creating a common library on a huge scale so specifically when you have lot of products lot of teams to working on that and they have their own lot of requirements so these are the pitfalls and things that you should consider so that's all I wanted to share sorry I haven't created a proper content or I haven't framed my sentences properly any questions for that no great thank you guys Hello everyone my self is Anand Kumar and I work for Publis recipient so I'll quote one of the presentation that we had recently and they were mentioning about micro frontend right so I'm going to talk about that of course I'm not prepared so but anyway so we mostly we prepare we create the application like single page application which becomes like monolith right and behind that we have microservices which all of us are aware of so what if we can have something similar at the frontend so that is where comes the same thing so it gives us the benefit like we can deploy individually each app small app we can have less regression then build process of course can get more optimized and it also gives us the leverage of having better A B testing right so what we can do with micro frontend so for example one of in the in the talk they were talking about learner right so we can leverage the learner to build small applications to build it at its own it can have its own webpack and all right so it can create its own application the one thing that I want to talk about is the build right so what if we can build the application the small individual application and deploy it to the cloud as a cloud function so if we deploy it as a cloud function what we can get it can be rendered as a server side and we can render it individually also in the browser or what happens is each developer can work on the individual application and they can deploy it they can test it individually and it can be available on cloud itself when I say cloud so like Firebase this supports lambda functions right so what you can do is it can scale it automatically so if your component being hit multiple times and if it needs more memory it can scale automatically to worry about how it is you know behaving on higher loads so that is one of the advantage and that so how it can be stitched together so we have learner we have different applications but how to stitch it so there is come TaylorJS if any one of you have heard about it so we can use TaylorJS which gives you the option to use fragments and you can use fragments to turn on any part of application, small application into page, if you want to insert one insert it, if you want to remove get to remove it so for example I have a home page and I have a header, footer and the content area so what we can do is we can have some kind of template engine where you can compose your page and you can enable any component you can remove, you can add and that template can be served at the server side like it can do the application of your page do the server side rendering and serve the page at the client side so it all becomes very easy to work like a lego so you can put one thing on top of other so yeah I mean so cloud function is the thing and aggregated TaylorJS so you can so one of the project we delivered on this also it was not using TaylorJS but micro frontend we did but yeah I mean if you guys have any questions around this we can talk offline so I mean I'm not prepared for these things but yeah so thank you so much that's all the submitted flash talks we had so some of you, some of us we are frontend engineers and we know a lot of these things and sometimes we wonder you know I could give a talk so before you submit your talk like maybe you want to test out there's an idea in your brain you want to test out the stage for five minutes then we have one more slot for a flash talk so if you have a good idea or an idea just ringing in your head we can allow you to go on unless it's a hiring pitch or a product pitch nobody? okay we'll break for evening tea and then we'll reconvene alright see you guys hi guys welcome back again so we have our next speaker here you might be knowing that there are two BOFs going on one on ARBR applications with React and one more I think on Geekery so if you want to attend that you can go there too our next speaker is Kiran Aburi yeah so he'll be giving a talk on deep dive into Apollo client so the stage is yours hi everyone should I reduce the volume it's fine so hi everyone welcome back for the last set of the talks so I'm Kiran and I work as a freelancer and I also organize ReactJ's Bangalore I hope most of you here are front-end developers so in my opinion there are two main areas in front-end one is UI what I mean by UI is how the app looks or how the app behaves things like styling, animations those sort of things and React does pretty good job with this thing so React is primarily a UI framework and the API and simplicity of React works very well for us so the second important challenge in front-end applications is state management so what I mean by state management is how we fetch data from the server how we manage it on the front-end how we implement business logic how we keep our server in sync with the front-end so there are quite a few unfortunately React does support some sort of state management but it's not meant solely for that things like contest might help but not for very large applications so there are quite a few libraries like Redux, Mobets and quite a few others as well but still even by using these libraries like Redux and Mobets still we have to implement logic on our own even getting state management right with all these libraries is still hard so this is where GraphQL helps so GraphQL has much more structured back-end compared to REST which is kind of not very strict GraphQL has much more structured back-end especially things like type system in the GraphQL and features like introspection GraphQL supports these are my two favorite features of GraphQL features like type system and introspection help us build a lot of tools right and which will help us build better applications with less code Apollo is one such tool which leverages the features of GraphQL and Apollo is by far the most popular client library so GraphQL is something that runs on the server and because of its unique features we can build client-side libraries which leverage the functionality of GraphQL and make our life easy so in this talk I will talk more about GraphQL, Apollo and how it helps even with Apollo it has it simplifies it is much better than Redux or Mobets based applications but it still has its own challenges and I will explain how to walk on those things so in GraphQL or in any back-end based applications like we have three concepts one is queries, mutations and subscriptions queries are used to read data from the server which is equal to get in HTTP and mutations are to modify data on the server which is equivalent to post with the HTTP subscriptions are for real-time updates so if you are building any real-time applications you might be familiar with sockets subscriptions are built on top of sockets to provide real-time applications so let's start with queries and see how Apollo helped with this so this is a simple GraphQL query here you can see in this query we are asking for users with within users we want properties like ID and first name so this is a typical GraphQL query so GraphQL is quite different from the REST in the sense in GraphQL clients ask for what they need in REST we just hit an endpoint and we get the data back but in GraphQL the clients request for what properties it needs for example the users database might have like 10 more properties but the server doesn't return those properties the server returns just the users with ID and first name because that's what GraphQL client ask for right so this is a simple GraphQL query and to use it in our applications we can wrap this with GQL so GQL is a helper function which takes a string GraphQL query and converts into a JavaScript object which we can use it Apollo or any other library so how can we use this query and fetch data from the server and pass it to our components there are couple of ways and so using high-order component is one way so we can import GraphQL from React Apollo and user list is a simple React component which just renders which gets a list of users and renders the users and it's a user list is simple React component and we use a high-order component called GraphQL and we'll wrap our user list component with GraphQL high-order component and pass user query pass user query and so this is the only line of logic we have to write and Apollo takes care of the rest of the things Apollo makes an API call to the server gets the data and pass it to the server like if you are doing the same with Redux or anything so you have to implement using some sort of edge use or fetch you have to make an API call get the response, implement error handling and storing the data in the cache so on and so forth so those things we need not do with Apollo so because of the previous step in addition to fetching the data from the server and passing it to our components we also get loading state and errors and so for example while the request is happening the loading will be true so if you want to show some spinner or something we can do that or if the request fails we get errors we can handle the errors as well and if the request is successful we will get the users data and we can use that to render the company so you can see that without writing much code we were able to get data from the server and use it we are not writing any additional code for managing the loading state or handling errors or fetching the data Apollo is taking care of that automatically all we have to do is write a GraphQL query and wrap our React components with GraphQL queries and Apollo also caches the data in the sense once Apollo makes a request and it stores in the cache and when we render the same component again Apollo doesn't send the same request again and so we need not implement that kind of logic also Apollo takes care of itself and Apollo stores the data very efficiently for example let's say when we when we made a request for the users we got two user objects and it is storing with reference to user one and user two and it stores the user one and user two objects separately so that if some other queries features the same data we need not duplicate the data so this is called data normalization so it stores efficiently and avoid any data duplication if because of some other query if one of these objects are modified the data will be synced across all the components so there won't be any data inconsistencies so if your application is read heavy for example if you are working on some media applications or some content based applications where you read different sort of data and render it on applications then GraphQL and Apollo works great so as you can see we haven't written much code we are writing queries and wrapping our components with that so if you are building dashboards or if you are building content based applications this fits very well so the next part is the mutations where we are making edits and sending so some of the applications where mutations will be heavily used is some sort of CRM based applications where user enters data and the data is saved into the backend of the applications so let's see how Apollo fares with this so to send data to make changes to the server again we write queries these are called mutation queries in this case we are writing update user and to this update user field we are passing arguments so GraphQL query language is quite extensive in the sense it has augments, it has variables it's quite extensive so in this case we are writing variables like arguments like id and first name and in response we want to mutate the server with id1 and first name is called Johnny and once this mutation is once the server got updated we want to get the response back in the response we want id and first name ideally the data will be the same so this is a typical mutation query as you can see in this query we hard-quoted id and first name but in real applications we don't want to do that so we want to use some sort of parameterization so for that we can use things like graphical variables in the sense we have one more layer where after mutation we can give an operation name and in the operation name we can specify the augment types in the sense for example we can say id is of type int and first name is of type string so graphical is a strongly typed long ways so whether it is getting data from the server or specifying the augment it takes care of it takes types very seriously so this query is almost same as the before except that in this case instead of hard-quoting the id and first name we are using parameters so how can we call that query there are several ways to do that so this is one of my favorite way where we will directly call mutate on the client how we get this apollo client during the setup page we will use apollo client library and give the cache and so on and so forth and finally we will get a client library apollo client and that we can directly call mutate and for that we can pass the mutation which is the query which we wrote earlier and pass the variables so these variables will be passed to the query and it will be evaluated on the server and once this mutation is executed we get the response from the server in some sort of dispassion like we get the data inside that we have update user because the mutation field which we sent is update user so in the response object also we get the update user and inside that we have id first name because that's what we ask for and in addition to that we have underscore underscore type name as you can see in my previous cache diagram right so apollo is storing with as references like user one right so so these cache keys are very important because whenever apollo sees some response from the server and if it finds underscore underscore type name and id right it immediately maps with the cache and updates it so we need not write any code in the sense you know we got some response from the GraphQL server apollo automatically understands that okay this data should be updated at that particular location and updates it right we need not write any logic so again this is very helpful and it also supports something called optimistic response let's say for example if you are implementing chart application and you entered something right you want to see that message immediately even before that message went to server and come back right it takes some few milliseconds before even getting response from the server we want to show that response immediately for that we can use this optimistic response in most of the cases we know how the response for example when we are sending a message we know what the message will be right even before coming from the server so we can give you a mock response based on our assumption in this case you know for example update user we are sending id and first name but that's the same response we are going to get back so we can give a mock response as an optimistic response so what apollo does with this thing is it renders the react components twice once before getting the response from the server and once after g