 Hi folks. I'm very excited to be here. I'm from Chennai. Who are from Chennai? Yeah. Is your hands? Hey. Okay. Not many. Okay. So this is my first view conference. Like I'm going to talk about view conference. So today we are going to see a board like using building form components, using UJS in a large scale application. So I am Bharat Vaj. I'm from I'm a friend and engineer at charge B. So a little bit about charge B. Charge B is a subscription management platform that helps you untangle recurring revenue business from negative 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 have a support more than 20 payment gets. So today's topic like we've been speaking about two things. Why a company like charge B charge B chose view as its view layer and we'll 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 considered being like two years back we had option whether to choose react or angle or view. So those are the 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 that extra was like Java Enterprise Edition with JSP for the front end. So we don't have any like expert in JavaScript expert in HTML CSS. So we are like traditional HTML developers and CSS developers. So we chose view because of that it's since it's easily approachable and it was easy to on board a new hire. So let's say a pressure 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 with angular or react so I would suggest like viewJS documentation is pretty clear and simple. So you can easily understand. So words new to the single page application can easily understand. So starting point to learn a single page application or just works versatile. Since I said our app is like a monolithic sound year old legacy application with a 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 or library that integrates the existing app and you're able to deliver within a month. So previously you're right. We are developing a complex you will animation with jquery or javascript or anything. It will take time. So charge is like a user experience focus company and we are like comp like user experience. We focus on user experience and we are like complex animation logic. So with viewJS we were able to deliver we were able to develop within a single day. Previously we were taking about three to four 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 it. These are the 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 add HTML and CSS developer who doesn't want to write CSS in JS so that's why we choose view. This was a major selling point to our investors and CTO. Single file components are the template part. It was very easy to debug and manage and maintain the application. And the final part was the dependency tracking system, the reactivity. So at the time since like view is not backed by any big product companies and there was many patterns at the time and it was just bubbling up. So charge bill allows philosophy. So what happens after two years even view 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 RFCs. So when compared to other frameworks, view is something like that is community driven. There is RFC once RFCs are approved by every most of developers once it gets upward and only then it will be moved to the version. We'll come into the performance. So you don't have to do anything like people the performance of the view. It comes after the box. When compared to React, we have to write in a such a way code like you optimize the code. So React doesn't do for it for you. So view does up to the box doesn't do it. So lesson says when compared to other frameworks. So in charge we have two applications. One is the web console as well as the checkout pages. So that the checkout page runs on third part of our customers end. So we want something that is lightweight. So we chose view. Finally it suits our need like we are using view for last two 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. So coming to today's topic, forms. Well, building forms that has more than 10 form fields and each form field has a relationship between other form fields and it's not just a form of text. Let's assume like we have currency input, time zone support. It's pretty hard to manage and maintain it and even write unique cases. Many of you know what we have. We have view just developer. He's the CEO of view just developer.com website and he's writing a book on and building enterprise application using view.js. So this is his read from him. So he says like building a very big forms using component based application 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 some normal form, average form in charge B. So this is not a norm generic form where you have a form builder and then not normal templates. We have like animations as a relationship and there's a 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 forms views in a different way. It's pleasing to the user experience. So let's dive into building form. So this is from a documentation website. If you're building a form select as a input field, the user name and we have the options for that as a binding to the user name. So the template field has user name field and the submit button and the form as the callback submit, submit form and you're making some, this is our normal basic in form in a visual application. So let's assume you're building a form with client set 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 options like 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 function checks whether name is required, name is there, email is there and check the email and for valid email, we have a regex. So this is how it looks like. So when I enter submit, I'm selecting anything. So this is like building a basic new approach of having a form with basic validation without using any library or any modeling. So let's build let's look at client associate validation. So this form basically we are the same as before. The only thing new is we are making a pay call on the response of the call. We are pushing the errors to this to enter it in the error. So let's look at the community plugins available. So view form it's a form validation library. So this is a popular library so you can find on 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 the components for using a JSON. 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 confirm 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 valid it that covers the in that wraps the input field and we have field messages that renders the if there's any messages for the particular field and normal form input input that's it. So the response will contain something like this for each field we'll have a name. What's that? So the render part is something it's very simple. We have this three fields name, password and confirm password. So if you submit it without it so each errors will be mapped to the particular field. So you guys went through like all the examples so what we found so validations are duplicated in client side and backend side. So basically any form any post action will have a validation server side. So best practice to do a validation of both client and server side. So here the validation part is duplicated in the source client 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 the way it displays the error messages. So that will be duplicated in all in all the places. Let's say each component level like slight variations of it but end of the day like you'll be have you'll be duplicating the same code everywhere, spaghetti code. Let's assume if a form contains like 12 plus form fields and that's assumed based on a 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 a chat between the parent and child. Anyway, you won't be you won't be keeping the entire form in single component. You break down into small components. So we will have some ugly riffs and then we will be calling the child and 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 it? Basically like the business logic of the form field. So it's quite difficult. And it's not scalable. So any product will have new features. So the number of form fields and the components keeps on growing it never stops. So let's team 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 any kind of form fields in the requirement of the future. demo. So we are going to be building a simple form field, a form like having a phone number that has a master input and a password. It's on our simple example of 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 different business logic. It has the different roles. Let me work through each one of them. It takes care of the rendering point. And so it's a source of growth, right? It interacts with the form. So it will limit the events all this to the parent. It can work independently with the form. It doesn't want to have a form wrapper for each and everything. You just want a search field or a normal unit input field. You can have it. And it can have a custom masking logic to fill from here. It's a wrapper container component. I think fancy. So on creation, it registers the form. So basically we will be moving the entire form state to the store will be maintaining this form to the 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 life cycle hook of the form for field from component. So it register the particular field to the store and it will attach a listeners to the field and it on validates the valid it takes care of the validation and updates a lot 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 is what it interacts with the basic the role of the field from component is to interact the store and update nothing doesn't do any doesn't transform the log value or nothing sort of actual form component. So basically on creation it register the itself to the store and it takes care of loading the validation part from the client side of the from the back end. So basically in charge we will load validation either from open IP spec. So we are a first company. We will be loading the we'll be adding specs. So we'll be generating validation from this open IP spec. So we use it for it and since it's a legacy app, so basically we will dynamically generate form field validations from the back end app itself. So we have a framework that supports it that gives the form, it's a form fields and the validation let it do it. So either way we can load it it takes care of the form submission part. So on destroy it removes the 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 we see. So basically it cannot be blank. So this how it works. Okay. So let me walk through the working logic. So on what's happening is we have a form store and we have a form. So form creates the sign up form. Let's assume that's a sign up form that sign up 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 text field with the custom type. So your phone number gets filled, it gets registered into the sign up 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 scenarios we'll be loading the form values to the form itself. 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 you have like error state right? So this takes care of the validation part. So on destroy text field form, phone number text field from the sign up form. So basically I showed a demo previously, right? So where we have a sample form in charge, 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 the component that contains the form state. It works automatically. On destroy form delet the form store. That's it. The reason why we chose this approach is as I said in checkout where again developers like the worst integrating checkout through the site can modify the styles of the form, the 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 not generic traditional form. But if you look at our app, we have a custom template. We can't like 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 then would win. So it's it was very difficult to dynamically render the HTML template part. So what we did we hard quarter the template in the HTML and whether to show the field or not comes dynamically from the business logic. So that's the basic in a nutshell we had done it. So this is like as I said in validation. So right left hand side you can find the open aspect. This is a one of a form field that handles currencies. So here we have refund amount as an indigent money format is money value. So we can easily for validate whether it's a valid money format or what kind of can be anything. So basically we use open aspect for this kind of things standard pattern. On the right side is the way we load the form validators 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 a this component does this one. Even for a fresher let's assume we have like hundred plus form components and each and every in every page it works differently. It is very difficult for a fresher to go and modify it with this approach like you're able to easily say this component does this one. Nothing fancy or nothing other than that. So basically we use the we didn't go for the custom logic or something from the outside like patterns or libraries. We use whatever available in the view. So any problem arises so we have a solution for it. It is very flexible. It has a solution inside it. You have just to find out follow it like APFS development for any form fields. Otherwise it's kind of messy like will be like a spaghetti code in the end and make it developer friendly. Even for a fresher to 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 you have like regarding charge be or view or forms. We can take about five questions. So I had one confusion. So the first one 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? So each form field will have a separate object. It has a separate object. It's a state object and sign form is a child of that object. See in an actual like just an object. We will dynamically register it and re-register it. So any page can interact with it. Let's assume like any component somewhere in the page can interact with it and let's assume like what value does store that has separate state getters 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 Vuex store. Basically can use Vuex store 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 on a GitHub or something and at this point the library or the architecture would have a hard dependency on the store object. Store being the Vuex store. So how would you try to make it generic because the store could be at 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 the just root level module space. So how would you try to identify and register or try to solve that problem? So Vuex is also like a normal view component that has a reactivity and we have some flux pattern. So you can use Vuex. Let the macro version of Vuex 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 your approach will still have a third party dependency view observable. Vuex was his own stone API. If you look at the documentation you can find it. Okay. 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 definitions was to go with a very descriptive JSON representation of the entire form including each of the elements 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 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 summarize what you said so basically you are using a JSON form like a form build. A JSON representation a 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 generation to a builder it builds a form for you and that's the validation. More or less. To a builder or script that generates towards JSON depending upon the requirement. Actually it depends upon the scenarios let's assume in your case let's take a checkbox and a text so it will be same across your app but in our use case was like our design team based upon the scenarios in the use case we are different styling and different way the HTML structure. So we can't build 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 depends upon the process. Generic and right to 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 and this is the relationship it's fixed and in that case it's correct but in our case it was pretty complex and difficult. 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 difference so basically in charge we have our own library we don't we don't use like bootstrap or any other beautiful any other payment for CSS as well so this doesn't 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 moved it make it try and then moved to store so found a generic pattern so this how it works