How To: Offline access to Vue.js documentation

If you are working with Vue.js Javascript framework to build your next generation web apps then you might be frequently visiting the Vue.js guide section (https://vuejs.org/v2/guide/) to see how certain things work in Vue.js. Most of the time you go to the Vue.js site since that is the only available option for office docs.

But, often it happens we don’t have access to internet and we have time to read something then we usually go to our saved articles, guides, books, or any other content to read. In that case if we have Vue.js guide available offline we could have luxury to read that without connecting to internet. Well, that is possible.

How to download the guide?

To download the guide for offline access all you have to do is clone the official Git repo from GitHub and perform the following steps.

  1. Clone Vue.js Git repo from GitHub https://github.com/vuejs/vuejs.org
  2. Open terminal or command prompt
  3. Go to the directory/folder where you have cloned the repo
  4. If you have npm installed that is most likely if you are a developer then run the following commands:
    1. $ npm install -g hexo-cli
      $ npm install
      $ hexo server
  5. Browse http://localhost:4000/v2/guide/ in your favorite browser.

That’s it! You have Vue.js guide available offline.

The next time you want to access your offline guide all you have to do is open terminal, go to repo directory and run hexo server command.

Why Hexo?

Vue.js guide is built using Hexo blog framework. You can read more about Hexo framework on their website https://hexo.io/

What we did is just clone the repo and ran the hexo server from the hexo-cli we installed using npm. This is not convenient as reading a PDF but still we have an option to read the guide offline.

If this helped you or if you found a better way then don’t forget to leave a comment below.

Event handling with custom components in Vue.js

If you’ve been working with Vue.js lately and developing custom components to build your apps you might came across how to communicate from child component to parent. There are couple scenarios here.

Immediate parent child components

If you want immediate parent child components to communicate then child event can fire an event and parent can listen to it. To do this you can do something like this.

index.html

Vue.component('v-parent', {
 template: `
 
`, methods: { handleEvent() { alert('parent caught the event'); } } }); Vue.component('v-child', { template: `
Fire Event
` }); new Vue({ el: '#app' });

app.js

Non Parent-child components

If two different components want to communicate or if the component listening to the other component’s event is not a direct parent (like grandparent or even above in the hierarchy) then Vue provides the bus concept. I have created a fiddle on JSFiddle that you can see running here.

Code Refactoring

One reason why you should refactor your code often

Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy at the center of the system. As he wandered through the hierarchy, the consultant saw that it was rather messy. The higher level classes made certain assumptions about how the classes would work, assumptions that were embodied in inherited code. That code didn’t suit all the subclasses, however, and was overridden quite heavily. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places several subclasses did the same thing with code that could clearly be moved up the hierarchy.

The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn’t seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.

The consultant had also shown the programmers who had worked on the hierarchy what was
going on. The programmers were keen and saw the problem. They knew that it wasn’t really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functionality. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.

The project management was not pleased. Schedules were tight and there was a lot of work to
do. These two programmers had spent two days doing work that had done nothing to add the
many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more “pure” a bit more “clean.” The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn’t already do.

How do you feel about this story? Do you think the consultant was right to suggest further clean
up? Or do you follow that old engineering adage, “if it works, don’t fix it”?

Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance. The consultant was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring.

This is an excerpt from the book preface “Refactoring – by Martin Fowler”.