 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. If you go anywhere in the community, you just go ahead, give it a try. 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 to our main talk which is reactivity so i keep saying the word reactivity right and i hope this would work give me one sec so what is the presentation without without a hiccup right internet hiccup so we are going to start presenting so these are all the flags that i talked about maybe you haven't seen them on this slide but let's get back to reactivity so i keep saying the word reactivity but what is it really let's take a dumb example and tell me praveen your talk was the crappiest talk to have after lunch it's giving me acidity my face is going to be like this and then if you give me an uppercut because i most obviously deserve it for coming up with this dumb example i'm going to be totally and obviously dead with this dead face or say that did not happen and viewday organizers gave me a bunch of t-shirts for free i'm going to be crazy with stars literally popping out of my eyes but i know that's not happening but this thing though that change outside and it made my face change is called reactivity now we don't punch screens to get things done we make buttons that click and then we release them as our design system and show list and draw some charts etc etc so how many of you have been building some kind of dashboard see that's what i'm saying so let's take a real world example when you click the follow button on twitter right a bunch of things happen and suddenly you are following that person let's try to describe what happened here clicking the follow button triggered a click event a piece of code that developers at twitter wrote reacted to that to get everything done it fired an api request and got a 200 they changed our ui and we see the blue following button but here's the thing what made the text change from follow to following or what changed the appearance of the button we can imagine that behind the scenes somewhere in the twitter's ui code this may have happened the initialize is following to false and they calculate the value of follow button text should be following or follow based on whether or not we are following and after this send an api request and get a success the change is following to true and voila we have our ui updated and that is what pretty much any major framework allows us to do they allow us to build modify update and change our uis from data declaratively they also make our uis react to those data changes done in future automatically and they give us tools to do all of these magical things without ever actually touching the top the question is how do they do it because if we know even a little bit of javascript the problem becomes apparent let me give an example so here we have a variable number initialize to 10 we calculate the value of square by multiplying number to itself and as expected we get the value of square to be 100 but now if we change the value of number to 20 we get the value of square to be 400 we can say that changing the value of number hasn't affected or updated the value of square we can now imagine why in the case of our twitter example changing is following to true at a later point of time won't change the follow button text anymore so then all these frameworks must be doing something extra to get a code like this to work and update our uis accordingly the answer is they build a reactivity system now what is a reactivity system you ask in the simplest of terms a reactivity system is like a spreadsheet in the example above we have two columns and the value of one column changes based on the other what we want is a formula to calculate the value of square so now the talk becomes how do we make javascript act like a spreadsheet and say all the people sitting in a room we wanted to come up with a competing framework with this awesome name and totally original logo and open source it we would have to solve this core problem without that we aren't going to get to the 100k plus stars that view has and now we need to look for some inspiration to architect our solution you know what we don't have to look too far in fact we have been doing all this whole reactivity thingy all our lives using add event listener anybody remembers add event listener good show of hands so browser have an event system that has been into place since the big bang if you have forgotten how add event listener works by writing all your framework code day in and day out let me give you a refresher so what we do is we start by saying hey browser we want to listen to the mouse being moved around over the body element and whenever that happens could you please go ahead let me show you the function that prints the value of x and y so then we move our mouse around and browser does what it promised so in this case the mouse was moving diagonally from left top to bottom right and if I have to say it the other way our handler that we passed which is the function that logs x and y it reacted to the mouse being moved around seems like the right direction writing to get inspiration from so let us understand how add event listener works if it dig a little we can see that add event listener does roughly three things number one it stores the handler we passed to it somewhere against the event for which we are listening number two the browser tells the tells add event listener well hey the mouse is moved an event has happened so and when that happens add event listener goes ahead and then finds all the handlers associated with that event all of them one by one so and don't just take my word for it because we have deaf tools and if we go ahead and check in deaf tools we can execute our code inspect the body element and go to event listener's tab and surely enough we can see our code being there so maybe emulating what add event listener does can get us to the solution and it becomes how do we replicate browser's event model so that seems like a simpler problem to solve than the actual reactivity jargon so let's start by writing some code and again I need your brains to be focused here there is going to be a lot of code so please be with me number one we know that we need to store our handlers so we create an array called handlers next we need to initialize our data number is being initialized to 10 and then square is 0 we create a variable called current handler and set it to null and you will see why we introduce this in a moment we then define add property handler function which is similar to what add event listener does which essentially stores the current handler into our storage finally we define notify handlers which is going to go ahead and execute all the functions that we have in our handlers list now this is all the setup work now we proceed to execution first we set current handler to the function that calculates the value of square remember we want the value of square to be calculated again and again so that's the function we want to store and redone next we call add property handler which does the actual job of storing and we call current handler and we call current handler so the value of square is initialized and if you do that and print the value of square we get 100 as expected now we want to change number and get updated value of square so we set number to 20 and announce hey number has changed and all of you handlers should rerun which is what our notify handler does finally we get the new value of square as 400 which is what we want so that seems like a lot but all we are doing is creating our store keeping our handlers in our storage and then executing them at a later point of time when we know things have changed so that's all and that gives us a way to calculate the value of square again and again now we can see how our spreadsheet example might look like in terms of code so you set the value of number to 10 you call notify handlers and you get the value of square to be 100, 400, 900 consecutive but our final goal is this where we can change the number and get the value of square immediately without having to do all the manual work that we are doing currently and there is another problem in our code so let's visualize how add event listener stores our handlers and that might give us some idea what the problem is for each handler whatever handler we give to add event listener it stores it in a separate storage for each event so if we had if we were logging XY coordinates for mouse move it stores against mouse move and similarly it stores the click event for click but our handler our solution has only one storage so all of our handlers go into the same place that means even if you change just number and call notify handlers it is going to rerun all the handlers irrespective of whether or not it cares for their change and that's bad so we'll need to fix that keeping our goal in mind we can say that we have three major problems to solve number one scale we may have a lot of data properties and we need to store handlers for each property in a separate place just like add event listener so we'll need some kind of abstraction that let us do this repetitive task in the case of browser events when we say we want to listen to a particular event we pass the handler and add event listener goes ahead and stores it but in case of properties we want that to be done automatically so that's our problem number two whenever a property is accessed we want the function to be stored automatically in our storage number three remember we don't want to call notify handlers again and again right so we should be able to get rid of that part and do that part automatically whenever a property is modified so that's the major problem number three now how do we solve all these problems so let's create a depth class which is going to encapsulate the functionality of storing and notifying handlers because we can create instances of a class and attach those instances to different things in our case different properties we start by creating our storage in constructor it's a set so a handler doesn't get stored twice even if you try to next we have the depend method which is exactly what add property handler was doing but it's just a nice name and all it does is adds our handler to the list of handlers and then we have the notify method which does exactly the same thing as notify handlers alright so we can go back to our first solution and then remove all the jargon around add property handler and stuff and just use an instance of a depth class so we first create that instance we call depth depend in place of add property handler and then wherever we were doing add notify handlers we are just now doing depth.notify alright see what we want to do is that when square is calculated using number we want that function to be stored against number and similarly when the function to calculate message is to be stored we want to make sure that name is the property that is accessed so that's what we want to do but our depend method is called depth class previously it just stores the current handler so how do we make sure that when number is accessed current handler points to the first function and when name is accessed it points to the second one and the solution is really quite simple because of how JS works you see JS can only execute one function at a time so if we get hold of which function that is and then call depth depend for different properties we would know exactly which function is using that property let me repeat that again since JS only execute one function at a time if we can get hold of which function that is we can store that reference and call depth.depend for every property and that will allow us to know which function is using that property so we can then store our handlers as we want we move on and try to do exactly that here we are defining current handler as a global variable we then keep hold of whatever our handler is and then call depth depend so now inside depth.depend we are guaranteed to have the reference to the currently executing function we go ahead and execute our handler for initial value and then we set it back to null again for a different handler to come for a different property looking at this piece it seems like we need to do this a lot for different properties so we create a function to do that and that's just another abstraction and let's call it watcher so now our code is much more reusable we can pass our handlers to watcher and then it does all the work automatically alright that's a lot are you all so far with me yes okay so we have done a lot of work to make things reusable so far but we haven't really used them reused them yet we can create instances of depth class but how do we know how to attach those instances to our data like I said also it seems like we need to know when a piece of data was touched that means accessed or modified because it might be a great opportunity for us to create an instance of that depth class and then do the dependency collection by calling depth depend or depth notify right and that's exactly where object.define property comes in it's an incredibly powerful jsapi that allows us to arbitrarily create properties on an object and define what the behavior should be when that property is accessed or modified great seems like we can make use of it so let's take an example in this example we are defining a property on our data object we then say hey whenever a is accessed which invokes the get method go ahead and console log data a was accessed similarly when a is modified we log a was modified amazing so this gives us the opportunity to automatically call depth depend and depth notify so we go ahead and take the step in that direction by migrating from variables to store our data to an object that keeps track of all our data so we convert our variables to an object like this we then do some object.define property trickery we start by creating a variable called internal value that is initialized to whatever value of number we start with see we do this because otherwise we would lose the initial value that we pass and get undefined we then create an instance of a depth class and then we go ahead and redefine the number property on data by saying hey call depth depend whenever this property is accessed and then return the internal value or whenever this property is updated let's go ahead and update internal value and also call depth notify now this takes us pretty close to our goal because now we don't need to call notify handlers manually and because every time number is modified the setter is automatically called and that pretty much does our job what we need there is another piece to solve here which is we can have a lot of properties in our data so how do we make all of them reactive and the solution is a very simple converter function that is just the exact same code that we have written previously but it just loop through it's just looping through all the properties in our data so the thing to note here is that the closure function that we used for for each is what allows us to create new instances for depth class and then each property and the getter and setter have access to that instance so that closure allows us to create new instances for each property all right so it seems like we have solved a lot of our problems and we can go ahead and change our watcher function a little bit because when previously we were doing depth depend manually but now since the getter automatically invokes that part we can get rid of line depth depend from line number 5 and our watcher function is now a leaner function well so it seems like we have pretty much solved all our problems so we have scaled the solution we have stored our dependencies automatically and we have also done the notification part automatically whenever the data has changed so here we are we have pretty much solved it right and if we do go ahead and make that javascript library that we were talking about we can now set it open source it and call it a framework killer already all right but how does what does this have to do with all the render thingy right we use render function when and we use templates right so how does that work in here if you think about it templates are just an abstraction which get converted to render function and this render function depends on component data so when we pass that function through our watcher all the dependency collection happens now whenever the component data changes it calls the render function automatically and we have our UI updated automatically voila we can probably go back and look at this diagram from view js documentation and it might now start to make a little bit more sense as to what is going on the system we have built so far is great because it's great but then it's not flawless we know there are edge cases that we haven't covered so our choices that we have took so far has made things vulnerable at quite a few places and I'm going to go through all the bullet points right now so the number one is we must declare or initialize all the properties we want to be reactive remember our converter function that converts all the simple data properties to reactive ones that converter function runs only once during the life cycle of a component so if we want property to be reactive we must declare them beforehand so that's why we do something like this in view and this leads us to another problem which is well how do we add a reactive property after the component is created because well the converter doesn't run and view comes to the rescue by providing us with a special method called view set which is a global method and this allows us to create a reactive property on any object in your component now we can use the same as this dot this dot dollar set in all of our component instances it just proxies the same view dot set method the last but not the least and in fact it's the most important one is that our reactivity system fails when we modify arrays or objects using the square brackets notation it doesn't work because in this way the setter or getter which are core part of our reactivity solution won't get invoked and view helps us here by patching the original push method by slightly by to make it possible to detect changes and we can also go the immutable way and then assign an entirely new array to our data so that works and this all of these bugs all of these edge cases have kind of led the future development for view which is where proxies come in the view new reactivity system is built on ES6 proxies I'm not going to go through all the things that are there because that might be talking it itself but I'm going to go through all the bullet points again so number one we don't have to use $set anymore because proxies allow us to declare reactive properties anytime we want next we can use the array notation to update or modify arrays and that works so our code can now throw away all the hacks that we were going to arrays to work and since we are throwing away all of this jargon that we used to create a setter and getter for all these properties and it was a giant object mess we were consuming a lot of memory so proxies come in and they help us get rid of all of that and make the memory footprint much much smaller it also doubles the speed than what we get in view 2.x and we all get all of this due to this amazing thing in the view ecosystem that API remains same you don't have to do anything on your user land code and all of these improvements you get under the hood so hopefully today we now have a better understanding of view internals and the problems associated with it and this I am hoping that is going to help you write better and more robust components and make it easier for you to debug view apps so thanks so much, thank you for being a fabulous audience feel free to reach out to me on twitter and link anywhere or in the open space so we have time for just one question maybe yeah so everybody understands reactivity now or nobody understands alright, thank you so much then so after this heavy talk we are going to do the flash talk sessions so first we have satyendra who will talk about deploying last scale applications at scale satyendra yes can we have the other persons yatharth saras and satish here yatharth and saras awesome so good afternoon to all of you and thanks for giving me the chance for the flash talk so I am satyendra from publisic sapient so we are assuming you all are the very good developers you can develop the very good applications so now we talk about the deployment so here is my flash talk is depend on the deployment of the view application at scale so as we know there are 5 minutes only so we have to cover a lot so deployment is equivalent responsible for the development as equal to the development so initially problem is that how you define application need a large scale deployment because large scale deployment is bit expensive we need large set of resources lots of factors are included in the large scale deployment so first we have to identify why as I think Kunal already explained what is a large scale deployment I am adding some more points to that so basically large scale applications need the large scale deployment so large scale applications is basically there are certain factors this is a one factor performance issue so if your application is going to serve the million or billion of the users so that means your application is bit complex, bit large along with the team size and all things complexity, logics that's a part of development but if we are going to the production so first we have to identify at least when we are starting a business so we have to set the target audience how much target what is the outcome of this so this is the one point and next one is our scalable our application when the time load comes when the work pressure comes it should be auto scalable next one is distributed so most of the time we have a set of languages for the different countries so our application should be able to serve the lots of countries with multiple geographies with the same code base and all that and if the issue arises so we have to be very sure in monitoring capabilities so that we can fix in one sort of we have to be very careful while monitoring the issues so these are the basically problems which leads to the scalable deployment of view scalable deployment which I am talking about it is not specific to view application but how we are deploying our javascript application my topic is covering that basically so architectural issues most of the developers are included in architectural development designing and all things so this is basically when we are calling a component from the several other components so it may lead to the latency issue it may lead to the bottleneck issue because single component need to serve all the multiple components and overall outcome of these are the business laws as someone said and I found a slogan from this source so 61% of the user won't give a second chance to the app if you feel this is not workable or if you see the crash so large number of audience is going down if you are not deploying your application at a scale so we have to be very careful while deploying our application and everything is lost so result is this everything is mess up all things so one solution is so we are going to deploy our view application using this three pillars Docker, Kubernetes AWS, EKS so I am a little bit explaining all these things what is this so step to first get ready your view application so second one is Docker so I hope most of you knows Docker how many of you knows the Docker yes perfect sounds good so Docker is a container or you knows very well so Docker is a play big part in deployment and next one is the Kubernetes how many of you knows the Kubernetes okay it's a quite few less than us okay it's a basically kind of a Kubernetes controlling the things so over the deployment so this is a basically which I am going to show this is my solution for the LISC deployment GitLab is a very related to view but now here we are using as a continuous integration tool and next one is Zenkin Docker is to build the image of our project next one is AWS Kubernetes is here managing all the act like as a load balancer where it includes the auto scaling feature at if we are doing the same thing on the AWS ECR so it's a different way without Kubernetes we can deploy but this is a way so basically this is a diagram which are intent of my flash talk thanks all thank you Sati so much and we can continue this discussion in the second view if Sati will be there to answer any queries any you may have so the next topic is something that we don't talk much about accessibility so we know we should do it but we really end up thinking about it so Satish Kumar is here to give you his experience of an introduction to accessibility please give a big round of applause to him okay so good afternoon to everyone at least for 5 minutes please don't sleep okay so the first question I want to ask you is since morning I have been here so how many of you saw me how many of you thought of meeting me and at least talking to me okay it's not that I am going to say that okay I am a big person or VIP there is a reason I asked you this question so when the introducer introduced he said accessibility we always talk about and finally we just leave it so that is the reason I told you so unless we meet the real time situation we may not understand what accessibility is and why it is important so before that I work for DQ systems how many of you have had experience using viewJS axe plugin for accessibility okay that axe core itself was developed by DQ systems for which I work okay so I am a senior accessibility consultant with close to 9 years of experience and my industry experience is 11-12 years already okay so what I would like to tell you I just want to stress few points about accessibility I don't want to bore you about that so one is making application accessible I mean your web application accessible okay many people think doing accessibility is charity oh we are doing it because they are powerful okay please don't think that because if you are making accessibility where your web products accessible you are tapping into 6.92 billion dollars of money in our pocket so accessibility is not a charity it's a business so that is the first thing and second thing is accessibility is legal also so how many of you know that in India all the public facing websites and web applications mobile applications must be accessible by June 15, 2019 so from that date onwards any individual or an organization can sue a product an organization if that application is not accessible as per the law so this is the second point I would like to tell you and third is as I said people with disabilities are there is another myth about accessibility that in the morning session somebody was talking about accessibility I mean I really feel happy that he was really touching upon that because many people don't do that not because they don't want because either they don't have time or the organization gives less priority to that I am not blaming anyone here but what he said was something that was alarming to me because he said accessibility is all about only per visually challenged people so there all of us are wrong so there are so many people with disabilities one is people with blindness people with visually low vision people who are color blind people who have different types of vision like you know central vision side vision and all those stuff and then people who cannot use their fingers why do they matter to us because obviously either they can't use a mouse or they can't use a keyboard so what they will use the speech recognition software there is a software called naturally dragon which is a paid software windows has speech recognition in itself now mac is also coming up with such a system so that is one more thing and then you have other cognitive disabled so people who have dyslexia I think a lot of people must have seen the movie tarazam invert no so that itself is another thing so when they grow up obviously your learning management platforms that you make with ujs must be accessible okay so people who are photo epilepsy there was a cartoon in 90s I think I forgot the name of the cartoon so when there was a flash content that came in the cartoon and within one second around the world 600 people had fits because of viewing the flash so I forgot the name of the cartoon actually probably so this happened because within one minute one second threshold the content flashed more than 5 times and that triggered an electric impulse and people got kids got particularly fits so this is called photo epilepsy there are types of disabilities and the digital content has to cater to all of them otherwise we will lose our business so that's what I wanted to tell you and third is and the last one I would like to make make an impression is I was searching for how ujs widgets are accessible or how many of us are really making ujs building widgets components that are really accessible taking care of keyboard and taking care of other design design related matters and then providing proper notifications and everything obviously vjs is I mean I don't see much development in that although there is a github page which showed vue 11y and there is a content plugin made in vue js and there are other projects that are going there and there is a heading called 11y in that github page unfortunately I don't have the url with me so please search for that accessible widgets in vue js or built with vue js you will get a github page but I would like to see that because the other js libraries how come up with many accessible components you guys as developers please build more components so that more applications come out they come up out of the box with accessibility built obviously you and all the organizations can make money out of it even though it is open source it is open source so we can make a lot of difference in the world we don't need to depend on anyone so if we can build those accessible components obviously many are going to use it and many sites are going to be built with accessibility in mind so from now on keep this in mind accessibility is not a charity it is a business so with that note I take leave of you thank you so much for patiently listening thank you satish for these wonderful insights I hope if there is one thing we could take away we could really take atleast these insights into our day to day work when we resume work with that we move on to the next flash talk so this is around deploying SSR with view by sarasarya hello everybody good afternoon this is saras and today I will be giving talk on deploying server side render applications with view so how many of you are using nux js cool quite a lot of folks that's nice just a second the laptop seems to have some issues of course what's a conference without you know things giving us issues just a sec something seems to be not working I'll probably do it atleast okay meanwhile saras fits it let's listen to the next talk of Riyadh so I'm actually a bit unhappy because I'm having no slides and I cannot there's no place I can put up my twitter handle I can get more followers yeah but so okay my name is Yatab and I work for a company called Pushal so I'm here to tell you a short story about my experience with view being a long time react developer so just 3-4 months back a little more than that I was just browsing through repositories on github and I saw that view has surpassed react in github stars and that got me really curious and I wanted to learn view at that point of time but that was not the only thing a few other reasons for example I wanted to break free from the react way of thinking react developers will know that if they are new over here and also I was kind of really bored of writing the same extents react.component syntax for past 3-4 years and finally it's good to learn new things so that's one more thing so a few things that got me instantly fall in love with view are first of all even being a framework it has this wonderful component like architecture something which libraries react providers second thing is its reactivity reactive data model which totally compliments it the third thing was its rendering system how it renders like it has this powerful template system but along with that it also has these render functions where you can actually put in JSX and it's very similar to what libraries like react have and that's really impressive and finally I was very very very impressed by the virtual DOM now the virtual DOM of view if you know that I would try to understand it's not similar to what libraries react have so it's actually very smart go ahead and try to understand that now if you try to compare react and view that won't be fair because the two things in my opinion are very incomparable because one is a library another one is a framework one was created by like a tech giant like facebook to solve its own UI problems another one was just a side project basically but even if I would like to say if you mention few points which you might be interested in for example the learning curve it's actually not so steep as compared to react you can quickly get started the official docs are really great and even the source code if you try to read the source code I'm sure you'll find most of it making sense to you in the first go which is not in the case of react for sure and then if you talk about the performance the DOM manipulation is really fast faster than react yes and also even being a framework it ships less code I mean like it's almost 7 to 8 kb lighter than react that's also wonderful and if you talk about the code the code style the view components actually follow a combination of functional and hoop structures and whereas the react follows just functional and what I really liked about the view was the life cycle methods they're very clean, very neatly done and they do exactly what you would expect them to do it takes a little while in react that you are working with react for a while and then you try to you are able to understand them completely so yeah so in my opinion the view was a great choice and a few things which I really liked I would like to mention over here that it's easy to go I was able to write the to-do app in just 4 hours when I started learning it the second thing is view templates are dope they are really really smart they do much much more behind the scenes than you would even able to understand when you are first using them and also view x is the better redux although view x and redux are both inspired by the flux architecture view x does its job better than redux I mean like it integrates into view x view better than how react react react that does its totally wonderful and finally the boilerplate tools are also awesome they are equally good as compared to the react counter tools and yeah although I was there were downsides as well for example coming from the react background it was a bit of bumpy ride to just adapt to view CSS in JS hurts a bit although yeah I don't think it'll ever be over there in view it's not just made for it and finally yes that's it that's what I wanted to say awesome so we have had that talk react developer loving view so yeah lets we have the last flash talk for today which is lets welcome back Saras for his talk on deploying SSR in view cool seems like there was some random issue with my laptop cool so I mean we already had a talk about deploying large scale applications but most of us don't really have those large scale applications what we have is medium scale size application running about say 15 20 pages stuff like that so this is around that so myself I work as a UI architect at anata as architect one of my jobs is not to just code but also to make sure that all my developers are actually deploying their changes faster and all the deployment systems it's my responsibility to set up all the deployment systems and explain it to them in case things go south so this talk is going to be very highly specific I'm going to assume that you already know something about AWS and you are already using some SED tools like CircleCI so there are generally two types of usage applications you can build one is the client-side rendered application and one is your server-side rendered application deployments are not so much hard with server-side rendered applications they are pretty straight forward to do and so what you can do is you build which actually takes all your components runs it to webpack generates all your disk files index.html you upload all those things via some sort of build script to S3 and you run some invalidations to clear your cloud front cache so that's how that's a pretty standard way to develop if you go to next website you can see this instructions laid out pretty beautifully but deploying server-side rendered applications is harder I wouldn't say it's hard but it's kind of non-intuitive but why is that so a server-side rendered applications first of all needs a server running which means you necessarily need to have a server which is in my case would be an easy-to-instance and nginx as a web server then you would as you I don't know how many of you know but server-side rendered applications in JavaScript for nux specifically run synchronously so every time you request a website the whole page is rendered in a synchronous manner and in a blocking manner on the server so if you don't have any type of caching for the same apps that are being rendered over and over again you would probably start seeing 502 requests on your server so you need some sort of caching probably on the nginx level cloud front level or your redis level but the thing is that you cannot build view applications at the server on which you are running the code so you cannot just go ahead as such into the server git pull run view build command does anybody have an idea why would that be okay so one of the things is that if you start running webpack that actually takes up a lot of your cpu your cpu if you do an htop command while you are running a webpack build on your server you would see cpu you are shooting up to 100% which means none of your apps are accessible at that given instance so if you are deploying right in the middle of the day or right in high traffic conditions your app will suddenly go 502 for a lot of people you will be back then so that requires a different kind of solution so in that case you would have so ci would be view build and using test cases and continuous deployment would be using build resources so basically you will build on a separate server and then try and then copy all those build files over to the actual server and then restart the server so there is a lot of code here I would like to run through it very quickly circle ci has a concept of workflows and jobs you take a job and this job is named as deploy which is mentioned here you take a node 10.5 docker image go to an app, check out SSH keys check out that whole repository run dependencies, go to the yarn file save all that dependencies so that you know you are not re-running yarn over and over again because your dependencies haven't changed then you basically start your deployment so now your app is built and it is ready to deploy one of the files that I have mentioned is deploy.sh so here I put all my all my environment-related variables then I just use this rsync command to actually take .nuxed everything that is there in .nuxed file copy it over to the server and just run pm2 reload while assisting into the server to deploy this I use this command this is the last version and I have the kit tag command so I just push a tag instead of running it on each and every branch so I know this was a very short talk and I ran through a lot of things quickly but if you have any doubts on any of those points and you need any details do catch me offline, thank you thanks Saras and good to be back here as a stage guy so how many of you use web components or have used or tried there is something going on in the world regarding web components so web components give us ways to share components written in one framework to be used in other frameworks where we use view or react or angular it doesn't matter and view goes hand in hand to provide that platform to us so next we have Karan who is going to take us through how you can build web components using view so Karan welcome on stage hi everyone my name is Karan and yeah my talk so I was working for Zoomcar recently and my talk is about using web component and view like using your view as a web component yeah before getting into the talk I would like to I would like to tell a few more things about me I am Nepri Bhata a GS enthusiast and if I may say so I am an audiophile the first one is just a pansy way to say that I am a dreamer so yeah I would like to start my talk with a story story of a printed developer like you and me let's call him Goofy because why not and bear with me there is a lot of weird gifs coming in so yeah this Goofy is really a good front end engineer and he tried to follow a lot of principle when he is building stuff and one of which is DIY don't repeat yourself so what has happened is one fine day his PM comes to him and he is like Goofy you know what I need a gallery slider on this particular page of a website and Goofy goes like okay I can do that and he looks at the code he finds it is on view and he was able to build it out on a given point of time and everything was awesome it was like 60 FPS and everybody was happy wish it was the end but it was not so on the other day PM came back and said like okay you build this really cool slider I need it on any other page on the website and Goofy was like okay it should not be a big deal I have already a component in view all I have to do is I have to use it there and he was like very happy okay that should not be a problem I will do it in very short span of time then he saw the source code and he was like this a reason being to his surprise part of the website was not in view it was either a vanilla javascript or let's say on react and only option he had then was to rewrite the whole component maybe in react or vanilla javascript or whatever the language it was on and he was really unhappy because he built a really good thing and he can't use it anymore so Goofy wondered if there's a way he can use his existing work into a different environment like I am just wondering how many of us have been in that situation before like quick show of and if that is the case okay cool very few people but that does happen yeah so I was in same situation sometime back and yeah so but Goofy then did what all of us love to do he googled and he googled a lot and he found something called web component and he was really interested into it and he was able to do it and he was happy just saying again quick show of and how many of us even like have heard of web component like we know what web component works awesome yeah that's a really great number so let's get down to the problem what Goofy was facing in first place so view component are limited within the view js environment you can't use directly inside a browser browser natively do not understand what view component has to do and the solution which Goofy has in his head was let's convert the view component into a web component or custom element with browser can understand right of the box so that is the reasoning behind why web component I have already told what was the reason he looked after web component let's get to the definition like the bookish definition web components are set of platform APIs which allow you to create new custom element new custom reusable encapsulated HTML text lot of words there let's break it down custom text it means that you can have your own tag which browser will understand and it will do the specific thing you want to do and it will be similar for a browser like any other div header list is reusable because we'll get into detail how it works essentially it is like you have a javascript file which defines how that custom element is fundamentally and then you use it in places where you want to do all you have to do is like include that javascript file and include that markup where you want to use it so that is the part where the reusability comes in encapsulation this is really interesting so web component uses something called shadow DOM we will again get into detail what that is what it enables us to do is like it encapsulate all your styles within a tag so no matter where you are using it the parent style will not interfere with the component style and yeah that's what it does so before this in definition we said like it is a set of web APIs right and essentially those are like four fundamental things which compose together to be a web component custom element shadow DOM and yes module and I think at least for with yes module we are like we know what yes module is at this point of time and I hope most of the people already know what templates are so custom element what a custom element I think I have defined that pretty well as a web developer we are able to build an element which serves our need and yeah that's pretty much it on the custom element side it has its own behavior in short like we have input type calendar right and then you somehow magically get the calendar inside the form so that is a sort of custom element let's get into the thing which we were discussing before the shadow DOM so in some sense it fixes the CSS and DOMs because now you are writing a component which is custom right and you want it to be reusable so how many times it has happened that you do a lot of names to make sure that if you are using this component somewhere else no other style is causing that component to break so what shadow DOM does is encapsulates all the style implementation and although there when all those structure within that and so the parent component styles will not be directly affected will directly be affecting the child component so sorry so shadow DOM is basically a normal DOM only difference is how it is created and how it behaves in relation to the rest of the pages and ES module ES module is nothing but sorry sorry my bad, STML templates so STML template is just a mechanism to say that this template exists browser will not render anything within that template but you have a way to handle that using JavaScript so that is how you do templating within the web component and then ES module so okay ES module what is the module module is just a JavaScript file from which you export that is the basic understanding of what module is and then you can export and import the module and function and you can call each of this function and you can get that functionality within where you are trying to import that module right lot of jargon I know you might be feeling sleepy already so web component in action so as you can see this is the home page of zoomka.com and we are in process to adopt a web component in this place and if you can see this whole thing this whole search bar is actually a single web component the definition is somewhere here is like you are including script as a module you are giving the part to it and then you are defining the markup so this is the reusability part we have a scenario wherein we have this search widget in multiple pages like one place where we just have HTML CSS a few places where we have view in place so that is when the web component shine because you only have a single component a simple markup which takes care of all the implementation details so this component does a lot of things we will get into detail in coming up slides so you must be okay this is all cool but I am here for view and why are you telling the web component for so far but the point is the problem Goofy was facing he had a component in vu and which was working fine for him but he wanted to use it somewhere else maybe in react how he did that he did that using this module web component wrapper so basically what it does is like you have to get into web component so only thing which you need to remember is like it still needs view it is not like you are getting rid of so it is not like when you are bundling it it is not like you are getting rid of view altogether you have to have view because in the end it is a view component wrapped as a web component and let us get into how we can convert our view component into web component so in this example in typical scenario you import view you import the wrap function from web component wrapper then you import your element and then you define that element and maybe some option if you have and then you wrap basically your component using wrap function to create a custom element and this is the last line which you can see line number 12 is basically a standard way so your element will be available with the name of may have an element in this case this element actually takes a props with the message and shows it to the user so in next slide we are going to understand how you can use it so as already discussed you need to have view because this component does not build view component wrapper does not build and takes view inside your component reason is you may have multiple web components to make sure that you are not having content code if you are putting view inside each and every web component which you are wrapping it will be a lot of redundancy then you have the element definition which we saw before and then you can use it and if you notice you will find that the props message is directly working without any other work so remember this is a web component which is running on normal HTML file and to make the props we do not have to do any other work it will just work and that is all you need to use the web component which you have built it just some time back so the thing to notice is all the props event and slots are actually being proxy what I mean by that is if you have a props defined for your component it will be available for your web component as well same goes for the event and slot only catch in slot is the scope slot here is not supported at this point of time because it's a view specific concept that's about it that's all you need but problem with this approach is you have to always wrap your component into using view component wrapper and if you want to get rid of that and you must be wondering how that can be done that's a relatively very simple step actually you can have this inside your package and which essentially says that build this with the target of web component and then the path of the view component you want to give and if you have one more than one component you can give a and you can pass some sort of name scoping so what it does is like it takes the name scope the first and then it takes a file name and build it so if you include this step what you can do is like you can have your view component in your project working seamlessly and then you can also build web component which you need for to be used in other places right yeah so that's pretty much it actually and that's all you have to do to make sure that your view component whatever you have built so far works everywhere talk let's get into the demo so remember I told the problem Goofy was facing so if you see this project essentially is a react project and okay this works fine and if you can see this is sorry I'm not sure whether it's visible it's visible you can see that inside this this looks like an actual tag already right and then we have shadow root something called shadow root and what I was talking about style encapsulation right this whole style is a part of this gallery component so point is then all the style and everything which is required for this component to work is resides within them and the parent style will not interfere with any of the thing which this component has to do so this one what you're looking at is a react application I will get into the code if time permits the other way is this this is again typical html file which has this by component and inside I think what did I have defined I think I have said I need view and I need definition of that component and then as a markup and it will just work so sorry so again you see the underline implementation within the web component remains the same it works as if so basically because it is natively supported right it does not require anything else in sense of like customization to make this work and all the props and property will so what you're looking now is the view component because it's a view project so I can use the component which I built inside the view directly so that is the proposition here you don't see a web component implementation but because it is not required that's it yeah and yeah we are done with the demo but I guess there will be like some people like dude I know web component but tell me if I have a web component can I use it inside a view project and actually you can and it is even easier so when you have a web component essentially it means that you have the definition for that component and the tag all you have to tell view is like please ignore this tag so bit context on this so modify search what you're looking at is a part of the search which we show on search result page and we don't want view to complain about this element has not been defined because this will be the part of the template that we are going to render that so we just say that please ignore this bit that's all we have to do to make sure that web component is working and the places where you want to use you include the script file and the tag and the props which is required we will get into like how that is implemented and this is action so what you're looking at right now is that modify search widget and it has couple of things going on so what you can see here is a radio button basically but it's like a tab so there's like each component in each tab and then this whole thing is again a component which comprises of two small components so here you can see a pattern of composition idea behind that is let's say you want to only use the speaker in some other places you can use only this bit you don't have to have everything else and similarly use for the calendar component and then you can compose it together like we compose our divs list item or header or whatever so it is very much like you do your typical web development it's nothing special going on here per se yeah so let's look at the code of that of the very same thing the modify search widget so here the definition of the widget itself whatever the behavior the skin you see this type and this is how you use it so this is very much this look I understand there's a lot of noise but let's get into like specific bits so what you're here seeing is like this attribute which is a bind it to a very like scalar value in this case string and then you also have attribute binding and the reactivity works flawlessly so in this case the desk address the source address and everything else is actually a view data so basically a variable which is bind it to the search modify custom element and same goes for the reactivity so what you're looking at if like you can see line number 23 here this web component is actually when you click on search or modify it is firing a custom event which is named as modify search submission and when it is firing that you can actually listen to it inside view and then you can handle it and perform the action whatever you want to do so the crux of all this is it is like your web view component it's nothing different yeah I think this is redundant we have talked about this bit let's get into performance so the problem is like when you're using when you wrap your view component as a web component and you're using it inside let's say react application as we have seen before you are actually loading view and then web component definition and this is not a production screenshot this is just a basic gallery what you have seen performance of that but if you notice all the matrix is same except performance because web component needs to load few other things to make it work and this is given I'm not using polyfill if you have to use polyfill that's another performance so this boils on to the decision wherein you have to make sure that your component is complex enough which is not worth building it again maybe in some other framework and if that is a thing and you are able to take that little bit of performance hit then and you are saving huge time here that is the proposition behind using web component in other frameworks so I will touch upon few best practices which you should keep in mind and I had a few of them which I have learned hard way first is encapsulate your style what I mean by that you because it's a shadow dorm right so the element shadow do ensure that regardless where it is be used if you apply styles within the component it will be same and specifically when you have a shadow root and then inside that you are using another web component so that goes nested and that creates lot of challenges if you are not encapsulating your style properly then yeah create your shadow root as the constructor so I have not given the brief understanding of like how web component looks like in general like they had their own life cycle so when you are creating your shadow root you want to make sure that you are creating it inside the constructor but not somewhere else for example connected callback like please connect offline if you want to get more detail into this but yeah and place children of the element created into its shadow dorm so if let's say your web component is creating new children you want to make sure that please inside the shadow dorm again for the same reason that the javascript and CSS will work seamlessly if you do that otherwise outside javascript may affect or interfere the new child and yeah this the fourth one is really interesting so point is let's say you are setting tab index you are initializing tab index to minus one and if you do that that component will not be accessible using keyword that will not be focusable right but when you do that you won't and maybe that is what you want by default but you also want to respect what author has to say so author in this case is the person who is using that component you want to make sure that if author is giving it tab index zero and he wants it to be focusable and if you are not listening to that value what is coming from the author and you are setting it by default to minus one what will end up happening is component will not be focusable from user so that is one thing which so this goes with any other global attribute which an element has and so this the fifth point I actually had to spend a lot of time to get it right because when I was building component I had this option where the properties and attribute of an element will always the same and that is not the case so basically properties are are the things which can take rich data set for example objects already but that is not true when we are calling when we are thinking in terms of attribute because attribute can only be scalar maybe a boolean number or a string so you want to make sure that you pass this data using attributes sorry using property not attribute because otherwise you have to json.stringify make it to the string and then pass it inside the component which is not good for performance two more things in in terms of best practices first is like internal component activity dispatch events so for example you have this component which makes some API call and then you you want to make sure when that API call passes you dispatch some event so the parent was using that component is aware but if the component itself does not do that the challenges the parent will not know when something has happened so if you are doing something you want to make sure the parent is aware of that activity and the seven point goes with it like if a parent is setting some value yeah so if we are dispatching a value when the parent is setting that problem is now you may have circular data dependencies so what I mean by that the parent is setting some value and then you are dispatching an event maybe parent is listening to that and setting other value so that may get you into infinite data loop which you don't want to be in data binding system yeah and every other technology on web web components are also not perfect so there are like things which you have to do manually and you have to figure out what works best for you in case of build system and the distribution is now relatively sorted but there is like lot of boiler plating when you create your hello world component you will see there is lot of things which you initially at least I wondered why I am writing all of that and then mapping between properties and attribute is something which you want to make sure you do that otherwise you will be like I am setting this attribute here but I am not getting any property so you have to have a proper setter for that and let's look at the browser support at this point of time so I am going for the four pillars or like four fundamental APIs which comprises web component custom element have around 73 HTML this is global actually HTML templates are pretty decent right now it is like 93 and shadow DOM is somewhere around 75 so accumulatively if you look it is pretty much decent but so there might be scenario where you want to make sure that web component works in like you know older browser as well or maybe in some places you want to have a polyfill so web component loader is something which you can use to make sure and what it does is like it only loads the minimum number of polyfills which is required by doing feature detection and there is also a standalone working lightweight version of W3C custom element specification which is already in production by Google AMP project so yeah they are using it heavily unfortunately there are few things for example styling encapsulation which cannot be polyfilled yeah so that's about it thanks for being such an awesome audience yeah thank you like a mind if we use at the end so we will move on with the next speaker so so even using webpack right so it is pretty much de facto bundler of choice but when it comes to configuring it might be a little bit challenging so view takes care of all that using view CLI and still allows us to make tweaks as necessary now Heymanth has been working with view for over 4 years now and he will share you some of his tips and tricks from his long journey and he will basically tell you things about how to supercharge your day workflow please give a hand for Heymanth the topic for my talk is webpack plus view loader recipe for supercharge view and let's start with the most cliched start that's with the quote I do feel this quote encapsulates the essence of what we are going to target in this talk and we will see how the tools that we have been using for our development workflows have actually improved the way we think about development specifically when it comes to view development because we will be focusing on view so my name is Heymanth Ray I come from Bangalore's not so cool I am a cousin city of Pune and I have been working with view from around 2015 we have been using view in production and over the years we have seen different dev workflows that catered to view development starting from webpack 2 if I am not wrong and then 3 and then currently webpack 4 so it does require a recap given the long history that we have had of our different workflows it does help us if we can go through a small recap of things specifically to understand why we should use webpack so there have been some generic ways of consuming content in browsers specifically JS content the first and foremost was using script tags so you just have a bunch of script tags for each dependency that you would need in your project but it came with its own issues stuff like if anyone remembers the jQuery development ecosystem when you include a script had a major repercussion on whether those scripts are going to work and work in the way you expected them to or not similarly the second option that evolved from that script tag implementation was to concat everything in a single JS file but then that led to another problem like scoping and maintaining the entire code base in a single file which was also used in a single file in a single file in a single file in a single file in a single file in a single file in a single file in a single file which was always a hassle so over that period NodeJS came into being and with NodeJS a new problem came into picture that was how do you consume JavaScript within your NodeJS applications because there is no HTML there is no script tag over there so CommonJS introduced us to the concept of commonJS was the time when require was introduced and require actually brought us to the modular front of JavaScript but before that there was something called IIFEs which is immediately invocable function expressions what they did was that they encapsulated encapsulated everything encapsulated different strings stitched them together while taking care of stuff like scoping and this is actually where we saw the advent of different task runners stuff like gulp and grunt and make where we could then use IIFEs to better bundle our code bases into a single bundle but then that had different problems particularly when it came to performance stuff like preshaking was something that developers had to do on their own even though we were getting there we were not actually there there with the advent of task runners and that brought us to modules the way we were just talking about when NodeJS was introduced modules were evolved to work with NodeJS and the concept of modules was actually used further in bundle scripts that would later on be consumed by the browser itself so modules is where things started getting interesting and lastly we can talk about ESM although the support is not 100% but we can very well see that this is the future this is where we are heading and to be honest I feel stuff like webpack is actually a stop-dap solution because ESM is not where we want it to be so even though ESM is there it doesn't actually replace bundlers like webpack and everything that they do so we'll just try to take a look into why webpack in particular so many of you might remember many of these different things that we have been using over the years as part of our dev workflows in particular and because this time was cluttered managing all of this was cluttered developers had to do a lot of heavy lifting whether we were using tasks in us in that case we had to maintain our script files we had to envision what we wanted to achieve in the best possible way and it took several iterations to actually nail down a workflow which would actually work for you and will provide everything that you need to satisfy your development requirements and that is why we come to webpack loaders and plugins so we'll just try to do a brief intro because we'll be reusing these words over and over again so it's better to set a simple definition of what we are trying to save and we are saying particularly loaders and plugins webpack as you most of you might know is a JavaScript bundler the main functionality of webpack is to create bundles out of the scripts that it sees and we'll look into how it does that in the slides later on but we'll talk about loaders and plugins before we begin loaders allow webpack to modularize files other than JavaScript so webpack by default deals only with JavaScript but we consume a lot of other file types we different sort of templating all sorts of things we want to do different preprocessing, post processing and all of this is mainly supported by the use of loaders so loaders actually tell webpack how to modularize something other than JavaScript and then to make it part of its own dependency graph which we'll look into a little bit later but basically loaders are how we are able to use SAS instead of CSS for our styling or typescript instead of JavaScript or even later versions of ES standards while supporting all the legacy browsers and everything so most of this thing is provided to us by loaders anything other than JavaScript that webpack is handling comes to us through loaders and last but not least plugins so loaders are kind of dumb in a way that they only tell webpack how to handle that particular file type whereas plugins actually allow us to tap into the actual webpack configurations and do stuff like optimizations and various other build optimizations, asset management all the other things that webpack allows us to handle most, we will do most of that using different plugins so webpack, loader and plugins together they form most of the current dev workflow that we follow particularly by developing view applications and just a spoiler but as the topic suggested recipe for supercharged view we are most of us are already using that supercharged view it's not something that we need to supercharge at least right now it comes supercharged out of the box with webpack 4 UCLI 3 so we'll try to mainly see what that supercharges so before we do that it would be better for us to just understand what is the normal state of view when using view library so view can just be included as a script view is a standalone library which provides you with many apis and features that you can use but that's it browser understands only html, javascript and css so you could continue using view as the same way we used to use jQuery at one point of time and that is the normal state of how we would go about using view js or building view js applications whereas once we get into stuff once we get into webpack loaders specifically view loader because that caters to the development requirements of view js in particular as well as certain plugins to do different things that previously developers had to do on their own so moving on we'll first take a look at webpack I'm sure most of you must already be aware but just to sum it up webpack is a module is a bundler for javascript applications but how does webpack work what actually happens is that webpack creates internal dependency graph on the entry point of your application so once you so this Jeff comes from webpack website and this pretty much sums up what webpack does so each and every different sort of asset that you might need to build your application goes through webpack gets bundled into static assets that you can just refer into html and it works simply so instead of having to manage this clutter we just have to configure our webpack to give us the static assets that we can directly consume in our applications and how webpack does that is pretty much pretty straight forward so if you look at the before part how things traditionally used to work is that you have your index dot html and then you have different script tags where you are loading different scripts and then the order in which you load the script tags actually define the way your global the global scope was created and then you can then use that going further but this part is completely manual you have to figure out what goes where and how you are supposed to do what whereas what webpack does is that it takes the same file it looks at the first entry point in this case let's say we have our app.js which is where we include all the resources that the application would be needing consuming so webpack starts at our entry point and you can have multiple entry points for example if you have instead of having a single page application if you have a multi page application you might require multiple entry points and webpack will support that and create dependency graph for each of those entry points so webpack starts at the entry point which in our case is app.js it finds each require or import statement that it does in app.js in app.js and it starts to think or it starts to refer to each of these your view.js, your view.outer your view.js as moots modules which are part of that dependency graph which is then later used to create bundle.js bundle.js can be a single bundle it can be splitted into much smaller bundles all of that will depend upon the way we configure webpack in our case so this pretty much is the this gives you a brief overview of what webpack does under the hood to create the dependency graph that is always talked about so that was a basic introduction to what webpack does for us now the thing is in today's time as view developers we don't need to work with webpack at all I mean because of view CLI there is an abstraction that is provided to us on top of webpack which means that we don't need to worry about what webpack.config actually looks like and in the older versions of webpack particularly webpack 2 and webpack 3 for that matter of fact webpack configurations used to be a beast in its own right and would have required a talk just to explain what that particular config does and how you could go about editing that but webpack 4 works with zero configurations out of the box but webpack 4 does make certain assumptions about your entry point and your output directories as well as a few more things but essentially most of us can continue using webpack 4 out of the box without having to worry about whatever configurations are needed but this is true for default use cases this is true where we don't need to do anything that the default configuration doesn't support there will be times specially in webpack 4 we will need to introduce newer assets we would want to use programming language or something that is not currently supported by webpack by default and in that case we will need to modify the configurations but instead of doing that directly to webpack we will look at how we will do that using viewcli and what viewcli does is that it provides us with two one that is chain webpack so we can make these changes directly in view config file instead of going to and referring to the webpack config file in fact that is the recommended way of doing it because there are certain configs that are used in several places by webpack and if you have scaffolded the project using viewcli not making those changes in view config would actually mean that you might not be aware of those changes and it might not be able to uniformly apply them across your application so it's even suggested to make changes using your view config files rather than directly tapping into webpack config at least if you have used viewcli 3 with webpack 4 to configure your application so as we talked about two functions the first one that is available to us is configure webpack now configure webpack as the name suggests will be used to configure webpack so there are two ways of using configure webpack first of all is the most straightforward way where we just return object with whatever configuration settings we need to be applied to our webpack configuration and in fact as you can see the example shows this is the perfect place for us to declare any new plugin that we would want webpack to use so as in this example we can have our own custom plugin or we can use one of the like in this example we are configuring style lint plugin to work with our application along with whatever configurations are needed for that so this traditionally would be done in webpack config but we can very well do that using configure webpack through the view config file itself another way of configuring webpack is so the previous example that we saw was pretty straightforward you just return an object you just make changes and it would be applied what if you want to configure your webpack based on say node your environment variables or basically if you want to do any sort of conditional checking after the lazy loading of all the everything has been done instead of the second option would be that we use configure webpack as a method and in this case what happens is that we get config which is the webpack config object and then we have two options we can either directly go and mutate the config object itself and those changes would be applied to webpack or we can return a new object in that instead this new object will then be merged into the existing webpack config and then the final output of that would then be applied as the final webpack config so in both these cases we are able to configure webpack for our needs for our requirements without having to without having to work with the webpack configuration itself directly through view config but this was very straightforward where we are doing some high level things we are just introducing some new plugins maybe we want two different builds for our test our test environment or production environment and we can do those small things over here but what if we want to get deep into webpack configuration and make some more changes do introduce some new loaders stuff like that and to do that view CLI introduces us to chain webpack so what happens is that behind the scene webpack uses a library called chain webpack chain and it maintains the whole config object the way we saw in the previous examples where you can either mutate that config object or you can return a new config object and it will be merged so for the merging it uses webpack merge whereas to maintain the final state of the config it uses webpack chain and chain webpack actually exposes some APIs which we can use to make changes to those config configurations in a way that will at least not break things and it will even make maintainability easier so you can have named loaders that you can then later refer to by their names and you can tap and get their config objects and then make changes whatever you would want over there directly so this allows us to have a very fine grain control over the internal config of webpack again through web view config files itself so there are few things that we can do which would want to see first of all would be to modify and would modify options of a loader so as we talked about in the introduction loaders tell webpack how to consume different sorts of resources and assets which are not javascript but at the same time we might also want to make certain changes to the default configurations because as I mentioned viewcli3 comes with a lot of pre-configured configurations and they do work in most of the cases but in cases where we want to make certain changes to these configurations chain webpack will come in handy like for example what this example shows is how we can we can find the view loader module view loader loader which is referred to as a module within webpack and we can use the tap method to find a copy of the options object that this particular loader is using and then we have we can make whatever changes we want to make to this config of this view loader configuration directly over here so viewcli will give us view loader with default configuration any changes that we would want to make to view loader configuration can be done directly using chain webpack option another thing would be to add a new loader so obviously viewcli by default supports a wide range of loaders for different sorts of pre-processes and other stuff but that doesn't mean we might not need to introduce new loaders because it's possible we might want to consume a new resource which was not part of it so even to do that we would again use the chain webpack option for that and as we get the config parameter over here we can directly define a rule we can set a regx in test which would be used to match against that particular resource type whether as a file import or as a language block within our single file components and then we define which loader to use and that's pretty much it so this way any file or any language block found with dot pug extension would be passed through the pug plane loader and this way webpack would be able to process pug instead of vanilla html for our templating similarly as I had mentioned viewcli gives us lots of configs out of the box so there are certain base loaders as we refer to them because these are the default loaders that come out of the box with viewcli but it's possible that we might want to make or we might want to change options of one of these base loaders or we want to change the loader itself so if we wanted to change one of the options we saw in one of the examples before how we would do that but in case we want to do away with the base loader and introduce our own loader we can again do that using same chain webpack in the example over here it's again pretty straight forward we are assuming that there is already a module configured for rule svg which it is in case of viewcli in the next line you can see that we are clearing we are using clear method what it does is that it clears all the configurations that would still be there for the svg loader if we don't do that any new configuration that we add would actually be merged into the existing configuration but we don't want that over here so we would just clear all the rules and then we will just define the new loader which would replace the base loader in our case it is view svg loader which would allow us to inline the svgs so the last option that we would want to look at would be because so far we would only be talking about loaders how to configure loaders modify options but the same thing will apply for plugins as well so if you want to define plugins we can use configure webpack to define these plugins but if we want to modify options of any of the existing plugins we can use chain webpack and instead of using module we can use plugin to refer to the plugin that we are targeting and again use the tap method to get the argument the config for that particular plugin and then make whatever changes we would want to make so over here in this case if you want to change the default location of our index.html we can directly make that modification to the plugin configuration although you can do that in other ways so this was where we were talking about webpack and the reason we were talking about webpack in such depth was because webpack forms the base for viewloader and viewloader is what supercharges the development for us webpack does that as well specifically by supporting all the new resources that we would want to consume but viewloader improves the developer experience by a margin we will see some of the ways viewloader does that for us like for example in so many talks today people have been referring to single file components as a matter of fact it's not browsers don't understand single file components but we write single file components as if it's pretty much pretty much like html and the reason for that is that viewloader enables us to stop thinking about how the single file component will be consumed by the browser it abstracts that part for us and we only need to focus on what the component is supposed to do and how it is supposed to be rather than how it would reach the browser and how the browser would understand it so that's like one of the examples which I found interesting given how comfortable all of us are with so many things that are actually not natively supported by browsers so one of the things is asset URL handling assets are a pain and making sure that all your assets are there in each of the builds is something that has always required a bit of developer oversight but viewloader helps us a lot with that and how it does that is that it takes any of the static resources any of the static assets that we would be using in our application and it converts that into a module and now then this module can be part of our view our webpack dependency graph and then if the module effectively it becomes a dependency and if the dependency is not there our builds will fail so this way we can ensure that any critical static asset that is required by our application is actually part of the bundle and the good thing is that we don't need to do anything to get this feature it works out of the box the thing to realize is that whenever we use something like an image src with an asset path it actually gets converted into something like this which is actually requiring that particular resource and this is how it becomes a module request instead of being a direct asset request viewloader also helps us by providing by helping us with paths to refer to these assets so you have your absolute paths you have your relative module paths which start from where you are and you have your module request where you can use still or even add that it which is actually a webpack alias but it would be available to us and these module requests actually point us to the root of our application so we can even refer to stuff so any of the static assets within say one of the packages in the node modules or something like that so it makes handling assets a lot more easier for developers without having to do anything to configure or figure anything out the next thing we want to talk about is preprocessors so in webpack all I mean as we talked about webpack webpack uses we can use different sorts of preprocessors in our application and these preprocessors need to have their corresponding loaders so that webpack can know how to process these preprocessors and how one of the cool things about view loader is that it allows you to have more loaders on top of view loader so you can actually chain view loader actually allows you to have to configure and use different loaders on top of it and that is precisely how we would be using preprocessors so what view loader helps us with is that it tells it figures out what loader to use for what preprocessor and it does that by matching the lang attribute for the or the file extension for that particular preprocessor that you are trying to use and again none of this has to be I mean it doesn't require any sort of developer effort most of the commonly used preprocessors are supported out of the box that you can opt for when you are scaffolding your project even if you don't do that all you need to do is that add those dependencies to your applications package.json and everything else the internal bindings will work without you having to worry about so stay at the time of configuring the project you didn't think you would be needing stylus for your styling requirements but later on you realize that you do need stylus all you need to do is that just add stylus loader as one of your dependencies in your package.json and view loader will take care of matching your stylus files and passing them through the stylus preprocessor so effectively what that helps us with is that instead of relying on vanilla JS TML and CSS we can opt for the language for choosing whatever is comfortable either for our development needs code readability maintainability whatever be the reason but we can opt for any of these instead of going for the vanilla options that the browser will understand and view loader will offload all the transpiling and making sure that everything gets delivered to the browser in a language that it would understand next thing to talk about would be scope CSS but before that I would like to talk a bit about CSS input like just CSS because as the front end developers CSS is something that would have tricked us at some point or the other maybe more often than we would you know want to accept but it's not generally because of the fault of the developer per se it's also because of the way CSS works and I'm not trying to talk anything negative about CSS I know it's a design principle by CSS works that way but it also has some side effects a very good way of understanding why we fall into so many traps again and again with CSS would be to imagine if JavaScript work like CSS so what would happen is that everything would be global which sometimes is the case and used to be the case not so long ago and it was a mess and every scope being hosted to the global would have so many side effects that the developer would have to take extreme steps to make sure that everything works as expected stuff like following very hard namespaces ensuring that the team of developers is in sync with what is going on and that is pretty much what happens with CSS because CSS is applied globally and a single element can be targeted by multiple CSS rules across multiple CSS files adds to that complexity and there are certain ways to handle this particularly stuff like your BEM approach where you but that requires a lot of effort from the developer and failing to adhere to those specifications can have a bigger repercussion so we have been seeing a lot of CSS we have been seeing lots of solutions to handle the CSS issue for us one common way is CSS in JS JS in CSS whichever one is the right one but the beauty of view is that I really admire the way they went about handling scoped CSS so what view does is that when you add the scoped attribute to a style tag you are basically telling view that you would want this style only to apply to that particular component so we are talking about the single file component over here and we can have a style with the scoped attribute over here and what effectively will happen is that view will add a data property to the targeted element as well as to the proper to the style that is targeting that element and that pretty much that's it that way we are able to ensure that our styles don't apply anywhere else than what we are allowing it to and in our in case of scoped CSS it would be that particular component so yeah this is a very clean solution according to me I really like this approach and it's not that scoped styles would limit you so if you needed global styles within your single file components along with scoped styles you can do that very well you can have a scope style and you can have a global style within the same component and which style will impact what part will depend upon whether that style resides in the scope part or the global part so scope CSS is not the only CSS solution that we get from view loader the second solution that we get is CSS modules now CSS modules is a project if I am not wrong by the same person who maintains webpack I am not really sure on that but there is a very I mean it provides very close integration with webpack so if you are not familiar with CSS modules CSS modules basically what it does is that it takes your styles it converts them into the most simplest description would be an object and then you can then refer to this object and then you can pick and choose which style to apply where rather than having to apply classes and stuff like that so an example would be something like this and as you can see our style tag now has the attribute module instead of the attribute scope which tells view loader that this would be the modules CSS module implementation that it will be needed over here one more thing would be that to have CSS modules you either need to use CSS loader and configure it to I mean you have to set the modules flag to true if you don't do that you can still consume CSS modules but then you have to add the .module.css sort of a nomenclature for that so just you can simply tweak the CSS loader's configuration using a chain webpack function that we saw and you can enable modules for your project and once you do that when you write a style in module it actually gets converted into object notation of sorts which can then be referred to either in your template or in your script so in your template you get basically what it does is that it creates that object and it passes it to your view component as a computer property with the name dollar style so in dollar style you actually get your whole CSS as an object and then you can figure out or decide how you want to consume that CSS so what is happening over here is that in the template what you can see we are directly doing style.red style.bold and effectively this is just applying those two classes onto this particular paragraph flag but you could see a more nuanced use of CSS modules where you want to pick and choose each and every small attribute we can refer to that dollar style object directly in our scripts using this dollar style and we can then use it to configure or apply CSS within our scripts as well so these to scope CSS and CSS modules actually make the developers life a lot easier especially when it comes to dealing with CSS there are some other benefits as well like minified CSS but we will talk about that later next thing we would want to touch about would be custom blocks so single file components view single file components support three blocks by default so you have your template block you have your script block and you have your style block and then you can configure loaders to work with these blocks specifically depending upon the lang attribute for all of these blocks but that's not the end of it it also enables us to create custom blocks itself so we can have a fourth block or a fifth block and then we can define the functionality of the behavior for that particular block and we can do that using custom loaders so we will go back to how we have been using view to configure our webpack to tell webpack how to process what part of our WordPress it's pretty much the same thing we would go about the same way we would have a loader which would apply to that particular custom block the difference being that instead of using the lang attribute the custom block would form so instead of having for example a script lang foo we can directly have foo as the tag and have everything within that that becomes our custom module which will be processed by the loader that we define for that particular custom block and we can then decide how we want to use it in our applications lastly one great tool that we get out of the arsenal is linting now linting is something that most of us I'm sure have been using for a long time there are two main flavors es lint and style lint but what linting is basically a process of applying static analysis to our code base to ensure that there are no syntactical issues so that the guidelines are being adhered to and followed across the teams which actually helps in making the application code base a lot more readable modular and to be honest if you are strictly religiously following linting there should lead you to a point where looking at the code you shouldn't be able to tell who wrote it because everyone would be writing precisely a very similar sort of code thanks to es lint and style lint now es lint targets by default the script block and the template block of our single file components and works out of the box in case we want to apply these lintings to our styles we can use style lint although it's a bit tricky to and it takes lots of iterations to actually nail down a style lint guide which would work for you I mean it's easier to set up es lint than it is to set up style lint at least has been in my experience but it gives you the same benefits you can make sure that everyone adheres to similar styling guidelines uses similar formats and the result of it would again be more legible, maintainable, readable style code at the end of it so take away so I know we have not been we haven't talked much about stuff that is new as in stuff that you were not already using most of you already but it does help in having a better understanding of what goes on under the hood because view does a fantastic job of abstracting so many things for us that developers don't really need to bother themselves with these principles but it's definitely a good knowledge to have specifically as your apps get more larger and complex you will need to utilize some of these options if not all and having the understanding goes a long way so some of the key points I would just like to point out towards the end would be browsers even today predominantly understand only html.js and css but we don't use these to build our applications we use a hell lot of resources to build our applications lest we forget that browsers still don't understand anything other than html.js and css the second take away would be tools allow us to go beyond so all these are the things that we have been using over the years to build our applications there have been some tool or the other which has helped us achieve that used to be task runners now we have come to bundlers who knows what tomorrow is going to be like but one thing is for sure as long as browsers continue to support only html css and js to support all the developers requirements and requirements you would need one tool or the other to ensure that what we write actually reaches the browser in a fashion that is understandable the third point would be these tools have to be managed and maintained at least that was destroyed till very recent times and it was a paramount of the developers to mostly manage and maintain these tools which was not a very straightforward thing to begin with if any of you would have worked with grunt and stuff like that in larger applications it becomes really difficult to keep track of what is going on specially for anyone new coming into the project and now what the current ecosystem provides us with vucli3 and webpack 4 is these tools are these tools don't need to be managed and maintained you can obviously extend them but things have started working out of the box which is a really great thing for developers so we can now focus specifically on building apps rather than how to manage them webpack vucli and view loader if you are working with vue.js apps these are the things which actually supercharge your developer experience even if you would not have acknowledged that till now under the hood most of the heavy lifting is done by webpack vucli and view loader they work together to provide from stuff like single file components to something like hot reload module which is great especially when you are trying to tweak those finite weeks in a component and all of that that we take for granted comes through webpack vucli and view loader and the last thing which is clear now is that future is modular modules, yes modules has already have a very high adaptability although I don't see legacy browsers ever being able to do anything about it as soon as they get phased out everything is going to be modular at least that's how that's the direction we are heading in and using webpack and vucli we can actually prepare ourselves for those times ahead by making sure that the components that we write today are modular and compatible with what we will be using tomorrow thank you so we are pretty much on time if you have any questions for Heyman we would like to take it offline and he will be available outside the area thank you Heyman so we are pretty much moving towards the end of the event and we are going to break for another beverage break and before that we have couple of announcements so on 7th September we have Root Conf is organized a workshop in Lua so if you are a game developer or a programming language enthusiast this workshop is for you you can check out about this more on hasgeek.com slash rootconf so we can now break for the tea session and when we come back we have a small case study from Flock as to why we chose Vue.js and then we have the most sort after talk of the day which is the keynote from Rahul so please stick around and I hope to see you here thank you hello so welcome back everyone after the break and we here have the Vue again and no need to introduce him because yes given us a lot of insights into how to build component now he is here to give us insights into how Flock the company that he works at has chosen the Vue framework for as the framework of your choice so he is going to take us through the journey so let's hear it from him to introduce myself because you guys were here in the morning and you don't remember it so I am I am a senior application engineer at Flock presentation is going to be an experience talk as to why Flock chose Vue for a lot of apps that we built so to explain the problem statement I will need to introduce Flock to you Flock is a platform for communication between teams so the aim that Flock has is to make communication between you and your team better and so basically it is a productivity suite it enables you to be more productive if you have if you have a Jira integration if someone created a Jira that has been assigned to you then you don't need to go outside of Flock to mark that Jira has done or maybe change the state of that Jira so that's what Flock is it helps you be more productive without leaving without making without more screens on your cognitive so the problem statement is that we have multiple applications that help you be more productive and because there are multiple productivity is not a single application problem it's a multiple application problem you have got to-dos, you have got Jira you have got GitLab you have got GitHub you have got Trello and so on so many tools that you have got productivity so all of those tools how do they interact with Flock that is through app integrations and because there are multiple app integrations which means that there are multiple applications and initially for these applications there was no defined framework that we'd use we'd basically go with any framework that you wanted like me and Flock and he even used functional programming once for our project and we also used vanilla JS we also used React to solve this problem and then we have also used View so the choices of framework were all over the place and they varied from backbone JS to everything to vanilla JS and these apps are supposed to be a part of Flock and even though they were being built and maintained separately we had to make sure that it did not feel any different the user did not find that the look and feel of this application is different so that is why we needed to make sure that the whole look and feel integrated into the whole Flock experience so this is an example of a channel and there is a to-do list with that channel so this is a to-do app integration which enables you to assign any task that you create or to do that you create to any channel member that you have so a channel is nothing but a group a group like feature in which you can add multiple people and you can discuss any projects related stuff you have on you could even add files like share those files with each other and so right now here we have the use case of a to-do app and you might not need Jira maybe if it is a small project if there are like 3 developers and you might not need you might not even need Jira because Jira involves a lot of workflows and you would need to configure those onto Jira so instead why don't you just use the to-do app directly so that's how the to-do app gets things done so basically the to-do app solves this particular use case very easily without you having to switch context okay but the extra challenges that we faced were that with other frameworks like vanillajs backbonejs maintainability was becoming a problem in the sense that we had whenever we have suppose let's say we have 3 applications and in a day we were to fix 3 bugs in each of those applications so it required a lot of context switching at that point I mean first you have to think okay let's me let you think in terms of backbonejs then let me think in terms of vanillajs then let me think in terms of another framework so that was becoming a problem for us and we decided that we want to like you know standardize so maintainability and extensibility was a problem the fact that we had a small team at that time and we were definitely growing at that point in time and we needed speed and because of these multiple different frameworks we knew that the build process was actually very like different for all of me so that is why like we tried out some existing frameworks at that point like I said like we already used backbone and backbone has been around for a long time like last I worked on backbone was in 2015 and like before last year and because I had been working on like other frameworks for that long and I had to go back to the documentation a lot like I had to read up on the documentation a lot and like in my opinion backbone required more code like if you wanted to add a plugin or a base code then extend it then fine but backbone definitely requires more code and backbone the problem with backbone was that it could easily lead to spaghetti code like if your code wasn't organized properly then you would end up with a lot of spaghetti code then there was react so we also tried out react and already worked on react a lot I mean I know it looks looked easy at that point in time like starting with react is always easy but there are always a lot of gotchas when it comes to react like you never know what what kind of gotchas you might end up with depending on your use case and like for example let's take the example of a life cycle method at that time we had the component life cycle method called component build mount so like do you make an API call in call component in mount do you set state in component in mount or not or like where do you do all of that stuff right so that was a little bit unclear and basically there was a learning curve involved with yeah and like it did like even though the documentation was good but a lot of free resources were not available at that point in time if I wanted to look up video tutorials I might get the basic ones but not like really good advanced ones so I needed to spend a lot of time on the documentation and for the same thing to be done as compared to view I felt that it required a lot of more code but react had community support and really good documentation so that's my take away from react and another another issue I faced with react was that like you have this this panda called component and pure component and the life cycle method the method called should component update so you get to decide what you want when you want to render and to me that was just a cognitive overload like why do I want to decide what needs to be rendered so what we needed was at that point in time unified framework for new apps basically if we're building new apps we wanted that it should be in this particular framework and a framework that accommodates a growing team when I say a growing team I mean that like this framework should be such that you could learn it in very in the least possible time and it has less gotchas so basically you'd want to do more with less code and we also wanted that it should have good community support it should have a good number of stack overflow and GitHub issues a good number of a really good documentation as well and a framework basically with growing support and we also wanted support for like project generators a CLI kind of a thing to bootstrap any kind of project if I wanted service worker to be included into my project I shouldn't have to hard code it it should just be there out of the box if I wanted state management I wouldn't have to go read the documentation and then add it via code similarly for ESLint and Babel integrations I wanted to have from the get go so all of these things could come in with a good CLI bootstrap project and that was the requirement of a free work that was a requirement from us to that free work so that is when we tried out ViewJS there were just three of us and all of us we tried out ViewJS which was like I know like you had been around for a long time but it was the time when View was gaining really like a good community support so as with all new things there was some resistance to adoption and trials as well so there were some concerns like was there enough community support or were there enough people doing View were there enough questions on Stack Overflow that were like answered the right way and what about the performance optimizations like is it does it have a good bundle size does it have a lesser bundle size and does it do DOM dipping and so on but again ViewCLI 2 which was there at the time it was a game changer for us we realized its power and how it made starting up of new projects because we were building multiple apps it was important that we build those apps and we have a good configuration from the get go so ViewCLI we realized that it made bootstrapping and deploying up brings so some comparison that we made with View and React because those were the two finalists that we had for example if you wanted something reactive in View it was as simple as assigning it inside an object in data and then doing not change that values so that is how you achieve the reactivity in View and you could see that on the UI directly but with React you have to do something like this so basically a lot of code was like being written to achieve the same thing similarly like one thing that really blew my mind about View was the computed properties already I'm sure most of you must have used it already and computed properties like it makes things so much easy and what it does is it listens it subscribes to the value of let's say like greeting and name so it subscribes to the value of both these both these changes and if anything changes the whole component will re-render and the same thing emulated with View sorry with React you need to basically create a helper method inside your render and then like do the same thing so what we found was that like View really fit the bill for us like some features we loved about View were that it had inbuilt DOM performance optimizations like the View DOM and also performance optimizations like we didn't have to worry about component or pure component so I'm sure like you must have already heard that in the second talk third talk here and there were computed properties like which completely sold us the reactivity syntax it makes things so much easy you get to do more with less code you're more productive so these are the some of the apps that we built using View and the video confidence app, the Google calendar integration read by is when you want to see who read your messages files app, search app the polls app mailing list and reminders so in conclusion Flock loves View and we'd love to build more apps with View if there are any more apps for us why didn't you choose something really crazy like Svelte or maybe to be honest in 2017 I'm not sure Svelte was even a thing since 2017 it's been View for apps for like I mean people have come and go to Flock but like I've been there so so yeah View is all the way awesome thank you guys, thank you thank you Vivium for taking two talks in a single day so a couple of quick announcements this is the last announcement thingy so reminders on 7th September RootConf is organizing a workshop on Lua so if you're a game developer or a programming language enthusiast it's for you visit hasgeek.com rootconf for more details and on 14th and 15th September View workshop is being held by View Day Curator Chirag Jain it's on how to design flexible components with View by building a PWA app and for more details you can visit hasgeek.com so yeah call back to the first talk of the day next talk winter is coming so it has arrived so View 2.x has done some amazing things to the web community but there are greater things coming in View 3 which we are all excited about so meet the improved reactivity system better tooling or a brand new composition api there are things to look forward to and Rahul who is a core team member a big round of applause to Rahul hello everyone how was the day? ok some of us are happy at least so I'm going to talk about future of View but before I start with that I've got just two things it took a lot of convincing and almost an year to get View Day this degree to make this thing happen and I want to thank Jainab, Hasgeek team who has made this thing possible round of applause for them and also for all the speakers who were there late last night preparing their slide and making it all the preparation for the event today again round of applause for the speakers yeah events are made by people but they need money and our platinum sponsor Anata has helped us to basically be here and all the facilities and everything thanks to all the sponsors let's do a quick recap of the day we got to know like it's easy to learn View we got to know you can build components and building component libraries is hard we got to know we can build our blogs with View you know like scale is also a people problem like last team can be a large scale application plugins can cure all kind of developer pain we looked under the hood and find out how the activity works and we heard the react developer show his love for View and most important lesson of the day accessibility is business so let's start from where it ended in the morning View 3.0 is coming yes it's coming a little bit about me I'm Rahul Kadhan you can find me on Twitter with this I call it junk zero whatever you want I'm a core team member and I run a meet up in Bangalore or blr.view.com that's the website and part time I'm building a conference in design look for that let's get back to the future yes 3.0 is coming so why now 2.0 was released almost 3 years ago and it has been almost good for us like there are no problems which cannot be done with 2.0 why now, why 3.0 is coming so the main reason behind this thing is this particular chart it was red 3 years ago now it's green so it's kind of a go you can use proxies and improve to 3.0 so I mean kind of give us a gist like how objects are defined reactivity works you define a ghetto there you just track all the dependencies when something is accessed you define a set where you can notify all the dependence like something has changed, update it but there's an inherent problem with this thing so all the caveats and the complexity like it has linear complexity if you have 10 properties we have to iterate across all the 10 properties and make them reactive so it incurs an upfront runtime cost then removal of properties and additional properties is not possible because all the wiring is done upfront when your component is initiated also array index and length assignments are not possible because there are no traps which can actually intercept those goals and proxy does all so proxy is kind of an interceptor which sits between your object and the accessor so whenever let's say you want to access a key on object it will ask the proxy object give me the key then the proxy will go and actually find the key and return it so proxy can intercept all the calls like assignment on index adding new properties removing properties even your custom classes objects any kind of object you can think can be handled this thing so no more caveats and I absolutely love proxies so as Praveen told us today like dollar set is kind of a workaround which object would define the activity cannot work with so all those things array assignment are gone now with the proxy base the activity implementation and it works with maps set, week map, week set or any other class would go on this small change has made view a lot faster much much faster than the object to define properties and I have some numbers for you so this is not a real world application it is like 3000 stateful components with lots of properties on it and we are voting the same application with 2.6 is the current stable build and 3.0 prototype so if you see something the time spent in JavaScript is almost half so we are getting double the speed of initialization of a new component and you see on memory it is almost half the memory so we are creating we are using less memory so double the speed half the memory 3.0 is coming so plus there are a lot of more low level stuff is coming in view 3.0 which are going to increase speed even much further and so for that I want to take you to a small crash course if you already know this so it is a small crash course how virtual DOM in view works so we write a component something like this we write templates in a steamer like language and this template is past converted and run time is represented as an object so that object is representational like what is the tag what are the attributes what are the child elements it's a representation it's kind of blueprint of your component of your tree what is actually being rendered in browser so this thing we call virtual node and how we get there is view compiler compiles that HTML into a function which uses like create element or the function to create those objects whenever a component is rendered it returns a bunch of objects and this particular element create element takes three arguments are tag attribute and a list of children and basically returns out an object out of it this particular object is called virtual DOM node or also called vnode and we get this thing out of the template so template is converted to a render function a render function returns a virtual DOM virtual DOM node and all the virtual DOM node combined to create a virtual DOM tree so that's all let's get what how we are using all these things in 3.0 so we are trying to build a smarter compiler that understands your code and tries to generate a more optimizer better code let's see this example uh it's a simple template it has two elements one is component other is normal div what compiler knows is like all HTML tags are lowercase single word and single word and all components start with a capital letter compiler can use those information so instead of using a generic create element it can find like create a virtual element or create a virtual node for component and this small change actually helps if we were doing this our create element something looks like this if it's a component run this component create component vnode if it's an element run create element vnode so we are moving this condition from run time to compile time so every create element is slightly faster and those slight improvements add up across your application to make your application a little bit faster so we call this thing element type detection and we detect from the understanding like tag starting with capital letter is a component and a single word lowercase tags are elements and cross only generate create node elements for that another small improvement but more effective it comes from concept called monomorphic calls so what is monomorphic call if you see this function call it is taking four arguments versus tag so it's taking four argument but same thing can be done if it was taking the first argument the span element the tag so there are no attribute there are no children but still we are calling it four arguments so what happens with monomorphic calls is like if function is getting same kind of and same number of arguments again and again JavaScript virtual machine optimize this function and reuse it so monomorphic functions monomorphic functions are little bit faster because JavaScript run time won't have to work on optimizing again and again so that small improvement will affect every call like create element is being called for every tag you write in your project so that small improvement will add up and will appear in the performance most we get in 3.0 so call remains same whether you get arguments or not so this is monomorphic call it's a very interesting topic can use in any of your applications another thing are component fast path at compile time we detect what kind of component you are writing so if this element has zero items zero children then we know like you don't have to run the logic to define the children and all we can skip all this part so we sort of have some flags these flags are tell the flags detect some information about your template at compile time and tell run time that you can skip on these things you don't have to perform this so all unnecessary work can be skipped over resulting into a little faster a little bit faster component run time another thing is optimized slot generation so if you have seen how a compiler compiles a slot element is something like this it creates an object and basically creates an array of all the elements in that slot problem with this thing is there is a logic collection and everything happens where it's rendered that is the parent component but parent component doesn't need to depend on those things there is unnecessary render of parent component a small improvement like converting this object to a function so starting from 3.0 every slot is compiled to a function and this small improvement helps better track the dependency like now dependencies would be like inside the child and if something change in slot parent won't re-render child would re-render another improvement comes from understanding your code like if you see this this component there is some reactive part corresponding to that we are generating some nodes but there is other part which is static it's never changing so if your dynamic property changing your static part is re-rendered which is not required so what we can do is we can extract that V node and store it as a static variable and use it every time now when the dipping algorithm would work on this component it will see a reference to same object again and again and it won't have to perform any kind of difference for that static part so all the static chunks from your template are little bit faster so we applied same thing on props if you see you have some attributes so those attributes are static there is no reactivity involving them so we can do same thing we can extract them out to a static object and dipping algorithm will be improved with this another thing we see is like we use lots of inline handlers something like this on event you are increasing incrementing a variable so this thing is converted to an inline function so how the ask it works is like every time you put an inline function it's a new instance of function so view has to unbind the already existing event handler and bind a new one every render however we know that this is not what we want here we want one event handler that stays across so what we are doing we are extracting that handler into us out of the scope and using same instance again and again so all the binding and binding of event is not required so that those are the these are the influence you are doing on compiler side now all those improvements in compiler side are complementing the runtime so we are getting a faster virtual DOM and we have a new dipping algorithm that utilizes all the information we have collected at the compile time let's see this example if you want to if you want to if you are let's say if you are the dipping algorithm you want to dip it how will you do it dip the div, dip the attributes on div now go to child find first child, dip it again so you will go to every element every prop one by one and dip everything so you will find the differences and if it doesn't match the previous DOM you will re-render it however if you see this algorithm most of the part is not changing the part which is changing is this particular part where we are using some reactive state so in 3.0 what we are trying to do is detect the part which are using reactivity or using some programming capabilities and extract them out so how we are doing this thing is we are dividing a component into blocks so component is a root block and every reactive content can be a block and now collecting all the blocks inside a component and now dipping algorithm would only look at the blocks so let's say you have an if state container component and now we will divide blocks like this you have a root block you have a conditional block and a reactive block all you need to dip in this particular case is those 3 blocks if there is no change in those 3 blocks rest of the content is already studied so you don't have to dip that same applies for 4 so in this case you have a 4 loop which will return multiple nodes so every node out of the 4 loop and we will basically divide this into a root block multiple iterative blocks and a reactive block and dip only those part where something can change a good way to see this thing is I like this diagram every box is an element which is using some reactivity and every circle is a static element so if you want to dip this 3 in conventional way how view 2.x is doing right now you have to dip 23 nodes all those items you have to dip but if you get rid of static items and thus collect the blocks you get down from 23 to 7 nodes this is like a huge improvement on the dipping algorithm the core of change reduction is the dipping algorithm which would make view significantly faster another thing is smaller bundle size so right now what we have on prototype view 3.0 is 10 kW gzip and you can make it even smaller currently how we do all the things like we have some global apis view.next or view.use in bundle in esm build we are removing all those surface apis from there and making them as named export so you can import the parts what you need and not just for those global apis we are making all the features like transitions transition group all those functionality that come out of the works view so everything you are using will be in your project and something you are not using let's say you are not using transitions in your application they would be stripped out of the view build and you will get a smaller size less than 10 kW so that's there next few improvements we are doing on dx side so new apis being added render causation component re-renders but you don't know why does this component re-render and new hook is coming called render triggered so this wouldn't fired change is detected and re-render has been triggered so you can put a debugger there and look at what is the property that triggered this particular thing and debug your component with more information additionally we are improving warning traces right now you get some warning but you don't know where this warning is coming from so we would create a trace on component tree how this warning is being propagated and how it is presented to you you can go to that particular component and debug how this warning was created which component emitted that warning one more improvement on template side is you would be providing template source maps so you can now put breakpoints at your template strings as well let's say you have a view in your template and you want to pause at that view you can put a breakpoint there and look like check what is happening there there is a huge improvement coming from native we are making it easier to target for multiple platforms you would come with an api to create your own renders let's say you want to target native ios or android let's say you want to target a pdf you want to generate a pdf using views so you can create your own render api is pretty simple you call create render and you provide some method to insert an element remove an element create new elements then query selector render out of it render to any target next is we are making it simpler to contribute a lot of people ask me how they can contribute it was always difficult for me to tell how they can contribute is a monodiff you have to basically spend a lot of time to understand all the concern going in there going forward we are adopting few things we are dividing our project into smaller independent chunks so let's say pro-ean wants to contribute to reactivity he can go to that model and contribute to that part somebody wants to contribute to compiler they can go to compiler and contribute to that part all the concerns are limited to the scope of the package and it's easier to understand a small chunk and you can understand all the chunks completely it would be a great opportunity for all those people who are waiting to contribute to views whenever it is open so go ahead and start contributing another big thing would be new 3.0 source code is written in typescript and you don't have to look through all the packages to understand you can just look at the type inferences all the apis and this work in particular functions but view is written in typescript you don't have to use typescript currently view is written in flow and you don't have to use flow in your application you can use the house script similarly with 3.0 we are writing in typescript because it makes the job of maintaining the framework easy but you don't have to use typescript if you don't want to another way to contribute today is you can be part of RFCs RFCs are kind of making all the decisions what goes into view and what doesn't so if you have some concern go voice your concern on this repository if something is breaking your application a new feature that might break your application voice your concern like this doesn't work for me or if a lot of people have similar kind of concern you would re-design the apis okay finally let's go to something which broke the internet recently a composition api and yes so why we are introducing a new api mainly if you have been using mixins the problem with mixins is let's say you are using two mixins in one component and you got some issue you look at like this state is coming from somewhere which mixins you don't know you have to jump to the source code of both the mixins to find out which mixin is actually exporting that property another thing is let's say both the mixins are exporting a prop or a state variable with same name both have counters and now you are using both the mixins you cannot use both the mixins depending on same variable they might change that variable differently that could break the behavior of mixin as well as the component there are couple of downsides to mixing though mixin help a lot in some mission areas but eventually you can get to a rabbit hole where you don't know where changes are coming from to mitigate all the issue we came with a composition api and in community react hooks have been working really well for react people so we are trying to create similar functional api which you can compose and reason about where state is coming from let's take an example so this is how a component would look like a new method is added there set a method this is if you can set up initial state for your component and here will go all the components in api related stuff a new api is exported reactive which is same as what we have right now api is called observable so you can define some reactive state and in that state you can use computed properties as well so here we are using a computed property function that returns double of the count variable we can define some functions in line here and finally we can export whatever the state we have created here this the object return here is available so what we can do is state.count, state.double we can access that increment method with return pretty much how we already do with data and computed properties and methods to consume something is changing does this set a method is something new and what we can do with this method gives you flexibility let's say this component is growing in size you want to reduce the size of this component you can extract the function out of it like this a use counter and all the logic from the set a method is now in this function and we are simply calling this function in our set a method and returning the state nothing need to be changed in the template template remains same what you can do additionally is let's move this counter method to a separate file now this use counter is in a counter.js file in our component we are importing it using in same way so this allows us to infect a code into smaller chunks and reuse it as well there is no concern about like there is no information about component in this particular use counter function it is creating some state and returning some api to access that state so that's there okay so nothing need to change and let's go to the case like when you are using two mixing both of same properties same thing can happen here but JavaScript comes to the rescue when you are destructing this object you can rename it to something else let's say you rename state to counter and now you can return counter increment and you will use it accordingly in your template the state becomes counter.counter double so all those namespace callings things are going away if you are interested to know more about it go to this URL click a photograph of this view composition api rfc.netlify.com and we have created an extensive documentation on what is coming to the composition api and what you can do there are plenty of examples there and plus there is a plugin that works for view 2.x so you can try the composition api today itself we are on questions but I guess I came with my own questions let's go with them first so 3.0 is coming in typescript so do we need to learn typescript now no if you are using view 3.0 you don't need to learn typescript if you want to contribute to typescript you have to learn typescript and it's a good skill to learn does 3.0 break my applications 3.0 is not duplicating or dropping anything all the public api in 2.x and 3 is almost same one more api is coming that's the composition api that adds upon the existing api you don't have to worry about anything breaking let's say you don't use composition api your component works as it is why it's 3.0 is because we are dropping object.property define property syntax and using proxies so that breaks something internet explorer does not have support for proxies and internet explorer is obviously dead now so it won't ever get support for proxies so if you want to support internet explorer you have to use a build that would have all the constant all the kvarts of 2.x but you can use 3.0 you can create 2 builds with view cli for modern browser it will use all the latest proxies thing for older browsers it will use different implementation of the activity system using object defined properties but you will be restricted to all the kvarts we have in 2.x if you want to support internet explorer and in the we will provide ample warnings if you are building your component with modern mode and you are using array index assignment this kind of syntax won't be this kind of feature won't work in internet explorer build so use an alternate way or remove stop supporting internet explorer and feeding microsoft okay another concern i have now we have 2 ways of writing component so we always had 2 ways of writing component you can use template or render function but i haven't seen any person who is writing all render functions or all templates most of the work can be done by template 99% of my components are template with templates but once in a while i will learn into some situations where i want to do something and those kind of things are not possible in template template is a restrictive language so you have to jump into render function and create your component analogous to this we have object based api where we use data and computed method to build our components that works really well once in a while we want to build a feature we want to use mixins and we want to share that feature across multiple components there we can jump and use composition api we have 2 ways of writing components but we have to choose like on a case basis if it makes sense to use templates we will use template if it makes sense to use object based api we will use that if it makes sense to use render function we will use render function same with composition api that's all from me today i am Rahul you can find your twitter by this i want to introduce Ustho please come on the stage he is also a core team member and he is involved in community a lot so come to you i originally wasn't meant to give a talk today but we still have a few minutes so let me share what i didn't prepare for today can we have a browser because i would like to show you a few of my favorite websites which may have or may not be created with UJS just a browser because i will be switching from one to one my real name is Dariusz Weondrehovski it is quite difficult to pronounce so my friends call me Ustho and i consider all of you my friends already so be happy if you call me this way when i came here to India also started having big problems with learning and remembering all the Indian names because we are so different from what i knew from Europe but what is not different is the passion that people here have for the technology and also for UJS that's what i will be talking today and i came a few days ago to Delhi because that was the cheapest way to come to India and i am a cheapskate i try to go to as many local meetups as many conferences as i can just to meet view developers to ask what to struggle with so i can pass people like Rahul who are better with coding than me and in Delhi my friend who actually he doesn't use VJS he uses React but he was sick and Amanda that's also your friend and he took me to a sick temple and we attended community dinner together and what i noticed there were people and getting helped with food and service by other people who are voluntarily helping them and community of developers doesn't really work differently it works pretty much the same way some of us like library authors like event organizers like workshop creators authors of tutorials authors of courses or people who just ask questions or stack over the floor chats or forums provide help for others and later when they need help from other developers those that previously were helped by them got help from them now they are knowledgeable enough because they received this help before so now they can help push this help further to new generations of developers and in the developers world new generation is practically year after year because we get new people interested in development very fast so when I was coming to India what I started becoming interested in was the place of India on the map of VJS world so let's start with the first website which is called viewpeople viewpeople.org hi Niko Niko is the author of the website it may be a little slow on this wi-fi okay so let's make it bigger can we make India a little okay nice let's see where we have some developers I see some in Bangalore some in maybe it's Mumbai maybe it's Pune I don't think I see anything in Delhi oh that's Delhi okay yeah I was in Delhi and I didn't recognize it on the map it's my fault I thought it's slightly more to the self so let me ask how many of you are represented here great what about the rest and if we see map of the whole world in India there are so many people and there are so many developers so why on the map there are not as many are VJS developers and that's nobody's fault but it's community that currently uses VJS or is just learning VJS it's we who can change it because together we can make the community bigger and better not only in India but also around all the world how I like to say it view united we stand let's go to the next website okay before there are multiple ways in which we can help each other and one of those ways is the way of Rahul I call it this way my friend Amanda helped me realize that on my trip around India I'm actually following the path of Rahul because I ended up on the exact seat in Amanda's car on which Rahul on previous conference was sitting before me let's try to follow the path of Rahul and I will ask you about libraries how do you think how many VJS libraries were created by Indian developers and we're not talking about libraries of Rahul which were a few I didn't know even one before today now I know because I heard about it here on the corridor view experts is the outer here with us yeah why we are opening it is because I want it to be inspiration for you that even if the community in VJS isn't what I would call the mainstream of the biggest biggest libraries and biggest communities around the world libraries like Naxt or Vutify or Element UI each of us can still add a small piece of it each of us can still create a library that will be used by other people we can see 700 stars that's a lot of people that found this project interesting a lot of them use it in their projects we can see that they are opening issues and that's the easiest way to okay but other than other than writing a library you don't have to just create a new library if you don't have an idea or you feel that you won't be able to focus on it too much what you can do instead you can join an existing team luckily during the last year a lot of change in the community previously libraries were mainly created by one person or maybe two people collaborating with each other now those teams grow good examples are Naxt team which currently has seven people I think Vutify team which is growing very nicely Quasar framework also has a big team right now and also in VJS core team we now get specialized teams for example the team working on documentation there are a few people and recently created a new team that it will be developing new versions of ViewPress and providing support for it so this is another way how you can join the ranks of contributors to VJS ecosystem the next website can I ask events VJS org okay find meetups okay and India we have Bangalore we have Hyderabad we have how many of you are from Pune I am not okay from Hyderabad I wonder what about other towns like Delhi like Mumbai there are so many times that are very big and there are so many developers of course there are other developer meetups like JS lovers which are popular but we all can take inspiration from the organizers and from speakers who share their knowledge on those existing meetups India is such a big country that there is always space for additional stages on which we can we can allow some of us to grow as promising speakers who next year may be stand with us or on other stages around the world like on View Toronto, View London View Amsterdam next website let's go to View Vixen this is a website that is very important for me because I notice among you there are a lot of guys but there are also women and next year hopefully come here for the next edition of View Day because I hope it will be a thing let's cross fingers for that I hope that there will be more women among us and that on this stage sharing their knowledge with us there will be also more of them so View Vixen is an organization that organizes free workshops around the world for women developers providing safe environment for them in which they can learn ViewJS at their own pace and the way they prefer and why I am showing this is because so far there were no workshops like that in India my friend here from Bangalore was invited at least my friend here from India there is a possibility that she will help with organizing such workshops around India so let's cross fingers for her too and finally the last website was not prepared before I learned that I will be talking an hour ago so this is just one last topic I was supposed to talk can we view land two more two more projects I am showing and we end can I look online to my website to my account to the web client to the web client I just put my password no no no so next way you can next way you can collaborate with view developers from around the world is our official ViewJS chat where I am administrator and you can also meet Rahul there and what's good about the chat if over 60,000 users a lot of core team members over 50 library authors from around the world authors of tutorials event organizers where we all share our experience exchange knowledge help each other to either create new applications with view or organize something for the community if that's here that was the secret one so you can see we have some rooms for event organizers for library maintainers and a lot of rooms on which we exchange knowledge most of it is in English but very low at the least we also have Hindi channel which is also in English so I would be very happy if you join our ranks and we have a very fancy logo which you don't see here but I have a lot of stickers left so if you want I will give them to you later and what do we want because it's not my account other than official chat of ViewJS there are also servers on discord for many more supported libraries for separate server for next for viewpress for beautify viewmaterial all kinds of other libraries together it's a can we open a view family view family channel at the very top yeah here's a list of all okay so viewfront view storefront saber which is also it's interaction in view community all kinds of other chats related to viewJS where you can discuss with authors of the libraries in the more okay we'll finish so let's go to our last project can we open view community view community org this is the last project which got published a few days ago it was started a year ago and practically it was we started working on it a year ago but you can see that when you work on something together it's going much faster when we try to work on it just as one person or two people it's not going as good so view community guide is that is that is meant to provide information written by the community and specifically for the community and about the community and the ecosystem so all kinds of information and questions that you wouldn't find the answers in official documentation you will hopefully be able to find here for example how to tell my boss that I don't really like react now like to work with viewJS official documentation won't help you with but we on official VGS chat heard such questions all the time so we're trying to prepare a resource the strongest point of view is still a step so we need to make it longer we're trying to provide all answers to such questions that are most commonly asked by the community and why I'm showing you this is because if you want to take your first step to contribute to viewJS community this is the easiest way because creating a PR and adding something from your knowledge and we have so many experienced developers here who have different points of view on how to create applications what libraries to use how to best provide a particular feature you can share this knowledge on this guide which is meant to be managed, maintained by the community and by community I mean us here and you on the stage that's all from me I'm thank you for listening to me give it back can we have a picture of him for Vesto and Rahul I'm going to have to be here and take us through the core things that are happening in the view community so thank you so much now I would like to call Xenob on stage okay so now I would like to call Xenob on stage who is going to take us through the end nodes please welcome Xenob sorry Rahul don't you want to take some questions after your talk okay so maybe we should have some questions for Rahul do you want to moderate the Q&A yeah sure he's here, utilize him you can ask from anything about the new composition api or all the masala that happens around that Rahul when is view 3 coming all good things when it's done seriously we don't have a date now we want to do it right there are no pain points at 2.x so we are not hurrying it up we want to ship it when it's ready and it's really good I think you mentioned that view 3 is probably not open sourced yet so when is that going to happen and any idea around that I don't have answer for that I asked Evan and there was a notification on this called I guess he answered to me but I have to check it I have to check it up yeah you can go to next question any next question probably so we can take one more question and then we can let Rahul go and sit on his seat anyone alright so thanks Rahul thanks for being here again and handing over to Zainab now I think Rahul you should stay on stage because we should be asking a few questions to people in terms of the conference itself okay before I wrap up one of the things that I missed mentioning this morning and I think this might be a good time is this year at view day there were 13 diversity candidates who were given tickets to the conference I'd really like to thank everybody who sponsored those tickets Nectify, Pushaul, Rahul Kadyan Gastu Neha and I think there's one more gentleman whose name I'm missing but you probably know him yeah okay so thank you very much this has really allowed us to bring in more women developers Satish's ticket was also supported and I think it's a great initiative considering that we were a fairly small conference by our standards like we were 130 people today and 13 meaning 10% were given to diversity candidates in addition to other women attending I think this is a very good thing for this conference itself so I think we should give a huge round of applause to ourselves and I hope that this can be continued going forward because I think it really matters to have more women in the community more people of different genders in the community more people who are differently able because it gives us different points of view and to think about what we're doing from many different vantage points so on that note I think I'm not going to take too much of your time because it must be really exhausting day but maybe we could have a few questions and you know folks can respond how many of you was this your first conference first tech conference that you're attending okay okay so can we have you know some of the first time was telling us what your experience was both good and bad and what we could do better so that you don't go off the radar of attending tech conferences so can some of the first time was tell me tell us rather like Rahul is here I'm here so you want to come on stage come on stage tell us how was your experience what was good what was bad did you face hesitation and like talking to people was the food very bad I have something to say conference was really amazing the organizers were really co-operators they were flipping out at each set and also the other the networking everything went well everything was easy doesn't seem to be like my first conference ever okay nice to hear that anybody with a contrary point of view because contrary point of view are very important the food was expensive the food was expensive okay alright that's good that's feedback for us to take anybody else so shall I say that Rupa is representing everybody maybe you can SSB or tell me if you are not comfortable telling it here yeah and then you pass them on to me yeah okay next question generally feedback on the talks and on the sessions would any of you like to tell us what worked for you what didn't work for you what we can do better next time around and that will be feedback for all of us including Swapnil and Rahul and Vidya and all of us who did reviews please tell us should I assume it's the fag end of the day maybe I should just let you go come on everything can't be so good stickers are on me I didn't get stickers so next time very bad first time was won't like it okay so maybe I should let you all go but we will be sending you the feedback form tomorrow and you can fill out the feedback form it will be about one weeks time that we will keep the feedback forms open and we really appreciate your frank feedback what else you have already heard from Rahul and that in terms of how you can contribute to the Vue.js community and tell us what more we can do to kind of help build the community we would really like to do what will help and serve your needs and last but not the least there are a bunch of events coming up there is a workshop with Chirag Jain is conducting on designing flexible components using Vue by creating a PWA that's listed on hasgeek.com and if you want more details Chirag himself is here you can catch him up and open to talking and then there is a bunch of and then there is JSFU that's on 27 and 28th of September in Bangalore itself we have been announcing a whole bunch of meetups and workshops in the next few days leading up to the conference so feel free to participate and if you would like to talk at the conference if you would like to teach a workshop please write to us on info at hasgeek.com we would really like to help you to speak and present your work so please feel free to do so we generally do a very nice job and push people a lot in terms of building the ideas and talking and we can be quite meticulous but then at the end of the day the output is for all of you to see so thank you very much for spending your Friday and coming here I hope you have a good weekend and we will meet very soon okay bye oh yes can we all gather outside the auditorium for a group photograph and I think one last round of applause to all the crew and volunteers who really slob since yesterday and today all of us wearing yellow lanyas and me of course bossing over all of them thank you very much for your efforts and for travelling all the way to do this for those of you who don't know there are volunteers like Yadav and Shilajmi who have travelled all the way from Kerala to come to this event entirely on their own there are a whole bunch of volunteers from SJCIT who have come from beyond the airport to Bangalore bracing the traffic so really all of them have come on their own and we are here for the community so thank you very much for your effort so outside the auditorium for a quick photograph