Posts Tagged ‘javascript’

My new course is all about using the Heroku cloud hosting platform with Node.js. I already have a course on using PHP with Heroku, and not bragging, but it has Udemy’s “Highest Rated” badge. Okay, there is a little bragging. Hopefully, this one will receive the badge, too.

Preview the course on Udemy or watch the trailer below.

Back in the day, unit tests and code coverage were the in thing. You wrote a class, you wrote a unit test for that class. Everything was tested at an individual level and you built integration tests on top of that.

Then we realised that maintaining all of these unit tests was a massive pain in the neck, made it tedious to refactor the code and didn’t provide much value when the real business value was only concerned with everything working together so that the user being able to successfully complete a journey. So, we started writing tests to the API boundary.

Fine. Except it wasn’t fine. The problem is that per-class unit tests are really useful when it comes to understanding other people’s code.

Let’s say we have a component and it is composed of many different internal functions and classes. We write a test to the API boundary so that people can use the component and we know that it works when people use it. That is fine if you are the only person maintaining the component and you have a good memory.

But what if multiple people work on the component and somebody else needs to refactor it? You could try looking in the docs. There are unlikely to be any, though, because it is an internal function. You could try reading the code. This approach is probably the one we rely on most of the time and often works. But if often isn’t too obvious, especially in loosely typed languages with lots of callbacks (*ahem* javascript).

How do you know what goes in and comes out of a function without docs and without types? You don’t. But having a unit test demonstrating stuff being passed in and out is really useful for making an educated guess.

When I first launched the WAM website it was built using a reasonably straightforward stack of React + Babel + Webpack. That was a year or two ago and a lot has happened since then. Notably, there have also been some JS security issues, too, so we’re going to start upgrading the stack on a regular basis.

As anyone who has worked with JavaScript knows, though, that is a massive pain in the ass. Here are some notes on the upgrade process.

Upgrading Gulp

Gulp has now moved to version 4. First off, you need to uninstall any previous versions of Gulp. You then install the Guli CLI globally, and the latest version of Gulp locally.

npm install -g gulp-cli

This was a massive hassle. The uninstalls did not work and I had to manually go through the file system to get rid of the thing.

There were also some changes to the config itself. Any paths such as dest('') had to be changed to dest('.'), and all of the functions that defined the Gulp tasks had to now return, rather than just being called.

return gulp.task('name', () => { });

The way tasks were run within them has also changed. So, anywhere that used tp be ['sass'], for example, now needs to be:

gulp.series('sass')

Ugrading Node

You’ll want to upgrade Node to the latest LTS version. This includes editing the engine in your package.json file, especially if you are using Heroku.

Upgrading React

This was as simple as updating the versions in package.json and running an update. However, I did run into a problem with the React CSS Transition group, where I had to update to a drop in replacement.

npm install --save react-transition-group@1.x
npm remove react-addons-css-transition-group

And then change the import statement to import from:

react-transition-group/CSSTransitionGroup

Upgrading Babel

This was mostly a case of bumping the version numbers, but I also had to update my .babelrc file. I think the spread operator was previously a different package, and I had to change the name.

{
    "presets": ["@babel/react", "@babel/preset-env"],
    "plugins": ["@babel/plugin-proposal-object-rest-spread"]
}

Upgrading Webpack

Again, this started with bumping all of the versions. There were also some config changes. Most notably, Webpack now has an environment property.

config.mode = 'production';

It has also changed the way that UglifyJS is brought in if you’re using that to minify your code. You’ll need to install the new package.

npm install uglifyjs-webpack-plugin webpack-cli --save-dev

And then update your Webpack config, too.

config.optimization = {
  minimizer: [
    new UglifyJsPlugin({
      uglifyOptions: {
        output: {
          comments: false
        }
      }
    })
  ]
}

Hopefully this will come in handy if you are upgrading a similar stack and wondering why everything has exploded.

You are making an awesome new JavaScript-based app in React. However, it needs to live inside an existing framework, such as Symfony for PHP. You want the hot-reloading function that you get with Webpack Dev Server, but you also need the content to be served from your LAMP stack because it creates the HTML wrapper page.

What do you do?

The answer is to run two servers: both Webpack Dev Server and your existing Stack. Here is how…

Configuring Webpack

Start by installing Webpack Dev Server as usual.

npm install --save-dev webpack-dev-server

Create a script entry in package.json to run it:

"scripts": {
    "start": "node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js"
}

We also need to make one change to our webpack.config.js file. We need to tell the output to point back at the Webpack Dev Server. Otherwise, it will point at your LAMP stack.

output: {
    publicPath: 'http://localhost:8080/scripts/'
}

Super. Next, let’s configure the LAMP stack.

Configuring your existing server

This step is easy. All we need to do is to point the JavaScript at the Webpack Dev Server.

Let’s say you have this at the moment:

<script src="/scripts/app.js"></script>

Change it to:

<script src="http://localhost:8080/scripts/app.js"></script>

Remember that when you are building for production, you will want to take the changes out. The easiest way to do this is to have a dev webpack.config.js file, and a production one, and have your build tool use the correct one depending on the context.

Ember.js is a JavaScript framework for creating “ambitious web applications” apparently. What that translates to is a JavaScript framework that allows you to get started quickly and have URL-based apps.

It is under heavy active development at time of writing so means that there is plenty of new stuff but also means that the documentation can quickly get out-of-date, so it might take a bit of time fiddling around to get it bootstrapped up and up-and-running. There is a helpful Chrome plugin that fits into the Developer Tools too, though most of the time I spend time looking at the standard console.

Once you are ready to go, things are easy to build. It uses Handlebars, or at least a Handlebars style syntax, so if you have used Handlebars, or even Mustache before then you will probably have a basic idea of what you are doing. You can then layer up pages within each other to build complex applications that can all be bookmarked.

It is designed to work out-of-the-box with Ember Data, which provides instant support for a REST API. If you do not have a REST API, Ember.js claims it is easy to adapt to something else, though I’m sceptical that it is as easy as they claim. It seems to work best if you build the app, and then create a standard REST API to work with it.

I have implemented some simple embedded Ember.js apps for my photo gallery as well as working with it for some more complex projects elsewhere. It is a fun framework to work with, but the documentation is a little parse and it is not quite as flexible as I would like. See the Ember.js website for more information.

I’ve read Douglas Crockford’s book on JavaScript several time before, but it is always goof to have a refresher. It’s super-helpful and so short that you can easily get through it in a day if you try. I think the appendices are actually bigger than the text.

Recently I spent a good twenty minutes tearing my hair out over a JavaScript unit test I was trying to write. The answer turned out to be a difference in the way our Mocha-based DOM differs from how it would running JavaScript in a browser.

For example, let’s say you have a select field.

<select name="test" id="test">
	<option value="">Select an option</option>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>

In a browser, the top option would be selected by default, so if you had the following code:

jQuery('#test').val();

It would output a blank value as you would expect. However, run this in Mocha and you will get an undefined or a null. The reason is Mocha doesn’t select the top option by default unless you manually specify it to. So your HTML would have to look like:

<select name="test" id="test">
	<option value="" selected="selected">Select an option</option>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>

In which case, it would then return the value as it should.

These days, we’re all trying to do very clever things in the browser, that take up heaps of system resources. Often, your application will be doing so much that the system can barely cope – and with JavaScript being a single thread language, heavy processing can tie the UI up and make the user think the page has crashed.

Enter web workers – a background process that essentially allows you to do concurrent JavaScript. You can create a background process from a script, and then send messages back and forth between it and the page, ensuring you don’t tie up the UI.

They’re really simple to use too.

var worker = new Worker('worker.js');

worker.addEventListener('message', function(e) {
  console.log('Message from worker: ', e.data);
}, false);

worker.postMessage('Hello, World!');

Then create a simple JavaScript for your worker.

this.addEventListener('message', function(message) {
  this.postMessage(message.data);
}, false);

You can read more about web workers on HTML5 Rocks.

jQuery has an amazing set of selectors, but what happens if you don’t have access to jQuery?

It happens, especially if you’re writing the automated tests or working within an existing framework and don’t necessarily have control over the content of the page. Luckily, you don’t actually need jQuery!

All modern browsers support the use of querySelector. When I saw all modern browsers, I even include Internet Explorer which added basic support for it in 8 and full support in 9. You use it like this.

document.querySelector(“p.introduction”);

This works just like jQuery – selecting all paragraph tags with the class introduction.

Last month, I went to a talk by Richard McIntyre on “The Future of PHP”.

Turns out, it’s JavaScript.

More and more these days, web applications are being developed with fat front end clients loaded with JavaScript, and the server-side processing is primarily used for data processing and APIs. So we’re seeing a shift from PHP being used as a somewhat front-end technology to merely (I say merely, there is a lot of work to do it) delivering the content in a format the JavaScript front end can consume.

Perhaps this is why we’ve seen a rise in the number of microframeworks, such as Silex, that I recently blogged about.

I think the overriding message I took away from the talk though is that they’re inventing development platforms faster than I can learn them! I’ve already got a large list of technologies and libraries I need to review and I think I came away from this talk with another half a dozen!

Really enjoyed the talk though, and if you’re interested in PHP and in the Leeds area you should definitely check out the Leeds PHP User Group who host such events on a monthly basis.