Final Fantasy like screen transition effect

transition-effect

I’ve created a small project where I tried to produce an effect similar to the Final Fantasy 8 screen transition effect.

You can see a video of the original effect here and my project in action here.

The code is accessible through the GitHub repository.

Whilst I’m a Firefox user first I had to resort to refreshing the page on Firefox as it leaked memory of the amount required for the canvas’ image data. This leak wasn’t present on Chrome, Edge or Safari.

I’m writing directly to the image data like a buffer which I found out is far from optimal. It’s far better to only stick to drawing primitives from the API but this ultimately limits what you can do which is why I stuck with the manual operation on the image data.

Using a type alias to create a new name for a preexisting type like Document

I often need to work with auto-generated types that have been generated by Swagger based on an API definition.

These types sometimes clash with the names of preexisting types. For example the Document object, which normally refers to: Any web page loaded in the browser and serves as an entry point into the web page’s content, but in my case is also the name of an interface generated by Swagger.

Since you don’t need to import the Document type to use it in TypeScript / Angular projects, every time I try to use the generated Document class it’s referring to the DOM’s Document by default.

This can be fixed by adding an import statement, but to avoid dealing with this project-wide we can use type aliases which let us give a type a new name:

type MyAppDocument = Document;

Since I can’t change the generated Document file itself, it would get overwritten the next time it’s generated, I create a type-alias.ts file like this:

import { Document } from './document';

export type MyAppDocument = Document;

Which then allows me to use the new MyAppDocument type everywhere.

Minimize the amount of changes in a changeset

When creating a new change set, always try to minimize the amount of changes it includes.

Do this by only modifying what needs to be modified to implement a feature or fix a bug. Keep formatting and refactoring changes for another commit.

The story of how I came to this practice

Many years ago I read Clean Code, a book I liked a lot. One of the things it discussed was to check in our code a little cleaner than when we checked it out. This meshed with the idea of continual improvement through refactoring which I was already following.

I took this principle to heart and made formatting changes, introduced constants, removed commented code and made small refactorings with my change sets. I kept big refactorings for different commits… well most of the time anyways…

Then later, on an open source project I contributed to, I was asked during code reviews to keep those changes out of the change sets. I was surprised since I thought I was improving the code’s quality. The reasoning was that the change set needed to include only the changes required to correct the bug that was addressed or implement the new feature we were working on. Refactorings should be kept as different endeavors or for instances where the code was being completely rewritten anyways.

Over time I started to see many cases in my own work where this made sense and eventually, after several years, started following this practice as well. One thing I like to do is keep notes of what changes I want to make, complete my work in a single commit and then make a separate commit for formatting and refactoring changes. If I don’t take notes, too often I forget all the little changes I wanted to do and never get around to doing them.

The why

When the commit needs to be read later on to understand the changes, revert them or when doing a blame/annotate to find out why a change was made it’s much easier if all the changes are related to the commit message and associated ticket number.  Otherwise you need to reason for each line if it was done in relation to the commit’s purpose or as a “bonus” refactoring.

Also, including unnecessary changes make for longer commits which make for longer code reviews. Both for traditional code reviews but also for yourself when you’re reviewing your changes before committing them (if you’re not doing this, this is a great practice everyone should adopt). In my experience the longer the review, the more chances some stuff will get glanced over.

Finally, every change we make, even when having a robust test suite risks introducing regressions. If you later find out your latest changes introduced a bug and it turns out it was in a refactoring, it’s much easier to revert or correct this refactoring without needing to revert a bug fix or remove a feature.

How to read from .json files from TypeScript / Angular

Locate your typings.d.ts file and add the following lines:

declare module "*.json" {
  const value: any;
  export default value;
}

Otherwise you will get an error saying the compiler can’t find module filename.json.

Then you can include a .json file in your project. For example this file:

{
  "version": "6.01"
}

And you can read from such a file like this:

import * as versionData from '../version.json';

// ...

if (versionData && (versionData).version) {
      this.version = (versionData).version;
}