The jump between Angular Material 2 Beta 10 and Material Beta 11+

Having just been through this experience I thought I would share some thoughts to help any other early Angular Material adopters navigate their way to the later Beta's - 11 and 12 as well as the subsequent release candidates.

Change 1
Angular Material no longer can be imported into your project as just one module. You must instead select all of the modules which you intend to use in the project.

Change 2 - seemingly innocuous..
The problem with upgrading between these two versions is that the Md prefix has been changed to Mat. This unfortunately now clashes with the AngularJS Material implementation... such as Md2.

We were early adopters of Angular Material, so we are still using Md2 by Promact. Originally this was used as a stopgap while essential components like the date-picker were being completed by the official Angular Material team. However, now, we wish to use both Md2 and Angular Material side by side. Especially since I was originally putting together the project with Angular 4.0.1 and now wish to upgrade to the latest.

ERROR Error: Uncaught (in promise): Error: The "mat-" prefix cannot be used in ng-material v1 compatibility mode.

To get around this you must use the "CompatibilityModule" or "NoConflictStyleCompatibilityMode" or something...?

jatkeshave commented on Oct 10, 2017

use compatibility module if you still want to use md- prefix like this import { CompatibilityModule } from '@angular/material'; and import it in app module if you want to use new mat- prefix which is good you can use NoConflictStyleCompatibilityMode like this import {NoConflictStyleCompatibilityMode} from '@angular/material';

When I first read this comment I was still confused. I just want my solution to work - what is all this!? This comment further down these thread helped me to understand:

Issue 1 thread
Issue 2 thread and relevent comment

I tried importing from material itself but this did not clear the errors.

import { NoConflictStyleCompatibilityMode } from '@angular/material';

Instead the solution seems to be to import and therefore invoke the NoConflictStleCompatibilityMode from MD2.

import { Md2Module, NoConflictStyleCompatibilityMode } from 'md2';

This makes sense because the use of mat in an angular/material v1 context can no only be in the MD2 project.

Checking Out React

I started my journey at the React Tutorial Page. While reading the introduction and checking out the code example on Codepen, I then had the notion that seeing as it was a Tic-Tac-Toe game, it might be nice to do it more properly and include it on my website.

Once down this road I then decided it would be good to turn it into a mini project to find out more about yarn and webpack, as these compliment the React world and are the shiny new toys in front-end web development.

This first blog in the series is about the setup.

Notes on Yarn and WebPack
I have heard that Yarn is better than NPM as a package manager, it is faster and more reliable. Webpack is more complex/flexible than Grunt or Gulp as a builder tool but, like my personal favourite JSPM (through systemJS) it is an excellent JavaScript module loader out of the box. Webpack is much more popular than JSPM within the React community.

Back to Tick-Tac-Toe
So I used npm to install yarn, ran yarn init and then used it to bring down my dependencies React and React DOM. I was pleased to find that there is no difference in where the modules are stored - it is still in a folder called "node_modules". I was also aware that I needed to "transpile" the ES2015 React code into ES5 so I installed babel using the "webpack" option on the babel installation page.

npm install --save-dev babel-loader babel-core

Notice that this is based on npm, but this was no problem, you can just replace "npm install" with "yarn add" and the command "--save-dev" with "-D". This was all easy to find here.

Using Webpack to transpile ES2015 back down to ES5
After some research I have found that the best way to use Webpack with babel, karma and react is to use the following packages:

With this setup I was able to setup a simple "hello world" example. I will get into more detail with my next post.

Windows Azure and Node - Remember to specify the version

I kept finding that my back end code would subtly fail on something once deployed to an Azure site despite working fine in my own environment. Having hit the problem again recently, I again looked through the server logs to try to identify the problem assuming that again Node would be throwing an error over some very simple syntax.

Then I noticed the following:

"The package.json file does not specify node.js engine version constraints"
"The node.js application will run with the default node.js version 0.10.32"

This is old, in fact to put this into perspective the contemporary node change logs start from 0.12.0 which is the beginning of 2015. I had to go through their archive to find out where this version is from, which is October 2014!

Now I know, the solution is to specify the node engine that Windows Azure should use. e.g.

As soon as I had made this change my problems went away as you may expect. Looking at the latest "how to" guide on the Azure website for node development I notice that this features at step 5. However, for those who have legacy node websites on Azure, this is not so intuitive.

Isomorphic or Universal Javascript

Why I have decided to learn about this?
I first truly took note of the term "Isomorphic JavaScript" when a recruiter sent me through a job which I thought looked extremely interesting. At the time I was not looking for a job, but it reminded me about the long standing problem with decent SEO and Single Page Applications (SPAs). I had heard a lot about React and Angular 2 providing some way to solve the problem, so I was curious.

Notably, the company in question were listing some other design patterns and technologies which were new to me and were also of interest: 12 factor app, Mesos and Marathon, CircleCI.

Godammit man, what does Isomorphic mean!
Isomorphic means "corresponding or similar in form". So essentially we are describing some sort of server side rendering to support the client side application.

Or as the AngularJS Universal Repository puts it: "A JavaScript Application that runs in more environments than just the browser".

The advantages?

• The application does not need to rely on JavaScript being turned on in the browser for it to function
• The application does not need to have a loading gif to explain to the user that patience is required
• THE BIG ONE - The application can be more easily crawled by search engines because the page is also available from a static URL.

Some disadvantages and limitations

• "Uncanny valley" - this is a term used to describe the time between the application appearing to be functioning and available and the time before it is actually responding to the users demands. This can be confusing for the user.
• Loss of separation between back-end and front-end application code. However, I would say, in this API/ Micro-service architecture world, that this actually makes quite a bit of sense. The User Interface will still be separated from Business Logic, we are just blurring the line between server-side "Get" request responses and view rendering.
• This is still just a bootstrapping technique and some SEO issues do still remain.

For a more thorough discussion on why Isomorphic JavaScript is "not the answer" take a look at this discussion on ycombinator (at your own risk of course!).

Karma Error: You need to include some adapter that implements __karma__.start method

An error message which means very little. Something has gone wrong with Karma and it is affecting mine!

It looks like some breaking changes made in Karma-Runner 1.0.0 have really screwed over all the plugin projects such as Karma-Jasmine which I very much rely upon.

The only way around it at the moment is to downgrade Karma to 0.13.22 until Karma-Jasmine is compatible with v1.x.x versions of Karma.

---

v1.0.0

 dignifiedquire released this on Jun 23

BREAKING CHANGES

• context: Our context.html and debug.html structures have changed to lean on context.js anddebug.js. This is in preparation for deeper context.js changes in #1984.

As a result, all customContextFile and customDebugFile options much update their format
to match this new format.

---

Hmm clear as mud huh?

Certainly I will be keeping a close eye on this issue to see when I can upgrade safely.

UPDATE: It looks as though this has been fixed - all the errors related to this were consolidated in issue 2194 and released just days after I wrote this post.

Hitting a bug where the best fix is to update... everything

Background

I have been working on a number of MEAN stack projects for the last year and a half. I had been moving rapidly between one project and the next, however, since December last year I have been working consistently on the same ambitious web application.

I have been so focused on delivering new features that I have not been updating my packages at all.

This finally came to a head when trying to improve my production build process.

I was trying to use the gulp-jspm plugin to allow me more control over my JSPM bundled front end JavaScript. Until now I have been using some hacky powershell to bundle my transpiled JavaScript - not the best for adding in more processes into my production build.

Starting Out

After hitting a few minor hurdles I was successfully generating a bundled file through gulp. Hwever when I loaded the application in my test of production mode locally I was getting a "System is not defined error" in the console.

After reading up on the "System is not defined error", it seems that this was fixed at the back end of last year, just when I stopped updating everything. So, time to commit what I have and then head full tilt into the world of updating third party packages...

NPM Tip

There is a command in NPM which tells you exactly which packages are out of date:

npm outdated

This was a useful starting point to try to evaluate how many of the modules needed to be updated and how badly out of date they were. Luckily most of the most crucial babel packages for node seemed to update fine.

Unlinked and operation not permitted ??

When trying to update the JSPM modules, in particular Angular ones with numerous links to one another. I got a number of confusing "please unlink" messages. It seems that this is JSPM's way of moaning about version inter dependencies. The way through this seems to be to remove the main files like Angular and reinstall which sucks, but got me through to the next set of errors.

After a while I was getting a serious blocker in the form of:

Error: EPERM, operation not permitted

I found a number of more recent posts suggesting to readers that they should use the NodeJS console with administrator permissions. I did try this but sadly the end result was no different to using ConEmu in administrator mode.

I then checked the NodeJS version and noticed that it was somewhat out of date @4.2.2 when the current version of NodeJS stable is @4.4.3. The clue here was again from some historic NodeJS GitHub issues. After updating NodeJS JSPM and NPM package managers started working without me having to manually uninstall and reinstall packages.

I finally got to the end of this mammoth updating spree. I run Gulp to build my JSPM build file which was where I was getting the "System is not defined error". The same problem remains. It turns out that the only issue was me misunderstanding the "self executing file" concept in JSPM.

There are three options with JSPM. Either you can generate a self executing file which includes everything that your program needs, including System.js and a "micro-loader". You can create a bundle which must be called by your html - and therefore you must make the node_modules location available. The third option is a full HTTP2 SPDY implementation which seems overkill for me at this moment in time.

The solution was to change the following in my Gulpfile to generate the self executing version:

gulp.task("default", function() {
    gulp.src("sysadmin/main.js")
        .pipe(gulp_jspm({verbose: false, selfExecutingBundle: true}))
        .pipe(rename("build.js"))
        .pipe(gulp.dest("sysadmin/dist"));
});

I have to be philosophical I guess, this blog post might well have the same outcome in my mind as the EU referendum but its a good lesson in why it is important to keep software dependencies up to date, it can lead to a lack of confidence which ends up wasting time.

Setting up Karma to play nice with JSPM

The TL;DR version

I was getting quite frustrated with unit testing today because when I was attempting to use ES6 features like Array.find I was greeted with errors like this one.

TypeError: undefined is not a constructor (evaluating 'categories.find(function (cat) {
                                return cat._id === id;
                            })') (line 19)

I noticed I was also getting a message like this in my stack trace:

tryCatchReject (http://localhost:9876/base/jspm_packages/system-polyfills.src.js

Why couldn't SystemJS load polyfills? It was managing it fine in my browser, at least that is what I assumed.

I made a mistake and thought that I must need to pre-process my unit tests so that they become babelified or ES6 ified or JS2015 ified etc...

I started looking at this...
https://github.com/babel/karma-babel-preprocessor
This made it worse because I was trying to re-implement using a different tool the same task which is being undertaken by JSPM and SystemJS.

In the end the answer was rather than keep adding configuration, strip out configuration and then add just one extra line.

I actually found this tip/clue from the karma-babel-preprocessor configuration page.

Polyfill

If you need polyfill, make sure to include it in files.

npm install babel-polyfill --save-dev

module.exports = function (config) {
  config.set({
    files: [
      'node_modules/babel-polyfill/dist/polyfill.js',
      // ...
    ],
    // ...
  });
});

I added the line above to the files array and "hey presto" all my unit tests were working fine with array.find. To prove that "karma-babel-preprocessor" was not needed I uninstalled it and re-ran my tests.

I later found that I also needed to reference babels polyfill.js in the client-side code that was using the find method.

The only reason I had not noticed was because Chrome has a native implementation. However MS Edge and all other IE browsers do not, so nothing worked on those browsers - a dead giveaway. I added this line to the files in question:

import "babel-polyfill";

See: https://babeljs.io/docs/usage/polyfill/

I found later that sometimes the unit tests would still crash PhantomJS. The final solution to this was to split the specification files from the implementation files using the following from karm-jspm:

jspm: {
    loadFiles: ['test/**/*.js'],
    serveFiles: ['src/**/*.js']
}

The theory being that you don't need to load the actual files to be tested until you have initially loaded the tests themselves.

I think it is fair to say that sometimes Karma does not like to play nicely with JSPM, although this does seem to depend on your project structure as well. I hope these little tips either help to resolve an issue or go someway to alleviate some confusion.