Thank you you. It was a good introduction. Hi everybody, i am excited to meet you all here. I am an auditor over there. So i am here to show a little demo on the website that i have built recently. It is a portfolio of mine. Ok, that is enough of the show. So what am i here to share with you all is that I have put my entire website with a nukse framework. What is nukse? యాిలురీ సంట్లాలు క్నుట్చిక్ట్ మాల్ లారురంగుమేనంపులు సంట్పనంపల్ట్వుఖడలిక్రోన సంట్పని మార్చల్టుటింటరుపలు. కాషితోతకి నిత్లె నారిత్ల్లాసంలు సిషింభంచాపి. నిస్లంచాలు ఎలిలూం పురంరంప్స్ పక్ప్వాతి. and I will then hand it over to the MCs who will do a far better job than me about helping you how to navigate the day. So, I am Zaina Bawa. I run Hasgeek.com. Hasgeek.com is a platform for building tech communities and Vue Day is really an outcome of the curators from the community coming forward and saying that we want to run a conference on Vue Day. So, a bit of history for those of you who have come to Hasgeek events before or are familiar with ReactFoo. ReactFoo was the first time where we experimented with trying to get the past speakers to be involved in curating the future editions of the conferences. And from there onwards is where Rahul Kadia and Swapnil Agarwal got involved and the idea was that if we can build a community around React, why can't we build a community around Vue. And it was really at their insistence followed by Hemant and Navya Agarwal who unfortunately is not here today, Hemant will be speaking on stage today. It was really them, Vidya Ramakrishnan, Arnav Gupta and a bunch of others who pushed from the community and said let's run a Vue conference and that's really how Vue Day has come into existence. So, today is Vue Day and that's really because of Rahul Kadia and Swapnil Agarwal, Vidya, Navya, Hemant, Arnav and a bunch of people who pushed and said that this conference has to happen. Now for us, Hasgeek.com is this platform which our goal is to enable curators from the community to come together so that we can put together events and help build communities around technologies and around problem spaces. So feel free to hit us up, to look us up today and see how best we can help you to build your community through Hasgeek.com. And on that note, I'm going to hand it over to the MCs of the conference to help you guide you through the day. Most of us are volunteers who are wearing yellow color lanyats, volunteers and crew. Please do look us up if you have any questions, any suggestions. A final note, all the talks in this conference have been peer reviewed, which means that every talk has gone through a process of reviewing at the idea stage as well as at the articulation stage with two rehearsals at least conducted with every speaker. The reason why I'm mentioning this is because we know that in science, in law and in various other disciplines there is review of research and in technology what we really want is review of practice. And the reason being is because if we are practitioners, we need to be talking to our peers to understand how our approaches are towards solving various problems. And in that spirit and culture and with every conference that happens on Hasgeek.com, we have tried to make sure that even view day is completely peer reviewed. And therefore, if you do have suggestions on how we could help the content become better, how we could put better content that serves your needs, please do talk to us. We really would like to get your suggestions because that is really how we improve on conference after conference. So thank you very much and hope you have a very good day and enjoy yourself. Hello, welcome to view day everyone. I guess we'll start in a bit and before we do that, we do have couple of announcements though to make. So if you have your phone on you, please put them on silent mode or switch them off if that's what you like. Phone's ringing in between talks is going to disturb the speaker and other participants. Participants wearing the lead raniards, red laniards don't want to be photographed. So make sure that you don't do that. And people who are wearing the yellow laniards are anyone you can reach out to for help. Do not bring food and beverages inside the auditorium. It is not allowed and it causes litter. Wi-Fi is provided by BIC. Wi-Fi access, I think all of you have got at the help desk. If you haven't already yet, you can go to help desk and ask for your Wi-Fi access. Now washrooms are located right outside the auditorium, men on the left, women on the right. Next, we have all of you have this badge which has a QR code. And this QR code is for sharing contact information with fellow participants and other sponsors. So you can go to account tab on hasgeek.com after logging in. Click on scan participant badge button to share your contact information. Also do not use the old Android Hasgeek app for this. Scanning has to be done from hasgeek.com website itself. The event tag is hashtag view day, vcaps, dcaps view day. You would like to see pictures from you coming up on Twitter or Facebook or any social media platform that you post. Post them with hashtag view day. You can also tag our handle, which is adderate jsfoo. So tag us in and we will retweet and share it with the entire world. Tag us in tweets and photos as much as you can. Next, we have our platinum sponsor, which is Anitha Designs, who has also sponsored our t-shirts. So if you haven't got the t-shirts yet, please go back to help desk and you can get your t-shirts there. The food code is in the cafeteria on the ground floor. You can buy food tokens outside at the help desk. And remember, you need to do that because no cash transactions are permitted. We also have flash stocks from 210 to 235. Each of the flash stocks are going to be five minutes. So if you have something to present, you can present it within five minutes. We are happy to welcome you on stage. All you have to do is make sure you follow a couple of rules. Number one, you cannot do any hiring or product pitches. Laptops are only allowed if you have a demo to give. And you can do any open source presentations. For example, your site projects or new tool that you have discovered that might help other participants here or other people in that community. And so what you can do is you can write your flash top topic and give your name and phone number to Yadev Yadev who is here. So you can give your name and number on with your topic on a paper to Yadev. And then we will by the lunch time, we'll put it on a whiteboard outside the auditorium. Selecting toss will be announced again around the lunch time. So keep in mind if you want to submit it, submit it now as fast as possible. All right, so we also have laid out the entire presentation, entire day in couple of major categories. And I'm going to go through the categories so you know which sections you would like to go and maybe pay attention to. So the first we have the view keynote where we are going to talk about view and its ecosystem. Then we have talks on component design. That's going to be all the talks before the morning beverage break. After that we have enterprise and scalability. And then we go into the view internals and framework customization. Last we follow a case study where people have used view in production and then we end up with another keynote. So without further ado, I would like to introduce our first keynote speaker. And before that I want to give you some context. Now view as a community has grown worldwide, right? From being a humble library to a full-fledged framework, it has come a long, long way. Sopnil who is here to get us insights from the current state of the view ecosystem. So let's welcome him onto the stage. So hello everyone. Super excited to be here at India's first large scale view conference. And we have been pushing for this to happen for quite some time now. As I mentioned, we have done a lot of effort in getting the word out, getting drop proposals and getting view. View lovers from different parts of the country. So let's start by taking a look at the current state of the view ecosystem, its community aspects and some of the recent technical developments. So sit back, relax and enjoy the view. So a brief history. View was created by Evan Yu. He was working for Google in AngularJS for a number of projects. So in his own words, he figured what if he could just extract the part that he really liked about Angular and build something really like we don't talk about it. And voila, view was born. So view is a JavaScript framework. Yes, it's also progressive in nature. So if you're building user interfaces, it proves to be a great choice. And you don't have to take a word for it.  You'll always hear positive things about you. And by design, it's very easy to pick up and like this is this comes with contrast to other monolithic frameworks where typically you would have to do a full migration. So as we'll see in the upcoming talks today, view is not just suited for quick prototyping. It's perfectly capable of powering large scale applications as well. So what's the buzz around VueJS anyway? In mid-2018, Vue became the most start JavaScript framework on GitHub. And earlier this year, Vue became the second most start project on GitHub. That is across all languages. And that's just only behind free code camp. So, Vue. Now, I'm not saying that more GitHub stars equals more usage. It's just that Vue is no longer the new kid on the block and is definitely worth checking out. Let's see some of the adoption numbers. Vue has over a million weekly downloads on NPM. And not only that, it has more than 900,000 weekly active developers users. So developers is a browser extension which helps you in debugging. So this number like really represents the large group of the developer community. And from my point of view, this is more significant than the first number because the NPM downloads can include a variety of use cases, right? It can include numbers, downloads from automated CI bands, robots, downloads of packages for their analysis purposes, etc. But DevTools provide a leading indicator of what's going to come. So these 900,000 users are using Vue in their day-to-day development work. And a significant number of them are going to write more of their future applications in Vue. Now, these are the number of hits on the JS Deliver CDN. So if you see the Nth place, Vue has over 900 million hits in the last 30 days. That's more than 30 million hits a day. That's pretty huge, right? And if you compare it with the NPM downloads number, this is like way, way higher. And that is because Vue provides a drop-in solution as well. You could just add the CDN file, the script app, and any application, any web application, you're ready to use the power of Vue. Now, the two other numbers to note here are the jQuery and Bootstrap numbers, the 7th and 8th places here. And if you compare the numbers, that's pretty close. What do you think? So, okay, no more numbers now. Let's move on to something real. Who uses Vue in it? So for starters, Laravel is the one who started Vue's adoption. Then we have GitLab, who was again one of the early adopters of Vue. Vance uses Vue, Apple is using Vue, and the list goes on and on. Now, one of the other frequently asked question is that is anyone using Vue in India? Yes, the answer is yes. You have started seeing adoption in India, and some of the companies using Vue are Pola, Vue's story, Zoomcar, Soul Store, and many more. So, the key point I'm trying to make here is that Vue is now already being used by many of your peers. And this makes the case, like you're considering going to Vue, this case, this makes the case for using Vue in your organization a lot easier. But, does it have an active community? So, I'm proud to say that Vue is back, Vue Bangalore's community is now 2 years old. In over 900 members, you can find the link at blr.vue.community. I'm hoping we hit the 1000 member mark by the end of today. And we host regular monthly meetups covering a variety of topics. And more importantly, this means that if you face any problem in your day-to-day development, you have people you can reach out to for help. And that's pretty powerful. And other cities like Hyderabad, Delhi, and Tune are falling soon and have growing companies. Vue looks right. Let's move on to the technical side. So, Macross is the code name of the latest release of Vue, which is version 2.6. And there's an interesting naming convention here. So, every big release is named after an anime with the X letter of the alphabet. So, like in the past, we've had a ghost in the shell and dragon ball as well. So, you're welcome to place a bet on what the next one might be. And if you're just getting bored someday, you could just want a curated selection of anime to binge watch, open the releases and go through that. So, let's see what it brings. One of the most important things that was released in Vue 2.6 is the new slot syntax. We hide an RFC for it and we'll talk more about it a bit. It also comes with an improved asynchronous error handling. So, if you are using sync functions in your life cycle hooks, the errors during those processes will now be captured by Vue's error handlers. And you'll also be able to send these numbers to... Like, you can handle them, you can monitor them, you can maybe send these numbers to sentry to anything. This also releases... This release also improves the compiler error messages. So, now if you're making any syntax error in your template, Vue actually points you to the code frame where you have made those. And an important point worth highlighting here is that this feature was contributed by a community member. Finally, we have the built-in data-prepared support during server-side rendering. And this is pretty important for solutions because up until now, there was a restriction that can only place your data-patching logic in the top-level round component or in the specific component otherwise, that will be a skill. And in Vue 2.6, we have removed that. You can place your logic anywhere in your component tree. And this also allows higher-order solutions like NUXT to leverage this to simplify their implementation and make things easier for you. So, overall, it will result in a better development experience for anyone using server-side rendering applications. So, we talked about RFC. What's an RFC? RFC is a request for comments process. This is a framework for proposing changes in Vue. So, you can just look. For beginners, this is a way to get involved with the community. You can go visit this link on GitHub and propose any ideas you have on how to improve Vue. There are open proposals as well where you can participate in discussions and programming. So, this makes things open in the sense that now, you have an opportunity to voice your opinion. If the coding, let's say, misses an edge case, you can point it out. And now, like from now on, all of the breaking changes go through RFCs. So, it's a very good place to keep an eye on. Now, let's take a look on some of the recent RFCs. So, the new slot syntax that was introduced in 2.6. So, let's see what it brings. So, for scope slots, it brings more clear syntax. We'll see some examples on what that means. And when you're using name slots, this brings more uniform experience. That's also in line with improving DX or development experience. So, let's see some examples on how this unification looks like. So, this is how... So, the first put-up shows how we used to define a default slot with text default. And the bottom one shows the new proposal. So, when you even wanted to just pass a text in a slot, you would have had to wrap it inside a template attribute and then you would have named it. You are passing the proxy. And now, with the introduction of vslot directive, you can just bypass that altogether. You can just add that vslot directive to the component itself. And this makes things easier. Now, if you don't have text, if you have an element inside... So, here is an example where the message is rendered inside a div. So, this also makes like similar to the previous one where you just put the directive on the component. And using the template syntax, the prop gets rendered inside the div attribute. And here is an example of named slots. So, notice how we have had to define two attributes one slot, one slot equal to one defines the name and the slot scope. This is now replaced by vslot colon the slot name. And this is where I was talking about the unification and consistency experience. Everything else is there. Now, let's move on to another RFC. This is a bit of a controversial one because this has made some headlines recently and some even called it use darkest day. So, let's see what happens. So, this is an example of a component where the logic is you have a count variable you have a double variable which is supposed to store the count into 2 and you have a button where on click it has to increment the count variables by by. And this is how we are used to writing the script right now. We export it in a data variable we write the method increment in a data variable. This is what was proposed you define the constants count double and increment and just return everything and the initial reaction including mine was this is quite complicated and it goes against the principle of the whole point of view is like it's simple and this is not simple and so, we had a lot of discussions and there were some modifications made and there are some key things which I want to clear this change is purely additive to 2.x it doesn't break anything you don't have to rewrite anything if you don't want to I just keep using view the way you are using and there is no plan of duplicating the object right now and here is the revised rfc note how the view had taken suggestions from the community and discarded the previous rfc and this is the revised rfc and it makes things simpler by retaining the benefits of logic views and better typing and this is the rfc that was closed where you have everything count double and increment different and this is the new proposed rfc it was opened quite recently like 2 weeks back and to emphasize again this is an open state and you can join the discussion on github right now so, this is like all in line with the current syntax where you have a state object which includes everything your data and comfortable you have a function and you return that so, let's quickly take a look at some of the other things everyone needs a mobile app nowadays so for building those we have solutions like github script view and weeks and we have also maturing coder-based solutions like chasar, anik4 and oncg1 chasar recently released a 1.0 version earlier, sometime this year and it's really impressive you should check it out quickly moving on to server side rendering it's been on the rise in recent years so, because of the benefits it provides better seo and faster time to go on and the view ecosystem is also sorted on ssr extend the pndsq plugin are the most popular choices for achievements so, coming to sustainability as github stars don't pay the bills and one of the major difference which makes view stand out is that it's not backed by any corporate but the challenge that comes with this is sustainability on how do we get people to continue working on this making sure the quality is not compromised so, even as a patron to fund this full time work on view and there's also an open collective which is backed by the community which fund the work by other co-team members so, in terms of sustainability I would say it's a good shape and it's going to stay so, to summarize view is getting more popular day by day and has started getting adoption people around view are either already using view or learning view the latest release of 2.6 has brought some performance improvements as well its view is flexible now, this is an important point the flexibility is in the sense that it doesn't force you to use any particular templates and tags or even typescript you can just use against stylus if you don't like closing a single tags it's very flexible in that the mobile ecosystem is quite mature now and is ready to take on your requirements thus, it's sustainable so, it's here to stay for a long time and view 3 is coming so, despite what you may have heard it doesn't force you to use type script it's your choice as develop experience has always been of utmost important use books and today's closing talk will do more details about it stay tuned and that's not from my side my name is Swapnil and you can find me at swapnil.net thanks everyone for being here and have a different day let's have a big hand for Swapnil and I hope that talk gave you an idea how many of you are in the community and if you want to consider view for your next project at your company this might be a good start you should probably pitch this to your project managers and now we'll move on to our talks so, as I promised, our theme for the next couple of talks is component design so, how many of you are building or using any kind of component design like element UI or view material or beautify a lot of people because we need them a lot and building a component design is not easy building a component library is not easy so, we have Divyam who is here from Flock who has built component libraries from Flock and who is going to take us through his journey on how he has made stuff work there alright, let's welcome Divyam hi folks good morning to everyone such a full house today is everyone late or what alright so, the topic that I am going to present today is creating a musical UJS component library and a quick introduction about myself I am Divyam Rasaghi I am a senior application engineer at Flock and I have got 6 years of front-end development experience so, the problem statement that I the problem that I faced was that most organizations they have a design language of their own that they have some primary, secondary colors some components that have a very distinctive look and feel so what happens is that you tend to have components like these so, you have got form elements you have got buttons so, this is a very just one page from our style guide and the thing is that we tend to have duplicate code when it comes to writing components across apps across dashboards so the problem with multiple dashboards and web applications is that they end up looking alike for an organization but at the same time we tend to copy paste those components for example, I used to do that too and what we would do is we would just copy some component from one repo and then paste it into another so the problem with that is that say you have got three repos and you copy paste the same component into those three repositories and then you suddenly realize that there is a bug in one of those in all three of those repositories and when you fix that bug you get to fix that everywhere you get to fix it push the code in all three repositories and then and then what happens is that you are basically doing a lot more so this is an excerpt from an article I wrote about why I built a component library and I wanted to point out the highlighted portion this was the most highlighted portion on medium.com from that article it says that there was a need for all why components should be consistent with the theme and colors of the application pre-built components which adhere to the design theme would make development much faster and definitely more fun so that is the reason I built a component library for Flock and using Vueges so what do you say to duplicate code like every time you think that okay I am going to copy this code and paste it into another repository what should you say not today this is definitely what you should say so is it hard to create your own library like using using Vue CLI well without Vue CLI it is actually a little bit harder meaning that you will have to configure your build process using webpack or rollup or whatever you want to use and and then you will have to build a lot of things on your own so without the Vue CLI it is a bit hard but with Vue CLI it is not as hard so that is what I wanted to talk to you about today so where do we start building these components and this component library that we keep talking about we start by writing our components and where do we start writing those components in a project that we create using Vue CLI so is that it well let's just see so step one is to create your components and there are like there are some concerns while creating your own components right like you need to make sure that you are making them extensible but at the same time you don't want to over engineer them like you don't want to over engineer for cases that you might never encounter so make them extensible so that if you want to change them later it should not be as hard and preferably write unit tests because in case like you are unknowingly breaking a core feature of your component then that unit test should tell you that you are breaking something so like there is a tool called storybook and you could explore that as well storybook enables you to run your it runs alongside your development environment and then you can basically use storybook to build standalone components like aside from your whole development process and accessibility so there is a web AIM accessibility checklist that you want to make sure that your components work for people who are visually challenged as well so this is a checklist and there is a link here you could check that out so this is an example of a link component and I know I have been talking about accessibility and this component is definitely not sensible right now and it is just a simple SFC and this is just a very basic example so the step 2 is to export your files through an entry point this is a very important step because this is where the view CLI will know that these are the components that you are going to be exporting and so basically what you could do is you could have an index.js in your source and export all components using the snippet that is visible here and step 3 is basically setting up your library build process you could just change your npm build script to view CLI service build and give it a target as live basically this this is the view CLI to build a component library in live mode to build it in the live mode and you get to give it a name as well and an entry point so this is the same entry point that we talked about here and the output will look something like this so we are going to talk about the common JS module here and that is what I am going to show you in an example as well so the step 4 is that you have to package your stuff like you have to tell how how view JS will find how you are how when you are using your library how the user will find that particular file so what you need to do is you need to add an attribute files to your package or JSON which is an array of strings and these files are the ones that will get exported when you publish your package to either npm or yarn so you also have to add your name to the library the name field of package.json because that is where that is what will be visible on the npm repository so the entry point is like main the build, the bundle that you built here because we are going to talk about common JS here and this is how you import your component and then you use it like a regular component so how do you publish your library well you have to like you would preferably write a script to publish your library like a simple shell script that basically does the following you have to publish it in public mode so that everyone you want can use the library and this command will publish your library to npm but first you will have to definitely create a user on npm you could do that using npm add user or if you already have an npm account you could do npm login into the terminal and then publish this so you could actually integrate this whole thing into a build process as well on a build machine like gocd perhaps and then all of this gets automated so how do you use your library all you need to do is just install it from npm like npm ai and save as a dependency and the name of your library so install it as usual and use the component as you would normally use a view component but there are limitations when it comes to like new cli right now on-demand loading is not currently supported when it comes to the common js bundle and but this can be overcome by using something called lerna lerna is a tool for managing javascript projects with multiple packages what you will be doing basically when you use lerna is you will be publishing your link component as a separate library itself and if you have custom select as well then you will be publishing it as another component and then you will get the user like the usual way so semantic versioning let's talk about semantic versioning basically if you are making breaking changes if you are making major changes just bump up the version of your library like the first decimal and that's how you end up with semantic versioning if you are making minor changes just bump up the second decimal or the third decimal another limitation is that assets like svgs they have to be inline into your view components because like currently vuceli does not support that getting images from your folders so these are some tools lerna and storybook you can build monorepos using lerna and using storybook you can build your components independently and test them out so any questions and answers now yeah alright when you say web and the mobile do you mean a mobile application or do you mean the mobile web mobile application you want to use it on the mobile app so it should ideally work the same way as you are using it on the web because the view ecosystem allows you can have you are probably talking about the views as you when you are building a mobile app are you talking about the views or are you talking about native web apps native web apps okay native web apps I am not entirely sure about native web apps at this point so I don't think I will be able to answer that okay no problem our solutions for creating libraries are difficult is there some other that picked up your interest or some that you would definitely not recommend for those who are wondering to choose other options you mentioned that there are other solutions that we could use to create our library and other view CLI are there solutions that you tried yourself and were more or less satisfied with or some that you would definitely not recommend based on your experience if you have a small library maybe 10-12 components in the library does not exceed 30 pages then I would want it to I would directly use view CLI for that but if we have a library of components that is huge in number for example if we are building something like material design component and your organization has that two states use learna to build mono reports what learna does is it publishes all components with their own versions on to India so that you could automate that and that would solve that use this as well does that answer your question with view CLI can we like have like single component library and use it for multiple projects is like plugin and like exactly exactly that is can be used for that is the main use but we cannot use it on a scale or a component which a large size of components which you said if you have many many components then the common js bundle will become big and that could reduce your first load time so ideally that is not advised if you have a lot of confidence but if you have a very few number of confidence my maximum library size has been around so I was fine with that behind have you worked with nested libraries of any kind like you have built components in a library and then you compose them on to a upper level component and then automated the build process so that everything gets updated that is fairly simple like if you have you could even have nested components so in if you I'll add a link to the repository that I built we have a modal component that is like using composition to from another generic modal component and using composition to make that component and it is in the library as a component so both of them generic modal and modal they are both components and they can be used from the library so yeah it is possible okay we can take one more question so as you said we can have small components and if they are smaller in numbers like 10, 15, 20 but what if like 10 to 15 components we have they are big not small components like button use if they are bigger in size not just small components usually base components are small in size in my experience but if you have bigger components like learner is for you so you can check that out learner is a really good tool I recently discovered it like when we were reviewing our presentation my ex told me about learner and that's how I came to know about it learner is good based on our experience based on our experience from the existing libraries which one picked your interest the most which one made you most impressed if we are talking about the build process the custom build process created specifically for those libraries right now as of now there aren't a lot of libraries for views there there have been a few libraries now since 2019 but so I haven't actually had a look at a lot of libraries but I've used I've used some like I've used material design for view so and there is a library built by Chris he had published it on GitHub and that was a really good starting point I really learnt a lot by looking at this code thank you guys so if you have more questions you can take up the devium offline now we'll move on to something which like as a front-end developer you have been seeing these for a long time forms so you can't escape forms there have been a lot of repeated business logic in forms so Bhartwaj is here to talk about his two-year journey of handling forms in their view applications please put a big hand for Bhartwaj hi folks I'm very excited to be here I'm from Chennai who are from Chennai? is your hands? not many so this is my first view conference so today we are going to see a board like using building form components using VueJS in a dot scale application so I am Bhartwaj I am a front-end engineer at ChargeB so a little bit about ChargeB ChargeB is a subscription management platform that helps your anti-angle, recurring revenue business from speculative building so basically we take care of the subscription part of your application so we are about like 9000 customers in 50 countries and we support more than 5000 customers so today's topic we will be speaking about two things why a company like ChargeB as I was asking about ChargeB chose Vue as its Vue layer and we will be talking about the forms what are the problems we faced and how we solved it we chose like there are multiple factors when we consider like two years back we had an option whether to choose react or angle or view popular at the time so we were just bubbling up there are like many factors we considered one such factor is a fast learning curve at the time we are like about 60 developers most of them were expert in Java and our textbook was like Java Enterprise edition with JSP for the front-end engineer so we don't have any like expert in Java script expert in HTML CSS so we have like traditional HTML developers and CSS developers it's since it's easily approachable and it was easy to onboard a new hire so let's say a fresher joins a team and he was able to deliver within a day so it doesn't take any steep learning curve it's very easy to learn and one more thing was like documentation part so when you compare it with angular or react so I would suggest like VueJ's documentation is pretty clear and simple so you can easily understand because new to the single-page application can easily understand starting point to learn a single-page application or just works versatile since I said our app was like a monolithic sound year old legacy application with lot of edge cases and complex logic building logic and we want to choose a framework and we don't want to sit and like sit to sound months and revamping the entire product we want to choose a framework that integrates with the existing app and we are able to deliver within a month within a month so previously if you are developing a complex animation with jQuery or javascript or any other part of it it will take time so chargebee is like a user experience focus company and we have like user experience we focus on user experience and we have like complex animation logic so with view js we were able to deliver we were able to develop within a single day like previously we were taking about 3-4 days to develop a animation so it became very easy to develop because of the animation books the view provides so end of the day as a business matter it is how fast you deliver design principles so we choose because like the decoupled html css js that comes out of the box of view since view is very flexible so instead of writing in react and having a jsx so we had html css developer who doesn't want to write css in js so that's why we choose view this was major selling point to our investors and cto single file components the template part it was very easy like to debug and manage and maintain the application and the final part was the dependency tracking system so at that time since like view is not backed by any big product companies and there was no any patterns at that time and it was just wobbling up so charge bill loves philosophy so what happens after 2 years even if you drops a project and goes to another project so since we went to the source code and we were able to understand easily how does a view works so even if that stopped we were able to pick it up and then continue it that's a major point for every enterprise company so as community driven we have rfc so when compared to other frameworks view is something like that is community driven there is rfc once rfc is approved by every most of developers once it gets upward and only then it will be moved to the version so we will come into the performance so you don't have to do anything people the performance of the view it comes out of the box when compared to react where you have to write in such a way code you optimize the code so react doesn't do for it for you so view does out of the box doesn't do it so lesson says when compared to other frameworks so in charge view there is a web console as well as the checkout pages so that the checkout page runs on third part our customers end so we want something that is lightweight so we chose view finally it shoots are nearly we have been using view for last 2 years and we didn't find any problem even if the problem comes we were able to solve it using view we were able to harness the power of view so that's how view is flexible for well building forms that has more than 10 form fields and each form field has relationship between other form fields and it's not just normal text let's assume like we have currency input date picker time with time zone support it's pretty hard to manage and maintain it and even write unit spaces this is Anthony got many of you know about him like we have viewjust developer he's a CEO of viewjustdeveloper .com website and he's writing a book on building enterprise application using viewjs so this is his read from him so he says like building very big forms using component based library let's say even view, react or angular it's very difficult to it's not maintainable that's what he says so this is like a normal form average form in charge view so this is not a norm generic form where you have a form builder and then normal template like we have like animations as a relationship and there's logic going behind we'll be having a API call to the back end to fetch some data this is how it looks and this is not a generic template pattern each form behaves in a different way so let's dive into building form so this is from viewjust documentation website if you're building a form so like as a input field the username and we have the options for that as a binding to the username so the template field has username field and the submit button and the form has the callback submit form and you're making this is a normal basic form in a viewjust application so let's assume you're building a form with client-side validation so let me go to the code pen and how it looks like so here we have the input field and and we have the email field and we have the option select option fields so this is so here we have the validation so we have the bindings here and we have the errors part that displays the that will enter the errors if it does so on clicking submit we will have the post check form the check form function checks whether name is required name is there email is there and check the email length and for valid email we have a regex so this is how it looks like so when I enter submit so this is like building a basic naive approach of having a form with basic validations without using any third-party libraries or any modeling so let's build let's look at client-side validation so this form so basically we have the same as before the only thing new is we are making an API call on the response of the API call we are pushing the errors to to render it in the error array so let's look at the community plugins available so view form is a form validation library so this is a popular library so you can find an awesome view so we validate it's a template based validation library I'll show you an example of it and view form generator is something like a form generator that generates components for using a JSON okay so these are three variants you can find so let's see how to build up what if we build up form using view form library so here we have the binding fields name, password and from password and if you look at the template this is a sample template of our form field will look like when you use a form view form so basically the entire form has been covered by view form in the template and we have a validate that covers the that wraps the input field and we have field messages that renders the if there are any messages for the particular field input tag that's it it's a simple as that so the response will contain something like this for each field we'll have a name what's the depth, the depth is valid invalid so all this kind of stuff so the render part is something that's very simple we have let these three fields name, password and confirm password that's it okay so if you submit without so each errors will be mapped to the particular field it's simple as that so you guys went through all the examples so what we found so validations are duplicated in client-side in backend-side so basically any form, any post-action will have a validation to the server-side it's the best practice to do a validation of both client and server-side so here the validation part is duplicated in the server-side as well as in the server-side what if like it's very difficult to maintain on a application that has 100 plus forms where each form field is very important the mission-critical application the second part is handling server error messages you can see like the component that holds the form handles the way it displays the error messages so that will be duplicated in all the places let's say each component level like slight variations of it but at the end of the day like you'll be duplicating the same code everywhere spaghetti code let's assume if a form contains like 12 plus form fields and let's assume based on the value of the and entered in the first field the like fifth field or sixth field get rendered or the options get changed in that case the validation and submission part are shared between the parent and site anyway you won't be keeping the entire form in single component so we'll have some ugly reps and then we'll be calling the child it's like an antipart and it won't be it won't be easy to test it that's what the fourth point says so how do you write a so it's very difficult to write a unit test so how do you test basically like the business logic of the form field so it's quite difficult and it's not scalable so any product will have it will grow will have new features so the number of form fields and the components keeps on growing it never stops so let's assume the form based so what our goal should be like it should be simple it should be maintainable it should be easier to test it should be dry and it's flexible to add up it's very requirement in the future demo so we're going to be building a simple form field a form like having a phone number that has a master input and a password field that's a simple example of a form so let's look at the structure of the form component structure look like so we'll be having a form and we'll have being a form field form that's a render less component that wraps the form field this is the actual form field which renders the UI so each component takes care of a different business logic it has a different role let me work through each one of them feel it takes care of the rendering point and so it's a single it's a source of truth right it interacts with the form so it will limit events all this to the parent thing it can work independently it doesn't want to have a form wrapper for each and everything it just want a search field or a normal unit and it can have a custom masking logic too field form here it's a wrapper container component I think fancy so on creation it registers the form so basically we'll be moving the entire form state to the store we'll be maintaining the form state to store so that any part of application can interact with the store and get the values from the form so on creation like on the lifecycle hook of the form for field form component so it registers the particular field to the store and it will attach a listeners to the field and it on validates it takes care of the validation and updates the store so this component is the one that interacts with the store not the field component so on destroy it removes the field from the store so this how it interacts with so basically the role of the field form component is to interact with the store and update nothing doesn't do any doesn't transform the large value or anything sort of that actual form component so basically on creation it registers itself to the store and it takes care of loading the validation part from the client side out from the back end so basically in charge we load validation either from open AP spec so we are AP first company we'll be loading the we'll be writing spec so we'll be generating validation from this open AP spec so we use the stagger for it and since it's a legacy app so basically we will dynamically generate the form field validations from the back end app so we have a framework that supports it that gives the form lots of form fields and the validation let it to it so either way we can load it it takes care of the form submission part so on destroy it removes object from the store form object from the store let's see the working demo let me show you the example and then let's walk through what is basically cannot be blank so this side works okay so let me walk through the core working logic so on one what's happening is we have a form store and we have form so form creates the sign of form let's assume that's a sign of form that sign of form gets loaded to the form store along with the validators so this is a text field form what we see in the phone number field like the normal text field and the possible is also a text field with the custom type so your phone number gets registered inside the sign of form and we have the text field that gets rendered into the UI that's it let's see what happens on user input let's assume the user interacts with the text field the value gets sanitized and then image to the parent the parent is the wrapper form field so it renders the so basically in certain containers we'll be loading the form values to the form so it takes care of that part too so text field form updates the form store on every event from the text field so it takes the validation and updates the form state so let's say like in a form field we have like error state so this takes care of the validation part so on destroy text field form daily it's a form phone number text field from the sign of form so basically I showed a demo previously right so where we have a in a sample form in charge we we have a template that goes beyond back and forth so in that case let's assume a field that gets unmounted will automatically get removed from the form store so we don't have to write the logic hey remove this form field from the store or remove this form field from the form state that contains that component that contains the form state it works automatically form deleter form on destroy form deleter form store nothing fancy here that's it the reason why we chose this approach is in check code as I said in check code where again a rend developers like the was integrating check code through other site can modify the styles of the form custom masking logic validation everything and the problem we had was why can't we go with the form generator the problem is if you go with the form generator then we will be following a generic pattern of the form field like a non-generic traditional form but if you look at our app we have a custom template we can't we don't know like what will be the template of the HTML part we will have a section down there we will have a link there and a text and the heading so it was very difficult to dynamically render the HTML template part so what we did we hard coded the template in the HTML and whether to show the field or not comes dynamically from the business logic that's the basic in the nutshell we had done it so this is like as I said in validation so the right left hand side we can find the open IP spec this is one of the form fields that handles currencies so here we have refund amount as an indigent format is money value so we can easily validate whether it's a valid money for in a format or what kind of it can be anything so basically we use open IP spec for this kind of things the standard pattern on the right side is the way what the form validates and then we dynamically load into the store what are the key takeaways separation of concerns so we can see each layer takes care of a particular part so it's very easy to test and we can say like this this component does this one even for a fresher let's assume we have like 100 plus form components and in every page it works differently it's very difficult for a fresher to go and modify it with this approach like we are able to it can easily say hey this component does this one nothing fancy or nothing other than that so basically we use the we didn't go for a custom logic or something from the outside like patterns or libraries we use whatever available in the view so any problem arises so we as a solution for it is very flexible it has a solution inside it you have just to find out follow APFS development for any form fields otherwise it's kind of messy it will be like a spaghetti code in the end and make it developer friendly even for a fresher if you look at the code they should feel like hey it's very easy to modify it and test it so that was the core point of this talk thanks like any questions like we have like regarding charge b or view or forms we can take about 5 questions so I had one confusion so the first time when the form loads how do you manage the state so suppose we have 20 forms in our page 20 forms 20 forms so we have login sign up this and that and 20 so how do you manage the state in that it has a separate object let's assume there's a state object and the sign form is a child object say it's an object we will dynamically register it and re-register it so that any page can interact with it let's assume any component somewhere in the page can interact with it and let's assume what value does it store that has separate state and everything and in that particular state you have all the 20 forms thank you hi so your approach has a hard dependency on the store store being the view extor basically can use view extor or you can use the observables as well okay so do you think what is the right approach to let's say if we try to make this approach as a generic one let's say we publish this library and at this point the library or the architecture would have a hard dependency on the store object store being the view extor so how do you try to make it generic because the store could be at an enterprise level applications could be fragmented into different modules okay in that case you would be trouble in the name module space or could be at just root level module space you could try to identify and register or try to solve that problem so end of the view extor is also like a normal view component that has a reactivity and we have some flux path so you can use let the macro version of view as a view observable thing and you can use it as a state object and then interact with it end of this reactivity okay so in that case so the approach will still have a third party dependency view observable right no we have exposes own it's a stone API we look at the documentation you can find it okay it's there in the at my workplace we also deal with lots of huge forms and this has been a recurring issue so the approach that we took towards sort of at least managing the form definition to go with very descriptive JSON representation of the entire form including each of the element as well as the relationships that would go and the rules that would bind all of them together and then we use this JSON representation both on the client side and the server side to make sure that we are able to both validate the form with same validation rules both on the client side and the server side along with making sure that we are able to upgrade components as well as form systematically across our applications making sure that everywhere every you know we are able to push that update everywhere so I just wanted to get your opinion on how I mean you find this approach compared to how you have been going about handling larger forms okay to surprise what you said so basically you are using JSON form like a form JSON representation much descriptive one which has everything right from the how to style that particular element to the validation rules that would apply or some binding rules to other elements within that form like so high rules and stuff like that so basically form generator if you give the form JSON builder it builds a form for you and that is the validation more or less kind of so a builder or we have a custom script that generates towards JSON depending upon the requirement actually it depends upon the scenarios let us assume in your case for let us take a checkbox and a text so it will be same across your app but in our use case was like our designing based upon the scenarios in the use case we are different styling and different way the HTML structure so we cannot then the JSON will become very complex and it won't be developer friendly and it will be like what JSON is going to do so your approach is depends upon the scenario your approach is generic and right in your use case if you have a generic form fields like this is the input field this is the checkbox and this is the select box this is how it works and this is the relationship it picks in that case it is correct but in our case it was pretty complex and difficult okay thank you we can take one last question hi could you like highlight some of the key differences between bootstrap view forms and this view form package apart from the dependency on the store okay so this doesn't have a basically in chat we have our own library we don't we don't use like bootstrap or any other so this doesn't it depends on the template it's up to you so the developer defines the template so this is what nothing but the thinking of the logic between the store and the component so previously this logic will be present inside the component itself so we move it make it try and then move to store so found a generic pattern so this is how it works so thanks Bharathwaj thanks for the talk on forms and we are now going to break for the morning beverage break but before that we have couple of announcements number one we have Gusto here who has been travelling around the world on all the view day events so if you are going out please talk to him go ahead and meet share and get his share of experience we also have Rahul here who is a core team member from view so you can talk to him about all the stuff that's coming up and remember while you are out go do networking but do not take photographs of people wearing red lanyards so respect their privacy and Wi-Fi is provided by BIC so if you want Wi-Fi access you can just go over to the helplex and take that also while you are networking you also have QR code on your badges use hasgig.com's app to scan your badges and get contact information from fellow participants our social even hashtag is view day capital VUE capital DAY do tag us in tweets and photos you are posting and our twitter handle is js4 thanks to our platinum sponsor which is Anitha Design for sponsoring our t-shirts if you haven't collected them yet you can go out near the help desk and collect them thanks to our exhibition sponsor publicity sapient and our community sponsor netrullify for making all of this happen last announcement we have flash stocks planned from 210 to 235 p.m so these are like 5 flash stocks of 5 minutes each you can present anything but our laptops are allowed only if you have a demo to show the rules are that you cannot do a product or a hiring pitch you can do an open source presentation, your site project a new tool that you have discovered or an insight that you want to share with the community for participating in that you can write the topic and your name and phone number on a slip of paper and hand it over to the hall manager and selected talks will be announced on the white boards outside the audience during lunchtime so yeah we are going to break now so please be back on time because when we come back we have a lightning talk on next and we will have our talks themed on enterprise and scalability thank you check check yeah it's coming right maybe you can ask that guy yeah check cool good morning everyone so yeah we all are very excited for the view day conference here today yeah cool mic testing one two three so sorry hello do you know what the matrix is hello hello hello so welcome everybody back into the auditorium we now have the lightning talk that we talked about on next js which is going to be presented by rupa here and we also have got two two submissions for flash talks and we are just looking for three more so if you haven't submitted yet and you are planning or contemplating to talk just submit it to yadav here so we will go ahead with the lightning talk and then come up with our talks based on the theme enterprise and scalability so let's hear rupa out hey everybody am i audible okay i am rupa i work with freshworks and i am from chennai and i am really thrilled and excited to see you all so what i am going to talk about today i am going to talk about how i build my blog site with nuxed and markdown first let me answer something why nuxed and why markdown it's not going to be why should developer have a blog never going to open that door so why nuxed so as what sapnel suggest as what sapnel was talking about nuxed is a static site generator for supporting view and it has got all the performance modular architecture on top of all it is it gives an amazing developer experience to put it in a short term like how we have gatsby for react we have nuxed for view so second view why markdown i personally love the way it keeps your file clean and you can have all the code snippets say html content or jace inside your markdown files precisely it's like a diary for developer so that's why i chose markdown so why has been answered now let me go to how did i build this one so this is my blog site this is my website and this is the entire blog that i have i did this with the help of a library frontmattermarkdownloader why did i choose this library to build the markdown say apparently when i am using the nuxed framework i need some parser you have dynamic routing and you have the file parser like asynchronous file data reading in the nuxed something different to parse the markdown file that i have say this is my markdown file is it visible so these are the attributes say the title the description the link and the rest of the content this is not like the normal file it has html content it has jace content everything so to parse the markdown files that you have with you i have gone with this library frontmattermarkdown there's one specialty about this frontmattermarkdown library is that it can also compile your view component it's pretty much cool right so using that and so the async data and you parse the markdown file content and you get the attributes separately and you can just generate your own html content using the template so this is how easy it is to build your portfolio or your blog with nuxed and markdown file so that's pretty much of it from my side and this is just an overview of how i build this site for detail how in detail how we want to go we can just take it offline so that's pretty much of it from flash so moving on with the next theme building an app for fun is one thing but building it for enterprise is a complete different beast altogether there are umpteen different things that go to make the apps modular our next speaker believes that given enough time any code will turn into a speckety one so why not make it a modular speckety so put your hands together for Kunal we'll be talking about a modular approach to building last scale view apps hello once upon a time once upon a time there was a frontend developer named Alice she was working with a fast based small organization which was still growing she was given a project to work on a frontend application so she thought let's start with a single page one the journey was pretty humble it started with a single page application a couple of components nothing fancy started adding pages when you have more pages you need a router then came the data management part something all developers or frontend developers did that's where the view x part came in new shiny features were added it could be payments it could be chatting messaging and what not so you see where this is going and of course new team members Alice alone cannot build this big of an application so obviously there are going to be new members coming into helper what does that mean last scale application now can I have a show of hands how many of you know what a large scale application is or are working on a large scale application oh god okay so sorry what is a large scale application how do you define large scale application see in my opinion it comes down to three points one size large scale applications are a large they can be sized in terms of lines of code, number of files assets, you know the story complexity intricate business logic if, is, this, that what not and of course team members this is something that ideally people might not speak about people might or something you would not would not see in a presentation like this but trust me it's a code that says what one developer can do in one month two developers can do in two months so let's let's take a look at how many large scale applications are there in the wild get lab now this is my personal favorite by the way like you would not find a better large scale application out in the wild open for reference like that is completely built on view IBM cloud the big daddy and of course B hands that's where you all get your design inspiration right so let's let's see how our favorite GitLab handles what it does let's see how large GitLab's application is they have 450 plus files and that's just view files I'm not even counting the number of JavaScript files or assets complexity if you go to the features page you will see that they have more than 50 plus advanced features CI CD pipelines repositories, boards, kanban boards you name it they have it team size they have a dedicated team of 50 plus developers working only on their front end so you know the scale well if you had an application this big how would you structure your application that's the first question every developer is confronting with when they start a new project or when they are currently working on a project that's going big so let's take a look at what the view a typical view app structure looks like pretty humble right there's a source folder for all your code there's a directory that contains components a directory that contains your views of pages a main app.view component that brings all of that together a main.js file for basically as a front runner a router file and a store file you know the story think about it 450 plus view files intricate business logic multiple developers working on it will this structure scale i think not let's take a look at giflabs view application structure so they have a javascript folder because it's a monolithic application they have a javascript folder where all the javascript resides you're looking at one folder called boards which belongs to their feature the kanban board feature if you look inside that you have a directory that contains all their components the store that's basically your state getters, set mutators and actions services probably classes that or single terms that make api calls models basically that acts as data transfer objects mixins and the index.js file to bring all of that together and i'm skipping the other helper files but you see where this is going let's see what this gets us each module and feature lives in its own directory you saw we had a directory for boards similarly we might have a directory for repositories for let's say if they had a messaging feature that would reside in its own directory and each module has its own set of components, services models, helpers, you name it so what does that bring us to? what's a module? this is the term that's thrown around everywhere and yet something even google cannot explain correctly like google has something along the lines of rocket science or something go check it out as a front-end development isn't rocket science so this is what a module would look like on a higher level components, routes, pages services, assets, utilities and store you get the picture all these modules come together like this this gives you a better viewing or let's say a better conceptualization of how your application might look the question would be what would a module do why is it that you need a module why not simply put together files in different folders and call it a day well let's take a look at an example consider this simple route mapping this is something we might have seen like probably a hundred times there's a path when you visit this path this particular component gets rendered simple right? let's visualize it this is the profile page component which is rendered on this particular route there's a data property for user which is empty or null by default and when the component is created you basically fetch the user by its ID which sets this user object simple right? and once this user object is set all you do is you render the profile card right? let's take a look at another example the same path except that's something nested which renders the profile settings page same visualization get the picture it's almost identical couple of problems here duplicate data fetching calls what would happen is that if you visit the profile page directly on creation it would make an api call if you visit the settings page it would again make an api call even if we use a store which of these pages or components would have the responsibility in the api call if you put that responsibility in the profile page component and if the user directly visits the settings page component the data won't be there so you see where the problem is going also what about other pages we have profile about page photos page etc etc so bring all of this together let's look at how we would modularize it so on this particular path we will load this particular component or render this component the profile module and we will have some routes which will act as children routes for this particular module if you go inside this particular route it will render the profile page if you go to user slash id slash settings file or route it will render this particular component but before this what would actually happen is it would all go through the profile module so when you visit this particular route the profile module will be rendered we will have a computed property that observes or gets the data from from your store and when this component is created we will basically call a simple bootstrap method which is nothing but our own custom method or a convention that we would like to follow and we will have this router view inside it which will only be rendered if the module is ready so how do we get there this is the simple bootstrap module for our example we will pick the id from the route and we will dispatch an api call in our action which basically sets the user object so we know that the computed property or the getter will resolve to that particular object which is like a truthy value this one so this would resolve to a truthy value only and only if the user is there and who is orchestrating all of that the profile module so this is ready will only be a truthy value or will resolve to a true value when the bootstrap method is called on creation which makes an api call to the store and this computed property results in a user object so these are the four points on how you can get there add a wrapper component per module so each module will have wrapper component we fetch all the shared data inside that module that is required for your child for your child components in this particular module it's not just fetching data from the api but it could be a lot of other stuff we'll add a router view for rendering our child routes and that router view will only be rendered when the module is ready so now the module component has the control to basically render or decide when the child routes are rendered so all of that is aggregated into your module component or wrapper component so instead of this try doing this this is exactly the same thing except you have one module to orchestrate all of that which is outside of your view router and then later on you can bring all the routes from all the modules together like this in your view router you see how those this is how simple this is you have your applications routes which are primarily static pages and for each module you have their own set of routes which you can load directly here and this is how the structure would look like your application routes are made about your module routes like n number of modules you have all of them brought together let's take a look at a quick demo this is the non modularized view app for example which is your typical view app with the router in a store and a couple of pages if you visit this user's profile you see the URL its users slash one so this is where our profile page component would be rendered if you click on this link you will be taken to their app out page which in our example is more or less like the settings page just see what happens you saw a loading loading indicator there so what is happening is that whenever you see this loading indicator there is an API call so it's one when you visit the profile it's fetching the user and again when you visit their about page it's doing the same thing let's see how our modularized version works out so if we go to this user's profile we saw the fetch or the API getting called and the loading indicator coming in now if you visit the about page it's no longer there because we don't have to make an API call all of that was done by our module component these are just pages that are rendered only and only if or only when that particular data was fetched and the module was bootstrap meaning it was ready let's dive into the code for this one so we have our app.view file pretty simple right just have a route of view here if you go to the routes file you see there's one page to load our home page and then we have our modular routes from the profile module if you go to that particular directory you can see that we have a modules directory which contains the profile folder for the profile module and inside that we have our own store and we have a router now these routes are exactly taken from the example you have a path or a component that's rendered on this particular path and we have two children for that a profile page and a profile about page now looking at this particular outline of routes it's very easy for anyone that's working in this particular framework is that we'll only render these routes if that particular module is ready the control is taken from the router and into that profile module now that profile module will decide when these routes are rendered or these components are rendered and before they are rendered it has the ability to orchestrate or bootstrap or decide when it's ready to do that let's look at the code for profile module we have a router view which will only be rendered if the module is ready else we'll simply show a loading indicator when this component or module is created we simply call a bootstrap method which is something that a convention that I really like to follow because it makes it really simple to reason it with the overall journey of or the flow of the application if you look at this bootstrap method all it does is it takes the ID from the route which makes an API call sets your current sets the user data and that user is available here in this computed property and we get to decide when is the module ready right now it's a pretty bare bones example where we have a user object returning a truthy value to basically state that the module is ready to get rendered further in your case it could be let's say if you need 20 APIs if you need to call 20 APIs let's say God forbid then you can make all those API calls and only then you get to render or you render the child routes but all of that logic all of that control resides in your module or wrapper component now if you go and look at the pages they're pretty simple you simply get the user or the shared data from store which we know is already there as this page would not have been rendered in the very first place no way if no hacky stuff of making or deciding whether to make an additional API call or not checking for stale data none of that stuff it's pretty simple you know that when the control or this particular component is rendered you have all the shared data you need because that's all been bootstrapped or orchestrated by the module component if you look at the about page pretty similar no API calls no hacky stuff and just to give you a brief look at how the store is structured it's pretty simple we have an action which basically fetches the user from a service which is nothing but a mock or let's say stop data we simulate the loading or API loading part using a set time out and we then commit or set the user once we have the data when we have the data this triggers this mutation which in turn sets the user object which is the details or info about the object you are trying to be a profile of when that happens this particular computed property returns that object which in a predicate world is a truthy value all of this together imagine if you had 20 other similar modules a profile module a user module a messaging module it would be very simple why because then one module or one wrapper component will have the power of orchestration of whether the child routes are ready or child components are ready to be rendered or not so to sum it all up split each feature into a separate module or separate modules that basically means one directory for each module have one wrapper component per module this will allow you to make orchestration or make your orchestration easier and you can basically have all your bootstrapping logic in one place we bootstrap this wrapper component by fetching shared data required by the child routes it could be fetching shared data or it could be doing other stuff you know the drill and we only rendered the child routes once the module is ready so you see you have the power to decide that or that wrapper component has so like I forgot to basically introduce myself in the beginning but I'm Kunal I basically lead a team of 15 odd people out of London and Bangalore so I work at this company which is a fintech company an year old we have based out of two locations and we currently handle 130,000 of ads so we can take up up to three questions this time hi Kunal we spoke about multiple modules if say for example two of these modules need some generic code to be written which is used by multiple modules so where would the generic code go right so typically there's a shared module pattern what you can do is probably have a shared module wherein all the components are stuff that resides which is basically shared by your complete application so what happens is that this is pretty similar to how Angular does it but the thing is that they are structured or Angular designed in a way that makes modularity a first class citizen in the complete application but in the world of view it has to go by convention so a lot of this cannot be enforced this is the part and parcel of you that is so flexible that you can do anything with it but it's not opinionated so you have to set your own opinion hi Kunal so what are the techniques that we should use when we are managing such large scale application not only from code splitting not bringing the webpack part but in the view application what are those techniques like generic techniques if there are more like if we are using dynamic import api or something like that for the dynamic routing similarly some other things like if you can share I think a lot of things in large scale application the problem that we also face and lot of other developers face is consistency which can probably be solved by couple of things let's say for example lot of people keep strict linking their linking rules are strict the other is documentation people don't maintain documentation but that's quite let's say ascension in a large scale application conventions lot of inventions need to be followed so in typical manner like if you are asking for particular techniques there is not not that you can primarily do in terms of like heavily enforced but that depends on your use case like if you can come back to me with a use case then I can probably give you a better answer hi Kunal it was a very good talk and I am working in a team where we have a store where we have multiple modules and the modules have started growing to like beyond 12-13 modules so we have just started debating among developers like this is not the right structure there is too much of coupling between modules they should be separated and all that I could see that you have got different stores and it's not one store with different modules so how do these stores communicate so primarily what happens is that all of that comes together in your main store there is just one store and where all of this comes together these are not isolated stores these are just store definitions for each module so that they are cognitively separated so let's say if you are working on one module you wouldn't have to worry about whether this affects the other module or not in general sense but all of that comes together in one store you just have one store but these store definitions are segregated into modules thanks we can take two more we have time for particular module requires a lot of data so how do you go about like instead of fetching all the data for just once for the module or like you go incrementally for child routes yeah so the best part about this module or architecture is that you can have some modules as well so let's say inside a user module you had a profile module and a settings module so what would happen is that the data that's required for both of them can be put in the user module the data that's only required for the settings module let's say can only be boot strabler fetched in that particular module the thing is that giving the control to one component allows you to decide like where can this happen if you want to make sure that before they are even ready or rendered the data should be there you can put it all of that or bootstrap all of that into their file so let's say let's say let's say let's say let's say let's say bootstrap all of that into their commentary thank you so we can we are pretty much on time so let's give Kunal a big round of applause for an engaging talk and I'm sure a lot of you will have a lot of questions for him so get hold of him in the open space after the break or ping him on twitter disturb him whatever you like so next up we are building enterprise apps and at some point when our product grows we want to get it to a stage where it can support multiple languages and building a multiple building an app that supports multiple languages not a child's grade so we have Prateek here who is going to take us through different examples and his experience through building multilingual apps so Prateek, stage is all yours hi everyone this is Prateek and I work as a front end developer at Zeta I'm here to give a talk on building scalable view web apps for multiple instances so these days many companies are moving to multiple countries especially startups in the recent times with this it comes as a challenge to us front end developers to design a web application in such a way so that it's easy to scale, develop and deploy so I came across the same situation where I need to build an application it scales into multiple countries and these challenge here is much more than language, currency or time zone because it can be satisfied by the I-18 library here the challenge comes is that in multiple countries the logic and flow can be different but more or less for one application it will be more or less the same consider a mobile web application where you have a user profile in that case most of the part will behave similarly only few part might change based on the country example in India in the profile page in case of fentech you might have a KYC component but in any other country in Brazil or etc you won't have that component so we need to manage these conditions in a single repository the aim was let's see how we were able to achieve it so what are the options I had that time the first option is the easiest option which comes in our mind the safest one is to maintain different repositories but it's obviously not a good practice because you are maintaining multiple shadow copies of the same repository and consider a situation when there is a security fix you need to do or you need to change the scroll behavior you will need to take multiple developments and multiple releases it's a huge task the other approach was like most of the developer which we all follow is if else approach it's maybe because of the bandwidth we have we go with this approach of if else this may work out for you for like one or two countries but consider a situation when you have more than 5-6 countries it will make the code look very dirty and not even this you will be shipping the code everything in one bundle of multiple codes of different countries in the single bundle and also if one developer is introducing a bug in one country it will go in multiple countries so obviously this was not another approach we should go for one more neat approach was maintaining configurations this is an enhancement over the if else conditional statements but again if you have like 5-6 countries then the backward compatibility becomes very difficult to maintain if you have configurations consider the situation you are the like 6th country the person who is developing and you are making some change imagine in the configuration you have to go to each and every country developer to know what impact it will make to your country this required a lot of team interaction and this again was not a solution we went for the last is one of the developer shared with me in this case what he was doing is he was trying to change the resource path during the deployment this solution can help you switching the countries but not avoiding duplicate code so let's see what are the principles which our solution is following we will prevent any kind of duplicate code in our solution separation of concern so here we will build separate country folder for each country so that one country team is working on a specific folder they won't mess with any other country folder and also it will avoid a lot of conflicts inheritance so as a developer we focus on making development experience better but also a major part comes in testing and deployment because one country team will be you know waiting for one country team to be able to do the same but also one country team to be able to do the same we will be waiting for hours at night to release but other country should not be dependent on them every release should be separate of each country these are the challenges which we thought we should solve make this complete framework building scalable web apps for multiple countries work out this is the core of the solution you make sense you make sense here you can even have the component options like data methods components props inside the view mix not even this you can even have life cycle hooks inside the mix so in my case I had an application already developed I had to scale it too I was the person who was implementing in the third country the other guy for them conditional configurations worked out but for me again working on it was not a good idea for me so what I did this helped me to move the complete javascript code of the view mixin into a mixin javascript code into a mixin completely having said that mixins are little debatable but yes view mixins are smart here for a specific use case if you are using with proper documentation it will give you good results let's see how mixin looks like so here we can see we have defined a mixin and inside the mixin we are having the component option of methods here we are defining a foo method and a conflicting method in the view instance we can see that we are importing this mixin and we are defining a new function called bar and then again we are overriding the existing function conflict and if you are printing it we can see foo is printed from the parent bar is implemented from a child and conflicting is overriding the parent this feature will help us defining the country specific requirements and also we will be using javascript's ea6 dynamic imports with dynamic expressions and web code printing this will help us separate each country fold as a separate chunk and loading the specific chunk while we are loading the application or while we are building the application you can see the format here we are passing the country id this can come from the webpack variable it will automatically load respective modules with dynamic inputs now let's see how folder structure will look like so here we can see that each country module is having a separate folder and each country folder has an app body this separation of concern will help us avoiding conflicts and each team will work on its folder without disturbing any other country every country here is having an app body let us see how the app body looks like the app body we are having components so these components will be across various countries most of them will be reusable but in case if we have a separate component based on a specific country example as I mentioned in case of India you will need to have kyc we will use the kyc component here but it might not be used in the case of any other country so we will define the components which we use it will be reusable will be used in multiple countries so this is the mixing code so this will be the complete functionality of that module here we can see we are having data, methods components imagine everything is different inside the mixing it just looks like a component javascript and then again here you can define the functionality if you have much more than language, currency or time zone so this will be the mixing will be the base component which will import in our country so here we can see this was the user profile component we are importing the user profile mixing which has a complete functionality and we are overriding it with the country specific requirement which we have here we can see in our case example if we are in vietnam the country code will be different the theme code which we are injecting might be different also the functionality, the function the call if it is different we will overwrite that function here and we will make the country specific implementation based on the requirement and imagine this same mixing will go in multiple countries we are using the same mixing for n number of countries see how we are avoiding so much of duplicate so this is how our overall component looks like we can see we have lot of reusable common components like the user name field, user email field and phone field these will be used in multiple countries javascript as we discussed we are importing the same mixing in multiple countries and only writing the country specific implementation and not even the templating and the scripting even in the styling we can see we have defined the common style all at one place and we are importing it and we are overriding in our country specific child component so we will have the basic base component in the parent folder in the common modules folder we will use that if we don't have any changes if you have a country specific requirement we will define it adjacent to the app body and we will use import that component instead and that component will import the complete javascript from the mixing styles again and only we will specify the country specific requirement inside this component we can see we are doing so much of reusability only we define at one place so this is the part which will make sure that each of the countries specific app bodies are loaded based on maybe the webpack variables or dynamically specifying the country so in the last line we can see the app body we are importing the country country ID this country ID is coming from the webpack variable and we can define a mapping of webpack variable and the folder name and then again we have an else it might be helpful for you in the testing where you can just specify with the parameter which country module you want to load and dynamically that country module will be loaded and this will also ensure that when we are building we are only building for a specific country so we saw how we made the development experience seamless and we chunked out all the countries into specific country chunks during the deployment we will create separate pipelines for each country making it sure that each country is not affecting any other country here we can see when we will build such kind of an application we will get multiple region modules like region 1,2,3 this is how dynamic import works whenever you specify a path it will create chunk for each of the folder inside that path but it will only include the component which we are specifying in the webpack variable if we are using the u.s. module it will only include the u.s. module when you are running the application and we saved so much of other country code as we are not including it in our build so here we saw this use case of building a scalable web app for multiple countries or instances and here we used the feature of view and javascript and no other library to make it possible we followed the principles we are not making any code duplicate we are using maximum reusability we are doing inheritance we are maintaining the separation of concern each country is having a separate module avoiding conflicts we are only loading the code and major thing the testing and the deployment is independent of each other the testing team of one country only needs to work the other testing team can relax and not concern with the release happening yes because the approach which I followed to make it possible making one repository work out for multiple countries with the seamless development experience and also the testing experience so we have time for a few questions hi so in our organization we use ember js and actually using mixins in ember we had some pretty bad experiences so ember mixins can actually access the attributes of the components that it is imported into so if the developers are not careful and they assume that say the store object is available to a crash when you imported somewhere else so my question is why mixins are the only solution for reusability problems like why can't you use a traditional helper so atleast you know what is the data that is expected in the helper and what it is returning so as you said mixins are derivative but yes again in the slide if you read aduous money the person mentioned in the orally article that mixins if you are using it with little documentation it can help you identify which function is being implemented and if you consider our situation view gives the power to include the complete component options and then life cycle hooks inside the mixins and in our case it is one level of overriding so one is the base component and other countries which are overriding it so when we go to the country component we know that if we are not overriding it is from the parent component if we are overriding it is from our component this worked out pretty well for us in case you have one parent and one child hey nice talk Praveen here so I have question as in where would a library like view i18n or any library that allows you to do translations where would it fit in all the architecture that you have talked about so when this requirement came we thought that it is filling through the view adding library translations will be done time zones currency will be done it will not have a KYCA in Brazil or some other country so then we went with this architecture answering your question i18 will include it in the base application all the templates will include the view i18 tags inside the templates and every component will follow the view i18 tags so automatically the translation will be done so what we can do is in the time of initialization as we saw the way we are setting theme in the mount application we can set the language better approaches when you are initializing the view component you are passing the i18 inside that when you are initializing the i18 library there you can specify the local which can come from parameter maybe you can define a configuration for that based on the webpack variable you are importing then the mapping for the language different from how is it different from a view async component so in this case you actually used a mixin but let's say you have inheritance based different components and you asynchronously load one of the child components how different is that going to be with this so the reason yes we used mixins here was because we were importing from the parent component and also we are having the view component options of data methods everything inside it so in my case the repository was already ready but i had to do is to make it scale in different countries so what i did when i came across the mixins i saw that they are giving the power to include the complete component option life cycle looks inside the mixin and not only this if you are using this you will import the same mixin multiple countries will override it in case of component you might be a duplicate but from my experience you can still do the same thing with inheritance hierarchy of components itself so if you see the javascript part and the styling part we are importing both of them and then overiding we are defining it at one place and then importing it and overiding in case if you are creating multiple components you might have duplicate styling duplicate javascript you have time for one last question awesome so thank you so much moving on so moving on to the last talk in the pre-lunch theme so as we have seen in a show of hands earlier today many of us are building large scale applications and when you are creating a group of applications that have to look similar or have similar infrastructure plugins come in handy while sharing the same logic across applications so arnav who is a next speaker has first hand experience in developing some popular plugins like vuex persist so let's hear it from him by the way this is the talk that's like between you and your lunch and arnav has promised to keep it interesting so yeah hi guys I am arnav currently I work at zomato and my work has nothing to do with vuex I work on the mobile team at zomato so that's why I start with why I made plugins in a language that I don't use so let me show you a sample of a site project so it's a website called sharetime.in it helps me should you have meetings with people in different time zones and I needed a component that would update itself every second like we have a timer kind of thing and I needed it in a lot of places inside that website so I built something like this you have a time object in the data called update time and there is something called timers now if you have used vue before you know that there isn't a key called timers inside the vue instance by default but that's what my plugin does if you add a timer for update minutes with an interval of say 30 seconds repeat it every 30 seconds that function is going to run and in fact if you use type script it's even easier when annotated with timer and it's going to run like this so that's the first time I actually made a plugin for vue itself and I've used it in a couple of websites since then and then eventually once I had to build so I found a startup where we had an online id and it has to save a lot of things last import last output it's like you know it's an id so it has to save a lot of stuff it has to save something local storage something for local forage etc etc and I wanted basically my entire vuex state to get saved to a storage and get restored when you open that website so for that I built something called vuex persist which again my end goal was that it should be like only 2-3 lines to incorporate it and my vuex store to get saved using it is very simple you just construct an instance of it the storage to it and as long as it is of the storage data which is it has get item set item functions inside it you can pass such an object to it and when you create your vuex store you pass that on as a plugin and that's it in fact you don't even need to be using vue with vue cli even if you are using vue just by writing script src in your HTML file you can still use this so this is something that actually got pretty popular after I released it it has a lot of downloads a lot of projects on use it so that's when I thought maybe I can give a talk about how to make plugins an expert enough to say that so start with the basics so what are plugins so in the world of vue when we use the word plugin there are 3 kinds of things we mean and we could of course differentiate between them so there are vue plugins which adds functionality to the vue framework itself or the vue components then there are vuex plugins now vuex plugins of course you can use only when you are using vuex and what they can do is you can trigger certain things happening when the state of your vuex is changed and finally there are vue cli plugins which has been popular ever since vue cli 3.0 was released so you can basically you can add support for new languages basically the entire vue cli build step where your project is compiled and bundled you want to make any changes in that pipeline you can create a vue cli plugin for that so I would not be speaking a lot about vue cli plugins because it's a very different kind of a thing it's about how your project is compiled and not about how it is run we are going to be discussing more about vue and vuex plugins in fact vuex and vue router which I think most vue projects use themselves are also vue plugins so how do you recognize what is a vue plugin what is a vuex plugin so whenever you see documentation which looks like this that say an example plugin called vue boom you import that and the documentation says that you write vue.vue so these kind of things are vue plugins vuex plugins you would usually see the documentation which goes along the lines of this that you import the plugin and when you are constructing the store you pass it into the array of plugins and vue cli plugins usually you would find documentation which looks like this that you do vue add let's say a plugin called tattle or usually you install it using npm and then invoke it it can run some code generation it can add some steps and all of that stuff so what exactly can these plugins do so what a vue plugin can do is that it can add some global methods of properties to the vue object itself it can add new directives filters or transitions so we have got a lot of transitions in vue by default like slide and fade transitions exist if you want to add your own ones you can do that directives like vif v4 you can add your own ones like that and they are in fact there are a lot of libraries out there which do specifically these things you can add some mixins so I think last there was some discussion about mixins so you want a particular mixin to be available to every vue component in your project you can put that mixin inside a plugin and put that plugin into vue so that mixin is available on every vue component and finally you can add things into vue.prototype which means those methods will become available to every instance so usually people do that with axios they put vue.prototype.axios equal to axios they do and then in every instance of vue you can use this.axios it is a reference to axios so those kind of things usually that vue plugin can do so what a vuex plugin can do it does really one simple thing it can listen to mutations and when the mutation is triggered the vuex plugin can decide to do something like save the state into local storage like mic plugin does or you might want to trigger a new mutation you might validate the user token every second so you can do that when the state is changing like that and vue cli plugins like i said they can add new webpack plugins into your build structure they can add resolve configs and they can add or modify the order of tasks in which your project is getting built and they can also have transformers which can transform your code so if you install the vue typescript plugin the existing javascript code gets transformers typescript code so let's take a look at how do we build vue plugins so first of all we need to answer these questions which of these things we need do we need global methods or properties do we need filters, transitions or directives do we need any global mixing or do we need any instance methods so the plugin usually looks like this you export your plugin to your npm module it is supposed to contain an install function that install function is going to get run when the vue.use line is getting run and at that stage you have the access to the vue object and with which you can do these things you can add a global function like this you view itself you can add some directives or filters into view these are things that you can do at every component level also but if you do it here it is available across your entire application right and then if you want to add a mixing so you can add a mixing like this and there is a created function so this created function will get run for every component inside your entire app and you can use you can use the prototype to inject there is a short hand syntax that exists if the npm module that you are building contains only the plugin and nothing else sometimes you might be exporting the vue plugin plus some other things so in that case you can add those things into the myplugin object apart from the install function but if the install function is the only thing that you want to export then you can just export that function this syntax also works if the module is a function then we will treat it as the install function itself you can directly add stuff like this we will actually build a vue but for that let's take a look at how vuex plugins are built and we will build both of them so when you build a vuex plugin what do you want to do when a mutation occurs and do you want to do different things for different kinds of mutations and do you want to commit another mutation when one mutation happens and it's very important to escape the recursive cycle you might end up because the mutation that you will run will trigger your plugin getting run once again so you need to figure those things out so everybody who has used vuex would have basic idea about this so your component can dispatch actions actions can do asynchronous stuff like up to the api then they can commit a mutation mutations are the only place where you can change the state and when the state changes there might be some re-render that's happening on the component one directional flow of data in this green box the only place where our plugin can hook into this life cycle is at the mutation level that's where we can do anything so the plugins you write like this you can subscribe to mutations when you subscribe you get this function which has the mutation in the state what happens is that you can read the value of mutation.type which gives you the name of the mutation that was run and mutation.payload will give you the value of any payload if there was a mutation mutations can be payload less mutations as well and the value of state that is coming into the function just keep in mind that that is the state after the mutation has taken place so this is going to run after the mutation has taken place so you get the change state you don't get the previous state so if you want to prevent a mutation from happening that is not something you can do with the okay you can reverse it maybe but you can't block a mutation from happening you just get to know that it has happened and you can do something else after that okay if you need a plugin to block the mutation probably you have not written your UX properly one thing to keep in mind is that like I said you can commit further mutations from here that would result into this function running again so you need to filter you need to not run it again for the my mutation being done because that's a mutation and people again forget this event keep in mind that if you are on strict mode that when you are developing usually people turn on strict mode for this so changing objects inside the state directly state.x equal to y or basing the state object itself the reference to that those things do not work in the strict mode and that's why like if you don't use strict mode you might end up writing like this and sometimes it might work but sometimes you will lose reactivity in your store if you write like this so it's best that you have strict mode turned on and when you build your plugins you automatically will end up creating mutations for making changes to it via the proper set okay so again do we build remember this to it? got very popular recently yeah okay so so years of presenting at conferences has taught me not to actually do a live demo so I did the demo an hour back and I have still recorded it so you are going to make a plugin called CSS debug and I don't type that fast that's 2x and we are going to export a function that function is going to have the view object inside it I am going to create a global mix in so what I will do is elements are mounted and we have published this module already you can install CSS debug we will see that live happening but before that how about we take this evil approach to UX plugins as well okay so let's make a UX plugin so it's called UX plugins store flash and again this is also 2x so we are getting a bit sorry for that so every time there is a mutation background is going to go red for 100 milliseconds okay and wish that as well so actually have a project size a bit this is a website called realworld.io it's a copy of Medium you can build it using any framework just to brush your skills for framework I really love that project to try things out let's go to this website so yeah it's how it looks like it's a medium clone there are trash articles of course so let's do is we will go to main.js and what did we name our this is import let's do we are going to import that as well import store flash from and we will add that into plugins here what do we have let's change the state so you can debug your entire app like this I mean of course you guys have better ideas of making plugins but I just wanted to show something that you can really quickly build one line JS files back to my presentation so just for your information I do use nano I don't use vim because I'm not a 10x engineer I I'm not even a 2x engineer I just play my videos in 2x okay so coming to some of the important aspects of when to make plugins now this is really important that you should not just keep on building plugins just because you know how to build a plugin I have built a few plugins which nobody uses them because so should we make a mixin and we put it into a plugin and we make the only way to use it is by the plugin or can we actually make the mixin separately available as well that's also a question in mind so you just decide whether the functionality that you introduced make sense only to some components in your project or to all components in your project and that way or the best thing you can do is for example the view plugin timers if you go and take a look at the readme I export the mixin and the plugin both in the module so you can use it as a plugin in which case it would be available on every component you can use it as a mixin in only those components that you want as well okay and we were talking about some enterprise grade projects you get 400-500 view files in some places should not introduce mixins into them because that function is going to get run every time it is a big run time cost to be incurred should you make a plugin or should you just create a function and export it as a npm module that also is something that we need to think of and what you have built does it make sense only in the view construct of things or what you have built is something that is very general to web development in nature and I think this is a very deeper question is that a lot of times when we are building app with a framework we forget that we are just doing web development the DOM is still there JavaScript is still there and it has not crashed so sometimes you just make something really generic it can be a function you can import just a simple npm module you don't need to make a plugin but yeah if it is related to how the view life cycle works or if it is related to how people will create filters or directives in that case feel free to go ahead and create a plugin right which time do I have I have a bit of time so I am writing tests for your plugins so now that you have built a plugin how do you write tests for your plugins I will just drop down to let me say yeah so this is this is my view timer one so the thing is the tests that I have written they they are not really like how you write I think the best way to do it is in your plugin inside the test directory create a sample view app which uses your plugin and then test the components of the end functionality that you need yeah so it is similar to that so create a normal timer component it is written in typescript though but I think hopefully it makes a bit of sense so I have just written my normal test I have used jsdom to make the elements available in Node.js so I don't need to run this test on phantom or something like that it runs on Node itself and we just check we mount the timer component and the timer component is supposed to update in 200 milliseconds so in my test after 500 milliseconds I just test that the value has changed so I am not really testing my plugin itself I am putting my plugin into a view component I am testing that component you will get very good coverage across your entire plugin wire up your test like that I think I have written some test for the UX plugin as well so UX plugin again does similar things we have got created a store which has some values of the number of dog bugs and the number of cat muses and it runs some mutations and then I just check if the inside the saved store whether the value has updated or not again this is a simple node level test in fact this test does not require view itself it just uses viewex to test it so it just is the viewex part of it so that's about tests and this is very important is that when you have written a plugin our distribution when you distribute your plugin to distribute it as commonJS or ESM or UMD if you distribute it as only commonJS then people would be able to use it only when they build their project via viewcli but if they simply want to script src your module and they just want to so in fact if you have looked at the documentation you can use view and viewex together without using viewcli you can just script src on package slash viewex and you don't even need to write view.use viewex the cjs script automatically includes itself into view you just need to write the lines one after the other first import view and then import viewex and you have viewex setup already so if you look at the stats so sometime back there was an article on like whether view is used more or will react is used more a lot of people commented on some frameworks like view and react is that these frameworks a lot of people do not necessarily go and install it from npm so the npm stats might not be a reflection if you go and look at the stats of js deliver or unpackage there are a lot there are like the number of downloads among the going to billions so a lot of people do use view directly inside their browser although that's not very good for performance but if it is solving their purpose your plugin could probably help those people as well so what we should do is I'll give you an example of my plugins where I have written them actually in type script and I have distributed them in such a way that they can be used by people who are using js or ts and they can be used directly inside the browser or with the viewcli structure so what happens is when I build my modules the dist folder it generates a cjs folder inside which there is the common js version of this plugin there is a esm folder which contains the esm version of this plugin and then there is a umd folder which generates the umd version of this plugin finally the .d.ts files are also separately exported types and my package.json I have specified all of these things so my main points to cjs because when somebody using it via node that is what they want my module one points to the esm one so if somebody is using a fully esx way of using it they will import it from the module one rather than from the main one if somebody is using something like bower nobody uses it anymore but if somebody does or if you publish it .json delivery package etc so browser we have a remap so if somebody tries to access distcjsindex.js they are getting the umd one if somebody tries to access esm they still get the esm one only and I have linked to the main files for unpackage and js deliver so when I publish they pick up the main files so people can simply write unpackage.com slash uxpossess they don't need to specify the minified or the unminified and all that stuff .milky pick that up and the typings folders are also specifically mentioned out there usually building something like this is not as complex as you might think distributing for all of these things I have used rollup so just define the output the format and the target and your source is going to be still the same you define a format for umd umd min esm cjs that's it you get four things built so when I'm publishing it it's available for all the formats most of the view and vuex plugins that I have built I usually do it this way finally documentation nobody is going to use your plugin if it's not documented and by documentation it does not mean run automated js doc not just that that should be there but if you're using type script even that does not require ts doc etc automatically gets generated for arguments and function names and all that stuff what's important is use the right usage guide step by step how do you get started with and we all being from the view ecosystem I think vuex has one of the best getting started guides across all the frameworks and it has been one of the reasons why a lot of beginners get attracted to vuex so I think it is on us when we add things to the ecosystem to stay true to the ethos of the ecosystem and write usage guides and for that we have vuepress so we can use vuepress to build them and I can show you an example of plugin that yeah vuex it looks exactly like all the vuex documentation you have a you know you can even highlight code somewhere yeah so which line I don't know if that highlight is within one of the lines is darker all of that stuff I mean you can write really nice documentation using vuepress so definitely when you are writing a plugin do that so yeah I think that's it from my side that's all I had used before vuex plugins you can put it if you want to and this presentation will be available on speaker guide that's my speech guide for lunch you specified for the mutations like plugins for the mutations specifically the mutations are mostly application specific and those existing in the plugin seem a bit I wouldn't say so the example in the plugin I just wrote rotation.type equal to something just for an example but what you can do is so I'll give you an example of how vuex process works you can make the consumer of your plugin supply a list of mutations on which it is supposed to be saved so your plugin is at a stage where the mutation happens your plugin can't know from before and when it is going to get consumed what mutations will happen so that values also you can take from the user because you can add a configuration step for your plugin in that case I don't know so what happens is like the easiest way to use this process plugin is we can just type plugins and we can add that but what I have is there are some keys when I am constructing it there are certain extra keys for example there is one called filter so this notation filter is a function that people can add and this will basically take the mutation type as an argument and return a boolean so you can add your own filter function and for those mutations you want to save your state as those you don't want to so those things you can add as configurations but yeah your plugin should not be opinionated on what people are doing yeah so when you are building plugins and shipping some vue components so what you suggest you should ship dot vue files or bundle files so that's a good question I think we had a discussion about that sometime back also so I think some places what you do is I don't know about vue plus bundle but I do ship both the ES6 and ES5 versions usually and the UPD builds they are in ES5 and the CJS and ESM ones they are in ES6 and I usually write a line inside my readme that you have to turn on transfer dependencies for this module because I feel that I have a lot of projects which are not transpiling down to ES5 so if they use the ES6 version of my plugin they will save a bit on the bundle size like those polyfills will not get added for them but there are a lot of people who are transpiling their project to ES5 and when they are transpiling their entire project to ES5 why not transpile my modules when along with that so that's like what I feel I have not shipped not view files directly I have I mean I did that with one of my plugins and a lot of people came up with problems like they were not able to buy that and all of those issues were there not view files directly I have not shipped so mutating like adding a global mix basically if your plugin is adding a global mix it affects all the components and it can basically affect that application so should we use global mix in or if we are using global mix in what should we do to convey what it can do okay so I think like I said I prefer doing is having it in the readme itself is that you can use in general document that you can use the mix separately in independent component as well I think it is kind of imperative for me I should add a line there that use it in every one of them that makes it function to just simply be that key to be picked up on property and run even if it is empty for a lot of those plugins so that is there in my experience in all the plugins that I have used there is rarely I have found a plugin which is supposed to be run on every one usually there are very specific cases that you need to run them on certain kind of components because when you have build a project like the GitLab one was being shown there are going to be at any point of time on the screen there might be 2000-3000 components itself and there is hardly going to be any functionality that is needed for all those 2000 components at the same time and if there is then probably those kind of things get added to users itself over time so in that sense I think putting a mix in inside a plugin is not really one of the best use cases like using a transition or adding a filter those kind of things are more valid use cases of building so what keywords or tags you suggest for plugins on npm and github so that they are visible and discoverable when you search them so I mean I don't know I haven't really gotten level of doing SEO for the plugins yet I mean I'm just happy one of them gets used a lot and there are already enough that I choose to keep up with along with my day job but I mean I just follow one thing as I write them in the format of view-plugin-name-plugin and vuex-plugin-name-plugin something like that that's usually the format that I prefer and in tags I just write view-plugin and then sometimes like if I have like timer like write timer and type also given a lot of thought to alright so thanks enough thanks so much for the talk can we have vik sure fans for it alright so now we are going to break for the lunch and before that I have two announcements number one we are still looking for flash talk so if you haven't submitted them yet you can submit them now to me or yeah they are here and we also have birds of feather sessions at 2.10 pm which is going to be hosted outside the auditorium in the open spaces see the markers annotated as bof and that's an open discussion about all the things that are happening around view inside view and everything related to it so please be back here by 1.30 we are going to dive deep into the view internals so let's be here on time thank you hello so welcome everyone back a couple of quick announcements the birds of feather sessions will start at 2.10 pm right outside the auditorium so if you are leaving just tip to and leave try not to disturb the other attendees the themes of the bofs are the first one is why to pick viewjs so if anyone is evaluating viewjs you can just discuss if your requirements are made by view and ask other people who have been using it and the second one is around how to build enterprise large scale apps so if you have some questions you want to discuss you should at the end of the second bof the detailed timings are mentioned in your land yards new announcement on 14th and 15th september we have a workshop by view decorator chirag jen and it's on how to design flexible components with view by building a pwa app and you can check out hasgeek.com for more details so i think that's all for the announcements let's start with the next theme theme after lunch which is around view internals and framework customization so have you ever wondered how view updates your UI whenever your data changes so this is the most technical heavy talk of this conference and we have put it right after lunch so that you wake up so let us take a deep dive into the view internals and understand how view does this magic please welcome praveen who is here to unravel the mysteries of the view universe pun intended thank you sabneel so as he mentioned the talk is going to be heavy and it will require all of our brains to be actively working more than usual what we have after lunch so what i will request you to get up where you are stand where you are so people who are holding their laptops don't do what i am going to do next so you can stretch like this alright thanks i needed that stretch so i made you all do it and now we are ready for the talk that's going to come alright and i am hoping that this will work so how many of you use view js at your company or personally or whatever alright pretty much everybody how many of you have tried looking into how the reactivity system works so a lot of people that's great but then if you have already taken this front end masters course can i have show of hands anybody has taken or have you read these two articles maybe you have so the thing is if you have read those articles and taken this front end masters course you probably don't need to attend this talk my job is done my talk is done we can all move on and have chai again but if you haven't really done that or haven't understood the concepts in those resources i am going to help you out my take is however going to be slightly different in that i am going to take you into the unknown using all the known pieces that we have been using so far and solve the problem step by step one thing at a time so yeah i am who am i i am praveen i work at an amazing startup called voice zen we are a voice tech company and we are great with doing speech to techs for indian languages so that's what we are good about and if you want to know more you can talk to me and wamsi who here is my colleague from voice zen and we will be happy to blabber i also do css things on codemen like the wallpaper on this slide or the other images that i have stuck up there yeah i also love indian railways so that's there couldn't finish my truck though and sometimes i take up css challenges like this one where each flag is a single empty div no text on javascript so i do things like this and if you are interested in talking about all the css things i do please come to the high and now we can go back