DEV Community: Kevin Cocquyt

Vue SFC’s in an ASP.NET MVC app

Kevin Cocquyt — Fri, 08 Feb 2019 13:43:40 +0000

Inspired by Cristi Jora and this article: https://medium.com/corebuild-software/vue-js-and-net-mvc-b5cede22862, I went on and tried to add the same functionalities in our boilerplate solution for future projects.

Between the time the article was posted and when I started my implementation, webpack went from v3 to v4 and Vue introduced the vue-template-compiler (additional to the vue-loader). Luckilly, most of the workings stayed the same… Writing SFC’s as well as adding them to your page with the created custom tags. The biggest challenge was moving over the webpack configuration (and doing something extra in my case) and that’s what I’m going to talk about.

When webpack went from v3 to v4, lots of the configuration settings were made easier (coming out of the box, like production mode which minifies your code), so you will see a ‘more or less’ slimmed down version of the configuration file as used in the mentioned article.

const path = require("path");
const fs = require("fs");
const VueLoaderPlugin = require("vue-loader/lib/plugin");

const appBasePath = "./js/components/";
const jsEntries = {};

fs.readdirSync(appBasePath).forEach(name =\> {
 var indexFile = `${appBasePath}${name}/index.js`;
 if (fs.existsSync(indexFile)) {
 jsEntries[name] = indexFile;
 }
});

module.exports = {
 entry: jsEntries,
 output: {
 path: path.resolve(\_\_dirname, "../dist/js/components"),
 filename: "[name].js"
 },
 resolve: {
 alias: {
 vue$: "vue/dist/vue.esm.js"
 }
 },
 module: {
 rules: [
 {
 test: /\.vue$/,
 use: {
 loader: "vue-loader",
 options: {
 js: "babel-loader"
 }
 }
 },
 {
 test: /\.js$/,
 exclude: /node\_modules/,
 use: {
 loader: "babel-loader",
 options: {
 presets: ["[@babel/preset-env](http://twitter.com/babel/preset-env)"]
 }
 }
 },
 {
 test: /\.(css|scss)$/,
 use: ["vue-style-loader", "style-loader", "css-loader", "sass-loader"]
 }
 ]
 },
 plugins: [new VueLoaderPlugin()],
 optimization: {
 splitChunks: {
 cacheGroups: {
 commons: {
 test: /[\\/]node\_modules[\\/]/,
 name: "vendors",
 chunks: "all"
 }
 }
 }
 },
 devtool: "source-map"
};

As you can see, it starts out with the same loop creating the entries (see mentioned article for the detailed information). For output, I chose a subfolder ‘components’ within my ‘dist’ folder as it’s only used for compiling Vue components. After that, do not (!) forget the ‘resolve’ setting as, because I thought it wouldn’t be, it cost me half a day to figure out why my compiled .js files were not rendering my components. The ‘module’ settings that follow are more or less the same, except for some options here and there (adding an additional package or a simplified Babel 7 setup). ‘Plugins’ is a new part and introduced since one of the latest vue-loader updates. And, maybe the part where I’m most happy about is the optimization (see separate section underneath).

Optimization

When creating a .js file, all of the included SFC’s and imported node modules are bundled and minified into one big .js file. As I don’t need every component on every page, I create a .js file per page using the jsEntries logic. The downside with that is that every .js file would be bundled up with the Vue runtime meaning an extra +/- 100 KB per file. Luckilly, you can do some optimizations by creating an extra file (‘vendors.js’ in my case), containing all the common node modules that are used in the Vue components making for only one (cachable) file. That file can then be added in your _Layout page and the other .js files can be added per page resulting in a lot less KB’s that have to be downloaded by your users and making the components load faster too.

Without decoupling the common node modules, every page file would be +104KB

Cache busting

When you add the JS files to your webpages, those will be cached by the browser and not be updated when a new version arrives (as it’s cached on the name, which did not change). As you’re not using the built-in .NET MVC bundling module, this also means the automated cache busting technique is not applied (changing/concatenating your JS files with a hash which changes when you change the JS files). For that, you will have to implement your own style of cache busting and more information can be found here: https://madskristensen.net/blog/cache-busting-in-aspnet/

I prefer the solution with the assembly version (https://madskristensen.net/blog/cache-busting-in-aspnet/#546c01e8-b3c7-4b63-a863-a47de3dc1507) even when it means a querystring is added as it’s not best practice for Google Page Speed. Standard .NET MVC bundling is doing the exact same thing after all…

And that’s about it if you want to add Vue SFC’s to your existing ASP.NET MVC projects. I had a blog post before about Vue components (non-SFC) but it bothered me that I couldn’t use the styling bit of SFC’s so I searched on and finally came up with a solution I’m happy about.

For those interested, I added the necessary files to a github repo so you can just copy-paste the stuff from there: https://github.com/KevinCocquyt39/mvc-vue-webpack4

Happy coding!

I18N in Vue Components for ASP.NET MVC apps

Kevin Cocquyt — Tue, 21 Aug 2018 21:05:39 +0000

I18N (internationalization) may not a big deal when you need to write English-only apps but in my bilingual country, leaving that aspect out is never an option. As I’m working with Vue a lot lately, I tried to create my first form with translated labels.

The technology used is ASP.NET MVC so no Webpack and no use of plug-ins and this is what I found 100% of the time when searching for ‘Vue + i18n’: the usage of a plug-in.

After reading the source code for that plug-in on GitHub, I created something I could use for my MVC projects. What came back a lot, in the different articles I found about it, was the use of a filter to show translations for a given label and that’s what I went with and will describe in the second part of this blog-post.

You may remember my first blog-post describing the creation of a Vue-component. If not, you may want to read that one first: https://medium.com/@kevin_cocquyt/vue-components-in-an-asp-net-mvc-app-e9eb0004c054

Step 1 — Creating a component

I created a component containing a title, a table element with header-elements and one row with data. As the header labels need to be translated, a default value is used followed by a filter in which the right translation for a given label is retrieved. That filter is then specified within the component itself and within that function, a list of translations is searched for the label that was passed as a parameter and, when found, the value-property for that list-item is returned, otherwise, the passed value (the value before the pipe-symbol) is returned. I need to pass the ‘ml’-list (more on that later) for each call to the filter as filters do not allow the usage of data-properties within them (meaning ‘this.ml’ only returns a null instead of the actual value, ‘ml’ stands for multilang in my case).

I could have named my component ‘vue-table-component’, which would be more appropriate but I’m too lazy to change my screenshots (and it’s 11PM already) :)

using a filter to find the right translation, defaulting to the initial value

Step 2 — Registering the component

Registering is necessary for two things: the first is making sure you can use the component in your HTML and second, you need to be able to refer to that component to be able to pass in the translations.

registration of the component

Step 3 — Passing in the translations

As the component was registered and assigned to a variable (can be let, or even const instead of var), you can now refer to the data-properties of that component.

The ‘main’ div is registered as the element in which the component will be loaded. ‘vue-form-component’ is the name of the created component. ‘title’ is a data-property and ref is the ‘reference name’ that can be used within your JavaScript or TypeScript (main.js is the file that contains the creation and registration).

At the bottom, an array of objects is assigned to the ‘ml’-property with two properties per object, each one appropriately named but you can name them in any way you like, as long as you then change the filter-function accordingly.

passing a list of translations

These look like fixed values of course but, for example, in my professional projects, I use an MVC HTML-extension like @Html.Translation(“number”) meaning the right translation will be retrieved from our database (using the set language) so one or your added objects could then look like:

{ name: “label.number”, value: “@Html.Translation(“number”)” }

Make sure the strings that come back from your database are encoded as they will be used within scripting (single/double quotes).

After passing the translations to the referenced property, the multilang-labels are known within your component and searchable via the filter-function.

Result

In the rendered HTML, only the second and third labels were translated whilst the first label, as there was no translation in the ‘ml’-list for it, only displays its default value (the string before the pipe-symbol).

HTML rendering

And that’s it.

Thanks to the writers of the plug-in and the ones of the articles I found to push me in the right direction, and thanks to myself for coming up with a passable solution, so I can sleep again at night (yes, these types of things keep me up!)

Thanks for reading!

PS: This is A solution, so I guess not THE solution, so if there are better ones for this scenario, please share yours in the comment section.

EDIT: Internet Explorer can be a real pain for web developers. It's at it again as it doesn't support the array.find() method. For that, inject the pollyfill script (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find) somewhere in your JS and you're good to go. Or use lodash (https://lodash.com).

EDIT 2: As I’m still learning the in’s & out’s of Vue, I learned about global filters and thought it was awesome. For that, I tried to implement this for my translations and it worked like a charm! What I did is creating a new file called ‘component-filters.ts’ with the following code:

/js/component-filters.ts

And add that script-file to the bundle:

bundling

Then just remove the ‘translation’ filter from the component and everything keeps on working.

Vue Components in an ASP.NET MVC app

Kevin Cocquyt — Mon, 20 Aug 2018 20:24:13 +0000

I’ve been using Vue JS (https://vuejs.org) for close to a year in a couple of my professional projects but never in the preferred way, meaning it still consisted of static HTML, Vue instances only containing the scripting and dedicated SASS-files for its styling. As components is the go-to method for web development nowadays, I really wanted to integrate this way of working into my MVC app(s).

There is SFC’s (single file components) but as you need Vue Loader and Webpack for that, this was not a real option for projects still using MSBuild and the standard ways of bundling. So on went my search but I wasn’t able to find a good centralized explanation on how to put it all together. Most blogs talk about using them in SPA’s and such with Webpack but never about using them in legacy projects… That’s why, after finally having figured out a good implementation, I planned to write a single blog-post about it hoping to save other people some time that could be spend on more lucrative features.

[UPDATE 2019/02/08] I didn’t stop to search for an SFC solution, found it and wrote about it in here… https://dev.to/keco39/vue-sfcs-in-an-aspnet-mvc-app-3e45

First, I’ll start with the 2 steps that are only needed the first time you would like to add support for Vue-components to your project.

Step 1 — Setting up TypeScript

I use TypeScript (https://www.typescriptlang.org) as my main scripting-language. Not only does it give you strong typing and improved intellisense but it also makes sure your templating strings will still work if you open your website in Internet Explorer. The reason for this is, when using a template string (read https://vuejs.org/v2/guide/components.html for more details) in multiple lines, you will need backticks for that. As backticks are an ES6 feature, Internet Explorer would not recognize the character in your template string and thus fail to render your component. Make sure you target ES5 within the tsconfig.json file so all backticks will be transpiled into single quotes, thus gaining support for older browsers.

Step 2 — Add a reference to the Vue library

As with all third-party libraries, you need to add Vue to the bottom of your webpage, above the scripts that will create and register your components (eg. https://cdnjs.cloudflare.com/ajax/libs/vue/2.5.17/vue.js).

Once these 2 steps are done, you never have to look at them again except for when you start a new project.

And now on to the cool bits, creating and registering your Vue components. For that, there are 4 steps.

Step 1 — Creating a component

I have a folder called ‘/js/components’ in which a TypeScript-file is created with a filename starting with vue-*, followed by the name of your component (preferably, the following words are also separated by a hyphen). How to create your component can be found in the official documentation on https://vuejs.org/v2/guide/components-registration.html

For example:

/js/components/vue-component.ts

I prefer to assign the returning value to a variable and the reason for that will be explained in the second step.

Step 2 — Registering your component

As the created component is still unknown within your web app, you need to register it by initializing Vue. For this, I create a different file within my ‘/js’ folder called component-loader.ts, making it clear this file is meant for registering (thus loading) your components using Vue.

For example:

/js/component-loader.ts

It is not necessary to use the option ‘components’ (passing an object containing all components that you want to register) as, without it, all of your components will be known within your web project instead of only the list that is passed. I prefer explicit naming as I sometimes create several instances for different kinds of components (eg. myFormComponents, myGalleryComponents etc.). As for the selector ‘#main’, this will be the semantic element (mostly a div) in which the component(s) will be loaded.

As of now the HTML-tag ‘vue-component’ can be used in your project.

You noticed I assigned the value of the instance to a new variable and that is because of the following (handy) feature… Let’s say you use the tag as follows:

Vue component usage in HTML document

The HTML-tag ‘vue-component’ (the given name when creating the component) is created with a name attribute (data property) and a reference-name to that component. With that reference, it’s now possible to use the variable to which you assigned the value of the instance, followed by $refs, followed by the ‘reference name’ , followed by a property that was configured when creating the component. Eg.

Step 3 — Bundling

As bundling is still mandatory to keep your scripting footprint as low as possible, you need to minify and bundle up the resulting JavaScript-files (transpiled from TypeScript). I added, in this case, the component- and the loader-file to the bundle and placed them at the bottom of the HTML-page, just below the reference to the third-party Vue library.

Javascript bundle with components (.NET functionality)

Step 4 — Git

To make sure the transpiled JavaScript-files won’t be added to your git-repository, add those files to a .gitignore file. The Javascript-files are better off being created by a CI/CD-build.

.gitignore rules to exclude JavaScript files

As a result, you now have a working Vue-component with scripting and HTML bundled into one file, leaving out only the styling bit which still goes into a dedicated CSS/SASS-file. Hopefully, this can be combined one day…

Another challenging feature was using i18n as most sources only talk about the plug-in, not an option, but that’s something for my next blog-post.

Thanks for reading!