Monthly Archives: November 2018

Vue components in Angular

I have an application written in AngularJS (v1) that I keep adding things to. Nowadays I prefer to write new code for Vue.js rather than AngularJS but rewriting the entire AngularJS application is out of the question.

However, when the need shows up for a new Page (controller in AngularJS) it is quite simple to write a Vue-component instead.

The AngularJS-html looks like this:

<div ng-if="page.showVue" id="{{ page.getVueId() }}"></div>

You may not have exactly “page” but if you have an AngularJS-application you know how to do this.

Your parent Angular controller needs to initiate Vue.

page.showVue = true;
var vue      = null;
var vueid    = null;

page.getVueId = function() {
    if ( !vueid ) {
        vueid = 'my_vue_component_id';
        var vueload = {
            el: '#' + vueid,
            template : '<my_vue_component />',
            data : {}
        };
        $timeout(function() {
            vue = new Vue(vueload);
        });
    }
    return vueid;
};

At some point you may navigate away from this vue page and then you can run the code:

vue.$destroy();
page.showVue = false;
vue          = null;
vueid        = null;

The way everything works is that when Angular wants to “show Vue” it sets page.showVue=true. This in turn activates the div, which needs an ID. The call to page.getVueId() will generate a Vue component (once), but initiate it only after Angular has shown the parent div with the correct id (thanks to $timeout).

You may use a router or have several different Vue-pages in your Angular-application and you obviously need to adjust my code above for your purposes (so every id is unique, and every component is initatied once).

I suppose (but I have not tried) that it is perfectly fine to have several different Vue-components mounted on different places in your Angular application. But I think you are looking for trouble if you want Vue to use (be a parent for) Angular controllers or directives (as children).

Vue.js is small enough that this will come at a quite acceptable cost for your current Angular application and it allows you to write new pages or parts in Vue in an existing AngularJS application.

Webpack: the shortest tutorial

So, you have some JavaScript that requires other JavaScript using require, and you want to pack all the files into one. Install webpack:

$ npm install webpack webpack-cli

These are my files (a main file with two dependencies):

$ cat main.js 

var libAdd = require('./libAdd.js');
var libMult = require('./libMult.js');

console.log('1+2x2=' + libAdd.calc(1, libMult.calc(2,2)));


$ cat libAdd.js 

exports.calc = (a,b) => { return a + b; };


$ cat libMult.js 

exports.calc = (a,b) => { return a * b; };

To pack this

$ ./node_modules/webpack-cli/bin/cli.js --mode=none main.js
Hash: 639616969f77db2f336a
Version: webpack 4.26.0
Time: 180ms
Built at: 11/21/2018 7:22:44 PM
  Asset      Size  Chunks             Chunk Names
main.js  3.93 KiB       0  [emitted]  main
Entrypoint main = main.js
[0] ./main.js 141 bytes {0} [built]
[1] ./libAdd.js 45 bytes {0} [built]
[2] ./libMult.js 45 bytes {0} [built]

and I have my bundle in dist/main.js. This bundle works just like original main:

$ node main.js 
1+2x2=5
$ node dist/main.js 
1+2x2=5

That is all I need to know about Webpack!

Background
I like the old way of building web application: including every script with a src-tag. However, occationally I want to use code I dont write myself, and more and more often it comes in a format that I can not easily just include it with a src-tag. Webpack is a/the way to make it “just” a JavaScript file that I can do what I want with.

Linux Apps on Chromebook R13! Finally!

For a while I have owned an Acer R13 Chromebook that I occationally have used as a development computer. I have been using Crouton, which is quite ok, but it is like something is missing.

Lately there has been talks and writings about Crostini, Container technology on Chrome OS, which enables Linux applications to run in Chrome OS. This would be different from Crouton in different ways, like:

  1. The Chromebook does not need to start/run in unsafe developer mode.
  2. There is a Terminal App, instead of running Crosh in the browser

This is perhaps not huge, but it is a step closer to making Chrome OS more universally usable.

New features are added to Chrome OS on different times for different devices. Just now (according to this thread) “Linux” was added to the Development Channel for Acer R13. I can confirm it. I changed channels to Beta (R71) and got nothing. I then switched to Dev channel (R72) and now I finally have Linux (Beta).

I guess in a few weeks R72 will have made it to Stable. If everything seems fine I will probably switch back to Stable, disable Developer mode and never touch Crouton again.

The terminal gives me a standard Debian Stretch system. The terminal itself is very minimal. I am aware of these shortcuts:

  • Ctrl + : make text larger
  • Ctrl – : make text smaller
  • Ctrl Shift P : open preferences
  • Ctrl Shift N : open new terminal windows

Compared to the terminal application I am used to in Debian or macOS this is pretty basic (and the limitation of Chrome OS is that you cant just install another terminal application easily).

Unfortunately I tried to install something (the screen command) using apt-get, and something went wrong. apt-get does not finish and when I open another terminal it crashes. A restart of the computer fixid this though. However, when during more real work things crashed on me. So there is clearly a reason for this to be in Development rather than Beta or Stable today, but it is very promising and fun nevertheless.

A new MacMini! Finally!

After well over four years Apple upgraded the MacMini!

I have like most other people only read about it, and I may never own one. But I can have opinions (as I have had before) about it anyway!

First, it is clearly a fine machine. If you buy it, put it on your desk and make use of it, it will probably serve you well for many years.

I think it is a shame that the SSD is (as it seems when I write this) not a standard replacable M.2/PCI unit. It would be so easy, trivial, and cost nothing, to make it a user replacable part (just like the memory appears to be). To me, this is a reason not to buy it. A non-replacable SSD is worse than non replacable RAM.

Previously – especially the earlier version – MacMini has been quite limited. It has seemed Apple has not wanted it to compete with the MacPro or the iMac in any way. Now it is possible to equip a MacMini with i7 CPU, 64GB of RAM and a lot of SSD storage. I think Apple has accepted that professionals will get it for doing real work (I think Adobe-stuff and perhaps programming). That is somewhat an interesting shift.

However, the entry level MacMini costs twice as much as the entry level MacMini cost when it was the cheapest. Apple seems to have abandoned the idea of selling it to regular consumers on a limited budget or as a dedicated media machine. I think it is a pity. Also if it was $449 it would be less of a problem that the storage is not replacable.

The GPU is not really for gaming and I kind of keep wondering why Apple does not release a computer suitable for Steam and market it with “pro gamer approves it runs top 10 games at 1920×1080”. However, external GPUs are becoming a real thing and perhaps a quite standard MacMini, with external storage and an external GPU could be a reasonable machine for gaming. But I don’t regret buying my Hades Canyon for gaming.

A “cheap” Apple laptop still seems like the best option to stay in the Apple ecosystem but also the new MacBook Air is quite pricey (and how can they get rid of the mag-safe?). I owned my first Mac in 1993 and I am typing this on a MacBook Air 11, but it may be the last Apple computer I ever own.