 So the topic that I'm going to present today is creating a usable UJS Component Library. And a quick introduction about myself. I'm Dibram Rasaghi. I'm a senior application engineer at Flock and I've got six 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 and some components that have a very distinctive look and feel. So what happens is that like you tend to have like components like these. So you've got form elements, you've got buttons and so on. So this is a very, just one page from our style guide. And the thing is that like we tend to have, like we tend to have duplicate code when it comes to like writing components across apps, across dashboards. So the problem with multiple dashboards and web applications is that they end up like looking alike for an organization. But at the same time, we tend to copy paste those components like for example some, like I used to do that too. And what we would do is we just copy some component from one repo and then paste it into another. So the problem with that is that like say you bought three repos and you copy paste it 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 on all three repositories. And then what happens is that like you're basically doing a lot more. So this is an excerpt from an article I wrote about like 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 two components to be consistent with the theme and colors of the application. Having 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 Vue.js. So what do you say to duplicate code? Every time you think that, okay, I'm 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 Vue, using Vue CLI? Well, without Vue CLI, it's actually a little bit harder meaning that you'll have to configure your build process using webpack or rollup or whatever you want to use. And then you'll have to like manage a lot of things on your own. So without the Vue CLI, it is a bit hard. But with Vue CLI, it's not as hard. So that is what I wanted to talk to you about today. So where do we start about like building? How 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? It's 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're 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, right? 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're unknowingly breaking a core feature of your component, then that unit test should tell you what you're, that you're 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's a link here. You could check that out. So this is an example of a link component. And I know I've been talking about accessibility and this component is definitely not accessible right now. And it's just a simple SFC, a simple view SFC and this is just a very basic example. So the step two 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're 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 like is visible here. And step three 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 lib. Basically this is the view CLI to build a component library in lib mode, to build it in the lib mode. And you get to give it a name as well. And ask 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're going to talk about the common JS module here and that's what I'm going to show you in an example as well. So the step four is that you have to package your stuff, right? Like you have to tell how view JS will find how when you're using your library, how the user will find that particular file. Okay. 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 add, I have to add your name to the library, like 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're going to talk about common JS here. And this is how you import your component and then you use it like a regular component in view. So how do you publish your library? Well, you have to like, you would preferably write a script to publish your library like a shell script, a simple shell script that basically does the following. You have to publish it in public mode so that like everyone you want can use the library. And this command will publish your library to NPM. But first you'll 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 on a build process like Go CD 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 normally use a view company. So, 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'll be doing basically when you use Lerna is you'll be publishing your link component as a separate library itself, as a separate component itself. And if you have a custom select as well, then you'll be publishing it as another component. And then you'll get to use it like the usual way. So semantic versioning, let's talk about semantic versioning. Basically, if you're making breaking changes, if you're making major changes, just bump up the version of your library, like the first decimal. And that's how you like end up with semantic versioning. If you're making minor changes, just bump up the second decimal or the third decimal. Another limitation is that assets like SVGs, they have to be in line with your, into your view components because like currently view CLI does not support that. Support getting images from your folders. So these are some tools, Lerna and Storybook. You can build monorepals using Lerna. And using Storybook, you can build your components independently and test them out. So any questions and answers now? All right. All right. 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're using it on the web because the view ecosystem allows that. You can have your property talking about web views as you, like when you're building a mobile app, are you talking about web views or are you talking about native web apps? Native web apps. Okay, native web apps. I'm not entirely sure about the native web apps at this point, so I don't think I'll need to answer that. Okay, no problem. Our solutions for creating libraries are difficult. 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 than Vue 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? Okay, so if you have a really small and private and well-component website that's not exceed 30K, this is it. Then I would want it to, I would directly use Vue CLI for that. But if we have a library of components that is huge in number, for example, if we're building something like my legal design component and your organization has that two states, then you could use Learner to build mono-reports. So what Learner does is it publishes all components with their own versions onto India. So that you could automate that and that would solve that use this as well. Does that answer your question? Like with Vue CLI, can we like have like single component library and use it for multiple projects? Is it like plug-in and like? Exactly, exactly. That is what a library can be used for. That is the main use. But we cannot use it on a scale or a component with 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 workload time. So ideally that is not advised if you have a lot of components. But if you have a very few number of components, like for my case, my maximum library size has been around like in GZ. So I was fine with that. Be hiding. Have you worked with nested libraries of any kind? Like you have built components in a library and then you compose them onto a upper level component and then automated the build process so that everything gets updated. That's fairly simple. Like if you have, you could even have nested components. So if you, I'll add a link to the repository that I built. We have a moral component that is using composition to from another generic moral component and using composition to make that component. And it is in the library as a component. So both of them, generic model and model, they're both components and they can be used from the library itself. So yeah, it is possible. Okay, we can take one more question. So as you said, like we can have small components and we can, 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 Barton, you said this short. If they're like bigger in size, not just small components. So usually base components are small in size in my experience. But if you have bigger components, you could like learnize for you, learn up in a lot of things. So if you check that out, learnize is a really good tool. I recently discovered it, like when we were reviewing the presentation. So like when he told me about that and that's how I came to know about it, yeah. Learnize good. So experience from, based on 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? There aren't a lot of libraries for you. For Vue.js, there have been a few libraries now in since 2019, but so I haven't actually had a look at a lot of libraries, but I've used some, like I've used material design for you. So and there is a library built by Chris Fritz. He had published it on GitHub and that was a really good starting point for me. I really learned a lot by looking at his code.