 I work with housing.com and available on web with this ID. So I will be talking about isolated components today. So before we talk about what are these isolated components, let us talk about where it comes from. So in React we know everything is a component and our components comes in different flavors. That is skinny components, smart or dumb components, then you have state full pure components, container of presenter components. And our belief with these components and expectation is that components means separation of concerns, separation of concerns means decoupled system and that leads to a easily maintainable system. So we start creating components all over. So all our application are bundled with different different components. You can see start creating a drop down component, you might have an image component which will load image for you on different resolutions and at different places in your app and some dumb renderer which will render based on your subscription type and button component, modal component and so on. So the problem with these components is that as your application grows your components also start growing like crazy and you might reach to a stage where you will start reusing your components in different places. So you can see the dumb renderer we are reusing at different places but soon you might reach to this stage where you will have so many dependencies of your components and you are no clue what is using what and what is being used by which component or which container component. So at housing we thought to give some meaning to our React components and we call them as isolated components. So what are these isolated components? So we gave them a responsibility of fulfilling our business use cases. So they are not dumb container components which just holds your different presenter components or combination of different dumb renderers and they are truly decoupled because we will be building them in isolation. So they are completely decoupled with your actual application code. You do not get store, you do not get any of your application code. So what business use case we are talking about? So let us say at housing user is browsing a property and he is interested in one of the property. So we will go and try to contact an agent to indicate his interest. So user will try contacting an agent. So first step goes like this like let us verify this user once he submits the details we have to verify him. If he is a verified user no, we will ask him to put an OTP and after OTP verification will submit his details to an agent and we will say and we will reveal agent's details. And in some other case if user is verified we will directly reveal these details to a user. Now there are lots of things happens even after submission right. So we will be pushing some relevant ads as well to a user. Then there is something called based on phone number will log him in to our system. Now you can see logging him based on phone number is also been taken care by another isolated component. So this is how the business use case looks like in your actual app. So user tries to contact, he is filling details not a verified user. So we ask OTP comes you can see here he is logged in and we push some relevant ads and we also think his profile details here right. So how do we create these isolated components? So before we move on to that why what is the reason to create in isolation? So this is a simple example of a contact form where you need to solve a business use case but what if you want to replicate the same logic across your device. So the thing which works on mobile you want to replicate the same business use case on desktop but maybe with a different view layer. Maintaining such complications is not easy right. So the solution to this is create your components in isolation. So we will use a react storybook or react isolate any of these tools to create them in isolation. We will test them in isolation using gest or webdiver IO and at last we bundle it and publish them as an npm model. So this is how you create this is a Kareera storybook it is a playground for creating your isolation this is this we built it in apart from our actual application. Now you can toggle here between different use case like how it will look for a verified user. So I can click on this for verified users and if I toggle back this is how it will look for unverified users right. Now once you build them and you test them like it works fine you bundle them and publish them as an npm model. And wherever you want to use it you just add it as a dependency in your project whether it is your desktop app or whether it is your mobile app. So at housing year back when we moved to PWA we moved our code base we separated out our repose for mobile and desktop. So then it started becoming difficult for us to maintain this kind of business use case to replicate in both the places. So this is where it is helpful for you in a desktop as well as mobile application code and to use it just passing the data it needs. Then it takes care of handling entire thing like whether to show OTP whether to show push relevant ads or what to do or whether to log them in everything is been taken care by this isolated component. So this is the example of one isolated component working across different devices with some relevant ads right. So this is a debatable question like what do you do with your stores like your application will be working on one store. So how does isolated components get access to your application store? So this is a debatable question I will not deep dive into this. But for us what we wanted is we wanted a plug and play mechanism where you just plug a component and it should start working on its own. So we did this created a different store altogether where we just specify key like which key to work on. So with provider create provider you can specify a store key in which key context you should provider should create store for you by default it store and another option for store key where you can say like which context it needs to read store from. Now the question comes is how does two isolated components talk to each other. So you have a login component you have a contact component after contact component you want to make sure that user also gets logged in based on his contact details. So right now we have a callbacks and each and every steps but you can replace them with any event mechanism or dispatch an accident maintenance yeah I mean it's pretty easy for us now we just change things at one place and we upgrade the version and publish them again on npm. So any updates are pretty easy for us test it at one place write it at one place and use it at multiple places yeah keep treating cool stuff so thanks yeah yeah thanks for presentation. You said you use callbacks for them to talk to each other they're using a function as a child and the react component to do that so are you using like a function as a child inside of the react yeah we pass a function okay thanks so to have two components talk to each other there's one component which is like a bridge between two components so this component tells that okay this is the data which I give you then what to do on that data has been taken care by any other component yeah passing data between two components can we have a common repo a common data object and use them across all the components so can you be louder hello yeah so when you are connecting two components right I mean traversing from one component to the other component you are passing the data right so rather than passing the data and we have the data in a common place and use it across multiple components what are you talking about are you talking about two different isolated components or components inside isolated two different isolated components so our idea was not to pollute the global store with these components these components should have their own states and they work on their own now these components eventually will lead to something like contact details leads to a success state where it tells you these are the contact details which got successfully sent now what to do on that is nothing to I mean isolated component doesn't have to be care they don't have to care about all these things so you just tells your main application code that this has been done what to do on that is been taken care about your other components so doesn't make sense to update it I mean my application code might not even update it in the state and I might need it just for a local reference and I might not need to store that as a state does that answer your question hello yeah so while having isolated components where do you maintain your API calls API calls everything so everything is in component so we have different actions all together for this component are you using flux or anything we have a redux store okay hey can you hear me okay good talk man so we actually wanted to do this as well one concern we had was sharing styles between mobile and desktop exactly you showed us a component that kind of look the same we had a problem we have a different build system for mobile and desktop so you kind of extract it out or something yeah what we do is we just ship a transpiled code to a mobile and desktop and then those two different folders take care of that mobile build process will take care of how do you ship it how it will ship and desktop code will take care of how does it ship it to production is there a particular way you guys do this like using normal uh webpack for mobile and normal uh process for desktop thanks a lot so if you have a same build process across your devices like desktop and mobile then it makes sense that when you publish your model that time only you bundle it in a way that uh the way you are both the build process works and then you publish it yeah hello so how do you decide what should be a component like where where is the line between things yeah yes like that I wanted to mention this in a talk so uh complex scenarios like this and when you feel that these kind of things will get replicated so this is just an example which I gave from mobile and desktop but in desktop itself there are different view parts so the way you show pop-up for contact mode in different uh flow user might see it directly rendered in the app so and maybe in a different uh so when you see that it's been reused at multiple places and in some different way but your business logic like core logic of doing things remains same then you know okay this is the trigger point for you to make them isolation yeah I think that was it for questions last question oh do we have one last question all right if you cut into the next speaker's time I'm going to find you much yeah uh have you got components for adjects and promises as well because that's a good standard there are the common libraries we can say but they are not component so component this isolation components uh main uh intent is to solve your business use case how the user flow happens and not uh particular library so library we import uh as a dependency and then it works like some components all right thanks all right thank you very much