
Once again, I've refactored my blog. I did this back in [2019](/blog/2019/07/26/move-to-github-pages) when I moved to GitHub Pages and Gatsby. I do this once in a while to teach myself something new. This time, I wanted to learn [Next.js](https://nextjs.org/) and [Tailwind CSS](https://tailwindcss.com/). I gotta say, the DX of these tools is amazing! I don't really use Next to it's potential, right now it's really just spitting out some static HTML pages for my blog but it gives me a little more that I can do.

# Architecture

I've also moved things around. With my last refactor, this site was just a collection of blog posts. Go to `https://mitchellsimoens.com` and you'd see a list of blog articles. These then pointed to URLs such as `https://mitchellsimoens.com/2019/07/26/move-to-github-pages` and you'd see that blog article. Now, I've nested all these blogs into the blog directory so that now I can start having other things in this site. What other things? Not sure.

# Cloudflare

When I moved to GitHub Pages, I had Cloudflare's CDN in front of it. I've loved it. Recently, Cloudflare now has it's own [Pages](https://pages.cloudflare.com/) service. So now, I could move my static HTML pages under one provider. I can open PRs and Cloudflare Pages will stand up a full ephemeral environment automagically. In the PR, I get a nice little link to this environment to easily see. I say environment because they also have integration with [Cloudflare Workers](https://developers.cloudflare.com/pages/platform/functions/) which I'm more and more a fan each time I use them.

Once again, the DX of Cloudflare Pages has been outstanding to work with. I'm starting to see why some companies focusing on DX are really succeeding in today's world.

# Content Updates

With Gatsby, I could support different plugins to parse the Markdown that I write blogs with. With Next, I now can also use MDX. I'm not sure I'm a big fan of MDX but it's something I can easily support so... why not?

One thing I am a fan of, and GitHub recently started [supported](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/) it too, is [mermaid](https://mermaid-js.github.io/mermaid/). So I support that within Markdown here too:

```mermaid
graph TD;
    A-->B;
    A-->C;
    B-->D;
    C-->D;
```

# Future

Besides one day eventually refactoring everything into something new, I do plan on playing around more. I don't have specifics yet as my day job and being a father keep me very busy. But I look forward to doing more with Next, Tailwind and Cloudflare.


Next.js Iteration


In the world of [Node.js](https://nodejs.org/), you're gonna be using the [npm cli tool](https://www.npmjs.com/). You're
also going to find lots of blogs telling you how to do things but I constantly find one piece of info lacking and
surprisingly, this is about installing node modules in a project. Well, I guess there are two things that are related
and one sort of makes the other moot.

## Version Pinning

One thing I always try to get people to do is pin versions of their dependencies in `package.json`. What pinning does is
makes anyone installing the dependencies always have the same version. By default, npm adds the `~` prefix to the
versions so if you were to `npm i @mitchellsimoens/versionator` it will use `^1.0.5` as the version. This means, if
1.0.6 or 1.1.0 is released, someone could have a different version that has been untested and may have features not
present in older versions. This can add confusion but even worse, this can add risk (even for
[attacks](https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes)). The `~` prefix is a little better
but the same issues can still occur only it locks down the possibilities to patch versions not minor versions.

So what's the big deal? In today's world, we have to admit we freely install node modules from anyone. This means we
put a lot of faith in people and while I would hope people have great intentions, some don't and even great intentions
aren't perfect. Also, not everyone follows semver strictly so a minor version maybe should have been a major.

You're best to protect yourself as best as you can by pinning versions. I even change the default to always pin via
npm's config:

```sh
npm config set save-exact=true
```

I'll be honest though, this is a bit of a false sense of security as it's not 100% but it's at least some form of
prevention. Someone I work with found this [blog post](https://docs.renovatebot.com/dependency-pinning/) that does a
great job at some pros/cons of version pinning so I definitely think that is worth a read.

## The Right Command

The other thing sort of makes version pinning moot. Say you clone a repo that contains a node project, what do you do
first? I bet you run `npm install` (or `npm i`). You just used the wrong command. Instead, and hopefully everyone checks
in the `package-lock.json` into VCS, you should get into the habit of using `npm ci`. What this command does is installs
what is in `package-lock.json`. If you used `npm install`, npm will go and try to find the latest version of your
dependencies (and their dependencies) that match the version and version prefixes come into play then. Npm will then
update the `package-lock.json` with these updated versions and you just introduced risk.

In fact, I ran a quick poll of some colleagues and 10 out of 11 (the poll got pushed way off screen with all the
replies) used `npm install` and some didn't even know about `npm ci`. The one person is someone I work with a lot so
wasn't a surprise there. This is also why I will still pin versions to get at least some sort of protection from those
not using `npm ci` when they should.

If you are adding a dependency, then use `npm install` since that will just add the dependency(ies) and not upgrade all
existing dependencies. If you are wanting to install all dependencies then use `npm ci` and protect yourself.


NPM Install


I've seen a few blogs about publishing a node module to the [NPM] repository and
[GitHub Package Registry (GPR)][gpr]. Some I like, some I don't. I thought, what's better than a couple
existing blogs about it? One more. I also have some ideas for the stuff I've done that may be a bit unique to
me but the workflow I have can be easily adjusted to remove parts if that isn't desired.

## The Why

Why publish a node module to NPM and GPR? Being the default, publishing to NPM is still a great idea. However,
lately, I've seen some projects start going with GPR also. Yes, installing a node module that your `.npmrc` is
targeting GPR will still get proxied to NPM, I still feel it could be a good idea to also publish to GitHub. I
also want to have a GitHub release created without just relying on a git tag.

## Splitting the workflow

The workflow I will be talking about has 4 jobs:

- [`build`](#build-job)
- [`release`](#release-job) (requires `build` job)
- [`publish-npm`](#publish-npm-job) (requires `build` job)
- [`publish-gpr`](#publish-gpr-job) (requires `build` job)

The last three rely on the `build` job but allow those three to run in parallel. Let's look more at each
individually but at the end I'll still show the entire `.github/workflows/publish.yml` file.

### `build`<a name="build-job"></a>

```yml
build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: 14
    - run: npm ci
    - run: npm run lint
    - run: npm test
    - run: npm run build
    - name: Zip lib & node_modules
      run: zip -9qry "build.zip" "./" -i "node_modules/*" -i "lib/*"
    - name: Upload build.zip
      uses: actions/upload-artifact@v2
      with:
        name: build.zip
        path: build.zip
```

I personally use [TypeScript] a lot so I need do need to build it. I also like to run a quick lint check and
run tests as this is the last opportunity to stop a release.I also zip up the build artifacts (`node_modules`
and `lib` in this case) and then upload them so the subsequent steps can download it and use it.

One thing not to overlook is when installing I use `npm ci` instead of `npm i` so that I only install what is
in the lock file and nothing possibly new. I see people using `npm i` far too many times even during
development. Updating dependencies should be a planned thing and not happen just whenever anyone feels like it.

If you don't use TypeScript or anything else that would require a build, you can simply remove that step and
the `lib` dir from the zipping but I still would zip and upload the `node_modules` dir. This would then look
like this:

```yml
build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: 14
    - run: npm ci
    - run: npm run lint
    - run: npm test
    - name: Zip lib & node_modules
      run: zip -9qry "build.zip" "./" -i "node_modules/*"
    - name: Upload build.zip
      uses: actions/upload-artifact@v2
      with:
        name: build.zip
        path: build.zip
```

The same would be true if you didn't have or didn't want to run the lint check or tests.

### `release`<a name="release-job"></a>

```yml
release:
  needs: build
  name: Create GitHub Release
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - name: Download build.zip
      uses: actions/download-artifact@v2
      with:
        name: build.zip
    - name: Create Release
      id: create_release
      uses: actions/create-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ github.ref }}
        release_name: Release ${{ github.ref }}
        body: Stuff happened
    - name: Upload Release Asset
      uses: actions/upload-release-asset@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        upload_url: ${{ steps.create_release.outputs.upload_url }}
        asset_path: ./build.zip
        asset_name: build.zip
        asset_content_type: application/zip
```

This is where things start happening. Creating GitHub releases is a great thing as it allows you to hold build
artifacts and have some body describing things in that release. There are many ways to build the body of the
release so I left it simple in this workflow as I've had to do many different things. Notice here, we download
the zipped build artifact but we don't unzip it. We upload that zip to the release after it has been created.
The reason for this is when the `create_release` step executes, it actually hits GitHubs create release API
which then uses the source for that tag. This is important as it does not create a release from what is
currently on disk so if you did this after a build (or unzipped the build artifact), that wouldn't show up
in the GitHub release.

I think it's important to upload the build artifact to the GitHub release so you have that zip bound to that
release which does include the `node_modules` dir. This is important because many people have dependencies in
their `package.json` with a prefix meaning the versions of the dependencies are not locked. When not locked,
you can never count on installing that exact version without some work. So upload the build artifact and you
are good to go without any work.

If you don't know, when you see `${{ secrets.GITHUB_TOKEN }}` that does not mean you need to go into the repo
settings and add a secret. That is a special secret that is generated for you when it's used. Also, the
`actions/create-release` action specially handles the `${{ github.ref }}` to strip away the `refs/tags/` part
to just have the actual tag name. So the `${{ github.ref }}` would really look like `refs/tags/v1.0.0` but
it removes it and so you'd just have `v1.0.0`.

### `publish-npm`<a name="publish-npm-job"></a>

```yml
publish-npm:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: 14
        registry-url: https://registry.npmjs.org/
    - name: Download build.zip
      uses: actions/download-artifact@v2
      with:
        name: build.zip
    - name: Unzip build.zip
      run: unzip -q build.zip
    - run: npm publish --access public
      env:
        NODE_AUTH_TOKEN: ${{secrets.PUBLISH_NPM_TOKEN}}
```

Publishing to NPM step is pretty simple. We setup node setting the registry url to NPM, then download the
build artifact from the [`build`](#build-job) step, unzip it so that the `lib` directory is present and then
run `npm publish`. This step does require you to create a token over on [NPM] and add it as a secret to your
repo settings.

### `publish-gpr`<a name="publish-gpr-job"></a>

```yml
publish-gpr:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: 14
        registry-url: https://npm.pkg.github.com/
        scope: '@mitchellsimoens'
    - name: Download build.zip
      uses: actions/download-artifact@v2
      with:
        name: build.zip
    - name: Unzip build.zip
      run: unzip -q build.zip
    - run: npm publish
      env:
        NODE_AUTH_TOKEN: ${{secrets.PUBLISH_GITHUB_TOKEN}}
```

The publish to GPR is very similar to the [`publish-npm`](#publish-npm-job) but there are a few differences.
First, when we setup node we give it a different registry-url but we also need to specify the scope. All this
is is the username or organization name the repo is under. So for me, if I have the repo
https://github.com/mitchellsimoens/foo then `@mitchellsimoens` is the scope. The next difference is of course
we need a [GitHub token](https://github.com/settings/tokens) which needs the `write:packages` scope (this will
also automatically check all the `repo.*` and `read:packages` scopes). A keen eye also would notice that the
`npm publish` here doesn't have the `--access public` because with GPR the access is determined by the scopes
on the user token being used.

## The whole workflow

The whole workflow is mostly all of the above concatenated but it also includes what triggers the workflow. I
have mine trigger when a tag with the `v` prefix is pushed. This means, I run `npm version patch` (or whatever
version) and then push the commit and tag up. I've seen some people push all tags (`git push --tags`) which is
fine but if there are any other tags with `v` prefix in it that have not been pushed you could trigger unwanted
publishes so you may want to push a single tag like `git push origin v1.0.0`. Up to you if you care about that.

Ok, here is the full workflow I normally put as `.github/workflow/publish.yml`:

```yml
name: Publish

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 14
      - run: npm ci
      - run: npm run lint
      - run: npm run build
      - name: Zip lib & node_modules
        run: zip -9qry "build.zip" "./" -i "node_modules/*" -i "lib/*"
      - name: Upload build.zip
        uses: actions/upload-artifact@v2
        with:
          name: build.zip
          path: build.zip

  release:
    needs: build
    name: Create GitHub Release
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Download build.zip
        uses: actions/download-artifact@v2
        with:
          name: build.zip
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
      - name: Upload Release Asset
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./build.zip
          asset_name: build.zip
          asset_content_type: application/zip

  publish-npm:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 14
          registry-url: https://registry.npmjs.org/
      - name: Download build.zip
        uses: actions/download-artifact@v2
        with:
          name: build.zip
      - name: Unzip build.zip
        run: unzip -q build.zip
      - run: npm publish --access public
        env:
          NODE_AUTH_TOKEN: ${{secrets.PUBLISH_NPM_TOKEN}}

  publish-gpr:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 14
          registry-url: https://npm.pkg.github.com/
          scope: '@mitchellsimoens'
      - name: Download build.zip
        uses: actions/download-artifact@v2
        with:
          name: build.zip
      - name: Unzip build.zip
        run: unzip -q build.zip
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.PUBLISH_GITHUB_TOKEN}}
```

[gpr]: https://github.com/features/packages
[npm]: https://www.npmjs.com/
[typescript]: https://www.typescriptlang.org/


NPM Publish to GPR and NPM


About 7 years ago, I started working out. My eating habits finally caught up with me and I needed to change. So I started
working out with a couple different personal trainers over a couple years, I did many off-road obstacle courses including
several [Tough Mudders](https://toughmudder.com/). I started getting bored so decided to train for a full marathon and I
got up to running 18 miles at one time which was meant to be my max training length but I was having lots of pain in my
feet with my left being the worse. My wife got pregnant and figuring I needed to rest (was coming off another Tough Mudder
in Chicago) I stopped running. After a long time, the pain lessened but it never went away. I had to change the way I slept
and I bought myself a medical boot off Amazon for when I would aggravate it.

## First Doctor Visit

In October of 2018, I decided enough of my self healing that wasn't working, I needed a doctor's assistance. Got some
X-Rays taken and was diagnosed with Retrocalcaneal Bursitis and was told to get some heel lifts to put in my shoes and
I could get cortisone shots in my heel and there is a surgical option. Got the heel lifts and went on my way... to not
use the lifts because they were uncomfortable.

Back to self managing I went. I would aggravate my left heel often as I did anything physical it seemed, like re-side my
house and replace all 25 windows. I'd be known to randomly walk around wearing this medical boot and would have to wear
a shoe on my right foot because hobbling around on just the boot was killing my back.

## Second Doctor Visit

Ok, self managing wasn't working. I could get by but I was always hurting and I never wanted to do too much and I have
a four year old that wants to be active and play outside. So about a month ago, back to the orthopedic doctor again
where I got more X-Rays taken (since the others were too long ago) and I was told I had Haglund's deformity. This time,
I asked about the surgery because I'd like to take care of this once and never have to worry about it again. But I was
told the recovery was 5-6 months and he didn't want to go into detail ont he recovery since that wasn't his deal, he
wasn't going to be the one operating or managing my recovery and so I got a referral to their surgeon that was a couple
weeks after.

I wanted to try the cortisone shot out even though it would be temporary, I wasn't sure if I would be getting the surgery
done now since the recovery could be long and wasn't sure what that'd actually mean. I got two shots in my left heel
which hurt like a bitch! Must have been the largest needle they had.

## Surgery Consult

Went in for my next appointment with the surgeon. Nurse took my vitals and luckily my blood pressure was pretty normal
(I tend to have high blood pressure from my lifestyle of not doing anything and drinking energy drinks). Next came in
a PA (Physician Assistant) which did go in depth on what the recovery would mean. Basically, first two weeks would be
non-weight bearing and I'd have a splint in. I'd get that taken out and then spend 4 weeks still non-weight bearing in
a cast. After that I'm in a medical boot for a couple months till I'm back to normal. During the first 6 weeks of
non-weight bearing, I could scoot around in a knee scooter. This recovery didn't sound bad at all, I was quite relieved.

So then I got to talk to the surgeon about the surgery. He asked if there was ever a specific moment that I went from
little-to-no pain to a lot of pain because the back of my heal where I had the extra calcium growth, there was a little
piece that had broken off. He further went in to what he was going to have to do. Since the Achilles tendon was calcifying,
he was going to have to remove about 1.5 inches of the tendon. This means that my Achilles tendon wasn't going to be long
enough so he was going to have to basically supplement it with another tendon. There are two tendons going to your big toe
and the one for the furthest knuckle could be used although this would be I wouldn't be able to curl that toe but I'd still
be able to bend the toe, no biggie.

So the surgery was going to be a bit more involved than I had previously known and the recovery was going to be much
better than I expected. Let's schedule it! Right?

## All Hell Broke Loose

Before I tell you what happened, I'll tell you some more of my history. Two decades ago, when I was a teenager, there
were a couple times I just randomly passed out. Yes, randomly. I didn't have to do bunch of physical things (I was very
active with different spots). There was one time, I stood up, walked over to where my mom was cooking breakfast and next
thing I know I'm waking up on the couch my dad carried me to. I'd be out for 15-20 seconds but when I came to I was all good.
Did bunch of tests (stress test, echo, tilt table, etc) but the doctors never knew what was wrong. I was told to eat more
salt and keep my electrolytes up.

I bet you can guess what I'm about to tell you happened when talking to the surgeon. Yes, I got very hot, started sweating,
got dizzy and passed out. When I came too, I was all sweaty and was told I said a few things I don't remember and I was
out for a couple minutes this time.

Yep, great to be talking to a surgeon about having surgery when you faint. So now I have to see another doctor before
I go back to see the surgeon in a month. Tomorrow I go in to get a monitor I have to wear for 24hrs (may be 48hrs, don't
remember). Then on the 31st I go back to talk to the actual Cardiologist.

## What Is It?

Over the last couple decades, I've had those tests and some followup tests (just had another echo about 5 years ago).
Everything checks out with these tests so I'm not sure what this round will find. I do know each doctor has different
experience and this doctor may have had something similar before, I go along with things and keep a notebook about these
to tell the next doctor. But is it a cardiovascular issue or is it more mental? Are these just anxiety attacks? Course,
the first couple times it happened were in situations where there shouldn't have been any anxiety but there also wasn't
anything that would require lots of blood flow.

Hopefully, when I see my orthopedic doctor next month my surgery isn't delayed because of the cardiologist. If it is,
then ok. I'm really hoping to be back to walking without any assistance by October/November time. I promised my daughter
that we could go to Disney World (which should be reopened by then) and I don't like breaking promises even if there
is a good reason. I also really want to get back to working out and getting on a diet so lots of reasons I want to get
things taken care of.


Health Update


This year has really been the year of [Typescript][typeScript] for me, I've been using is anywhere and everywhere I can. While there are some annoyances, I love it and I didn't think I would. At the same time, I've been using React more and more and on larger projects, using [aliases](https://webpack.js.org/configuration/resolve/#resolvealias) that [Webpack][webpack] provides has been great. When importing files, relative paths could get ugly but with aliases they can be relative to your `src` directory. But when working with Typescript, I didn't have this feature... so I thought.

## Enter paths

I don't remember where I saw it first but I saw that TypeScript has a [paths](https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping) feature. Ok, so this looked very similar to Webpack aliases and in development, it worked. Now instead of this code:

```typescript
import Foo from '../../../components/Foo';
```

I could write:

```typescript
import Foo from '@/components/Foo';
```

And all I had to do is have two things in my `compilerOptions` object in `tsconfig.json`:

```json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}
```

This worked exactly like I wanted... in development.

## First Issue

I call out that it worked in development because I actually published a module to [npm][npm] and it simply didn't work. I'd get an error like:

> Error: Cannot find module '@/components/Foo'

But wait... this code is compiled. Why is it trying to use the path I have in my `import` and not a relative path that TypeScript found? I feel like most people first using paths hit this and the reason is, it's not meant to be analogous to Webpack's alias. TypeScript paths are intended to be used to resolve type information used by various loaders, not resolve just anything. There are a couple GitHub issues for this, here is a link to the first explanation that made sense to me: [#10866](https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-246789510). There is lots of back and forth on these GitHub issues but it sounds like TypeScript isn't going to change things to work the way we want in this case.

## Solution

Not wanting to give up, I found a way around it. I found a [plugin](https://www.npmjs.com/package/@zerollup/ts-transform-paths) that during build, it will rewrite these paths to relative paths so CommonJS style requiring (like [Node.js][node] uses) will work. You can then edit your `tsconfig.json` to use this plugin:

```json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    },
    "plugins": [
      {
        "transform": "@zerollup/ts-transform-paths"
      }
    ]
  }
}
```

Run a build, test the compiled code and you'll still see the same "Cannot find module" error. The reason for this is TypeScript **doesn't** support plugins. So why did I say to use plugins? Instead of using TypeScript directly, you have to use a different project: [ttypescript](https://github.com/cevek/ttypescript). So instead of using `tsc` command, you use `ttsc`. Now run a build and everything should work! Fantastic!

Even though I hate that we have to use ttypescript and even though we are using something in a way it wasn't intended, it works. At least for now. I do hope TypeScript supports plugins eventually. Ok, so it works... or wait, does it?

## Second Issue

I felt like I was on an emotional rollercoaster. I published a version that used paths and it didn't work. I worked around it using other libs and it worked... but then it didn't. I moved a project to a [monorepo](https://en.wikipedia.org/wiki/Monorepo) using [Lerna][lerna] (and [yarn workspaces](https://yarnpkg.com/lang/en/docs/workspaces/)). Each package had it's own `tsconfig.json` that extended from a base `tsconfig.json` and I was using paths in the individual packages. However, when I wanted to import from another package in the monorepo, it couldn't find the other package. The reason for this is each package had the [`main`](https://docs.npmjs.com/files/package.json#main) field set to something like `lib/index.js` as when published, that's what I needed. However, with TypeScript, that `lib/index.js` only exists when you build and during development, it's not likely you'll have that and even if you build in order to get it, as you develop and add/remove files, you'd have to build the package each time. I'm way too lazy for that and it didn't feel like an efficient workflow for me and anyone else working on the project.

So my solution, add TypeScript paths for each package that was going to be imported to target that package's `src` directory in the same way my `@` path works. So an individual's tsconfig.json would have this sort of thing:

```json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"],
      "@somescope/core-pkg": ["../core-pkg/src/index.ts"],
      "@somescope/core-pkg/lib/*": ["../core-pkg/src/*"]
    }
  }
}
```

Now, when one package had an import like:

```typescript
import Foo from '@somescope/core-pkg/lib/Foo';
```

In development, it would then map to `../core-pkg/src/Foo` and work. However, once compiled, that plugin I was using would overwrite the path and have that relative path. Since each package gets published on it's own, that wasn't what I needed. I needed it to leave that import alone but write the `@` path so I wanted to have cake and eat it too. Luckily, that plugin I'm using has a way to exclude certain paths from what it processes. So my base `tsconfig.json` now has this:

```json
{
  "compilerOptions": {
    "plugins": [
      {
        "transform": "@zerollup/ts-transform-paths",
        "exclude": [
          "@somescope/core-pkg",
          "@somescope/core-pkg/lib/*"
        ]
      }
    ]
  }
}
```

And now when it comes across an import matching that path, it simply leaves it alone. Great, this plugin is fantastic!

## Recap

Let's step back and recap what is going on. In development, I can import from the same package or another package using paths to load the TypeScript raw source without needing to build often or using the watch feature. When built, paths to the other packages are excluded and will remain the same after as it looks before, with the module import not a relative import. Great! We're done... or are we?

## Third Issue

Oh geez, I thought we were done except we weren't. Something I noticed when I was building packages, TypeScript was also moving the other packages that we imported into the package's `lib` directory. So once built, the `lib` directory looked like:

```
lib/
  core-pkg/
    src/
      index.js
      ...
  my-pkg/
    src/
      index.js
      ...
```

Notice how the core package and the current package (my-pkg in this case) are there now? TypeScript will compile all the files you imported and move them into your build directory as it thinks you need it... you know, since we aren't using paths how it was intended. So I had a `postbuild` script that I now delete that `core-pkg` directory (using [rifraf][rifraf]) so the `lib` directory looks like:

```
lib/
  my-pkg/
    src/
      index.js
      ...
```

I could move all the `lib/my-pkg/src` files up to `lib` and delete the unnecessary `my-pkg/src` directories so things are more cleaned up but it works and I'm tired of fighting with this so I just kept it the way and updated the `main` field in `package.json` to be to that nested `lib/my-pkg/src/index.js`.

## Fourth Issue

Oh good man why?! Yes, there is a fourth issue. When you are running code in development, TypeScript only loads a single `tsconfig.json` so if you are importing another package that is also using paths, TypeScript simply doesn't know about the paths in that other package. So if both packages are using `@` as a path, it'll try to load files imported by that other package into the package you are running in and it won't find the proper file. And if you changed to a different path in that other package, say `^`, TypeScript simply won't know what that it should try importing the file from that other package because it doesn't load that package's `tsconfig.json`.

Ok, at this point I was done. I was done working around issues trying to get paths to work as something it wasn't designed to. Could you get it to work? I'm not sure, I didn't even look and I honestly do not care. The other package didn't have a lot of files so going back to relative import paths worked and I just went with it.

## Conclusion

After fighting with paths, I decided to not use it. I still have it used in one package that is the "main" package and it has a few files where paths has helped but the only reason I haven't undone using paths is because I'd rather do other things than update 50 files and since I'm not going to use them going forward there just isn't a payoff just yet. I'll eventually undo using paths but you never know, maybe there will be official support. And like I said, you may be able to get something super elegant that works in development and production and it may be beautiful... I just lost motivation myself. If you'd like to see what project I am referring to, it's the [Gimbal](https://github.com/ModusCreateOrg/gimbal) project at [Modus Create](https://moduscreate.com/).

I'm not saying paths are bad just if you're gonna use them in a way they are not intended to be used, expect a bumpy road. And just because it works today doesn't mean that TypeScript will have an update that will break ttypescript and you'll have to wait till it gets updated to work. I doubt TypeScript wants to break things but they also are not obligated to keep it working. So use at your own risk!

[lerna]: https://lerna.js.org/
[node]: https://nodejs.org/en/
[npm]: https://www.npmjs.com/
[rifraf]: https://www.npmjs.com/package/rifraf
[typescript]: https://www.typescriptlang.org/
[webpack]: https://webpack.js.org/


Why TypeScript Paths Failed Me


I love how simple [React](https://reactjs.org/) makes using global state in an application so simple. It's API is simple, predictable and easy to [grok](https://en.wikipedia.org/wiki/Grok) (IMO). You can have as many state providers as you want to separate chunks of state into logical chunks. Let's say you have a simple email application so you could choose to separate loading emails and the address book into separate state providers. The reason for separating it is each thing has different actions to work with the state. For example, both will have the different CRUD actions but how you work with each may require different application logic.

I'm not going to build everything so you'll have to fill in some blanks. What I want to do is how I structure multiple state providers and later we'll add a way to use React Hooks.

## Using Providers

To add a state provider, you add the provider to your `App` component. So you'll have something like:

```tsx
// src/App.tsx

import React from 'react';
import { AddressBookProvider } from './state/AddressBook.tsx';
import { EmailProvider } from './state/Email.tsx';

const App = () => (
  <AddressBookProvider>
    <EmailProvider>
      // the rest of your application or router
    </EmailProvider>
  </AddressBookProvider>
);

export default App;
```

Like I said, you can have as many providers here as you wish. The more providers you have and what the rest of the `App` component will look like (maybe using [react-router](https://reacttraining.com/react-router/)), the more the `App` component begins to grow in complexity. Instead, I like to create a `Providers` component that will wrap all the providers like we see in the `App` component and it will help simplify the `App` component. The `Providers` component will look almost identical to the `App` component:

```tsx
// src/state/Providers.tsx

import React, { FunctionComponent } from 'react';
import { AddressBookProvider } from './state/AddressBook.tsx';
import { EmailProvider } from './state/Email.tsx';

interface Props {
  children: React.ReactNode;
}

const Providers: FunctionComponent<Props> = ({ children }) => (
  <AddressBookProvider>
    <EmailProvider>
      {children}
    </EmailProvider>
  </AddressBookProvider>
);

export default Providers;
```

And now the `App` component would be able to just use the `Providers` component:

```tsx
// src/App.tsx

import React from 'react';
import Providers from './state/Providers.tsx';

const App = () => (
  <Providers>
    // the rest of your application or router
  </Providers>
);

export default App;
```

So now as your application grows and if you add more providers, your `App` component doesn't increase in complexity and nesting, that is abstracted away by the `Providers` component. I know from these small snippets it doesn't show much benefit but in real applications, organizing in proper places can help tremendously.

## Using Global State

Once you have added the state provider to the `Providers` component (which is then bootstrapped into the `App` component), any component can get the state and will re-render whenever that state changes. To do this, the component will use the state context along with the [`useContext`](https://reactjs.org/docs/hooks-reference.html#usecontext) hook:

```tsx
// src/components/Email/List/index.tsx

import React, { useContext } from 'react';
import { EmailContext, ContextArray, Email } from './state/Email.tsx';

const EmailList = () => {
  const [{ data }, setState]: ContextArray = useContext(EmailContext);

  if (!data) {
    // data hasn't been loaded yet
    // maybe show loading spinner
    return null;
  }

  if (data.length === 0) {
    return <div>No emails!</div>
  }

  return data.map((email: Email) => (
    <div>{email.subject}</div>
  ));
};

export default EmailList;
```

Here, we use React's `useContext` hook and pass it the email context. Check if it was loaded, has emails and finally you get to rendering the email list itself. Now if something else, maybe a search field in a header, filters the emails this `EmailList` component will get re-rendered thanks to using the `useContext` hook. This means there is nothing more you have to do to keep this `EmailList` in sync with that email state; it'll just work.

## Email State

Before we get too far, let's look at what our email state context and provider looks. We'll just look at a small example, I won't complicate it by using [`useReducer`](https://reactjs.org/docs/hooks-reference.html#usereducer) even if we would maybe likely use it in this instance just to keep this blog scoped small.

```tsx
// src/state/Email.tsx

import React, { Context, Dispatch, FunctionComponent, SetStateAction, createContext, useContext, useState } from 'react';

export interface Email {
  // more fields...
  subject: string;
}

export interface State {
  data?: Email[];
}

export type ContextArray = [State, Dispatch<SetStateAction<State>>];

export const EmailContext: Context<any> = createContext([{}, Function]);

interface Props {
  children?: React.ReactNode;
}

const EmailProvider: FunctionComponent<Props> = ({ children }) => {
  const [state, setState] = useState<State>({})

  return <EmailContext.Provider value={[state, setState]}>
    {children}
  </EmailContext.Provider>
};

export default EmailProvider;
```

A few things are done here. We have some interfaces to describe the state object and what an email looks like; these could go into your typings directory but we'll keep things simple for this blog. I like to have a type to describe the context array that will be used for `useContext` so each usage can use this one type instead of duplicating the type per usage. The context is created, this is what will hold the state. We create a provider, use the [`useState`](https://reactjs.org/docs/hooks-reference.html#usestate) React Hook passing an empty object.

This is all we need to use state globally in an application. Now I'm not going into how to load the emails or work with them (like filtering to creating a new email), that's just not what I aim to do with this blog.

## Our Own Hook

What we just saw using `useContext` isn't complex, but maybe we can make it a little more approachable. One of my favorite updates to a library I've ever used from any language may be [React Hooks](https://reactjs.org/docs/hooks-intro.html). I love the Hooks api, I have seen them be used in some truly amazing ways. For this blog, let's look at updating our `EmailList` component to use a custom hook and then we'll see how to actually creating the hook:

```tsx
// src/components/Email/List/index.tsx

import React from 'react';
import { ContextArray, Email, useEmails } from './state/Email.tsx';

const EmailList = () => {
  const [{ data }, setState]: ContextArray = useEmails();

  if (!data) {
    // data hasn't been loaded yet
    // maybe show loading spinner
    return null;
  }

  if (data.length === 0) {
    return <div>No emails!</div>
  }

  return data.map((email: Email) => (
    <div>{email.subject}</div>
  ));
};

export default EmailList;
```

Ok, this simple example, not much as changed. Instead of using the `useContext` React Hook, we are using the `useEmails` custom hook we will create shortly. The reason I like doing this is there no longer is a need to import the actual context and pass that to React's `useContext`. We are simplifying separate usages, making the "complex" code appear only once in our code base (our `useEmails` hook) but you'll see, it's not complex at all so it's really only a benefit with no sacrifice.

## Our Custom Hook

To create our own hook, all we need to do is add this bit of code to the end of `src/state/Email.tsx`:

```tsx
export const useEmails = () => useContext(EmailContext);
```

So you can see, our hook really just does the `useContext` for us. It's not a huge savings here but it is something I do enjoy. Small wins are still wins in my book!

## Conclusion

This blog only shows some small wins but sometimes small wins have large impacts. Maybe it's from my time working on Ext JS but I tend to think about how I can abstract away duplicate code. While sometimes that abstraction can lead to other issues (like performance), the two things I showed in this blog, the `Providers` component and `useEmails` hook, have only been a good thing for the React projects I've worked on.


React State Provider with Hooks


I've had my personal blog since 2011, the year my career sort of took off. I self hosted [Wordpress][wordpress] as it's the de facto blog platform (at least at the time). There were lots of plugins, lots of blogs saying how to use it. It just worked.

At the end of 2014, I moved from Wordpress to [Ghost][ghost] and wrote a [blog](/2019/07/26/move-to-github-pages/) saying why I did it. There was some help migrating between the two and I was all about using [Node.js][nodejs]. However, the version I was on meant upgrading was a pain and eventually I stopped upgrading Ghost. I was stuck on an old version (like v0.11.x) and so I decided to rethink my blog. I want to blog more so I wanted something that felt good to write on, a blogging platform definitely shouldn't get in my way.

With Ghost, I was using a Let's Encrypt SSL certificate and I was too lazy to setup a cron to get a new certificate so I'd ssl into my serer and manually update the certificate. Manually updating the certificate was annoying but not annoying enough to take the minute to setup that cron... crazy!

## What I Was Wanting (Technically)

It's no surprise that I've been getting into [React][reactjs] lately and wanted to move to using a CDN and static pages. No more having a platform that had to do database calls, unnecessary for what my blog is. So I decided to give [Gatsby][gatsbyjs] a look. I write in Markdown, I can write components using React, and the pages are built and those static pages can be deployed. Even though I wasn't paying [DigitalOcean][digitalocean] much monthly, my static site could be deployed to [GitHub Pages][githubpages] and I could put [Cloudflare][cloudflare] in front of it.

Basically, what I was deciding was perfect for what I wanted for this blog and saves me some money.

## DigitalOcean

By no means was I unhappy with DO. In fact, I love the company. I love their tutorials. I love their new control panel. I love the new features they've been rolling out. With my Ghost blog, I've had no problems. So moving away from DO was only because I didn't need to have a server always running for a static site. They do have a [newer service](https://blog.digitalocean.com/introducing-spaces-object-storage/) called [Spaces](https://www.digitalocean.com/products/spaces/) where I could host a static site with a CDN so I could have stayed with them... except that it does cost and what I could get from GitHub Pages, I don't need to pay.

## Cloudflare

Cloudflare is an amazing company with amazing products. For me, it's a huge CDN, gives me lots of controls over what is cached and what I can invalidate, a full API (if I need it) and for my blog it's free. Cloudflare would also manage the SSL certificate for me so no laziness on my part!

## GitHub Pages and CircleCI

I absolutely love how simple GitHub Pages is as a concept. Basically, your files in a repo is hosted for you... easily. I'm all about setting up CI/CD pipelines for everything so all I have to do is write some content and push to the repo. I have [CircleCI][circleci] automatically build and deploy for me. Building is simple with Gatsby and deploying is done with [gh-pages](https://www.npmjs.com/package/gh-pages). It's just all easy and free and automated.

## Gatsby

This is the only thing I haven't used before. The rest of the stack is all familiar to me. And what I have with Gatsby is a starter, I still need to do some things like styling but I wanted to get something deployed. I made sure to keep the URLs the same so any linkage from external sources plus SEO is persisted.

Gatsby does have a plugin to get blogs from Ghost but since I was on such an old version and the API was in beta with no tokens, didn't look like the plugin was going to work. So I spent a couple hours, copy and pasting from my online Ghost to local Markdown files... manually. But now that I have files locally and if I move to something else, I can at least easily script something to migrate. I was so tired after the manual "downloading" and I'm sure there was still ways to do this without me manually doing it but some times the long way isn't actually the long way. Could I have figured out how to do it, write scripts myself or whatever was going to be needed within the couple hours it took me to do it manually? I wagered no and I feel like it was the right decision.

With Ghost, I had to host images in an external service and tbh I don't remember what that was. With Gatsby, I can link to it in my Markdown and since GitHub is my host my images are right there, nothing else is needed.

The one thing that is bothering me is the index page shows all the blogs in one list. I want to get pagination going and Gatsby does have plugins for this but wanted to go ahead and get this going.

## Conclusion

My new stack, while not finished, is just easier for me to work with... and free. I will continue to update this blog to get it styled and I'll be trying to get back to actively blogging. Best way to let me know what you'd like me to blog is via [Twitter](https://twitter.com/LikelyMitch)!

[circleci]: https://circleci.com/
[cloudflare]: https://www.cloudflare.com/
[digitalocean]: https://www.digitalocean.com/
[gatsbyjs]: https://www.gatsbyjs.org/
[ghost]: https://ghost.org/
[githubpages]: https://pages.github.com/
[nodejs]: https://nodejs.org/
[reactjs]: https://reactjs.org/
[wordpress]: https://wordpress.org/


My Move to GitHub Pages


Let's get something out before I start. Yes, I am an ex-employee of Sencha. No, I was not laid off (I left on principle seeing the knowledge of the company and friends get laid off). Yes, I have been critical of Sencha since the acquisition but this is something I've been doing internally for years so nothing new there.

## Quick History

One of the necessary evils of the early 2000s was that JavaScript was really just a kid. You couldn't do any real OOP like many languages could do for years. I come from a PHP background and had been using classes for a long time, I liked that type of programming. When I started dealing with JavaScript I had to do functional programming which worked and you could do what you need to but I always enjoyed my classes in PHP. It just felt structured to me.

When I found Ext JS, not only did it have some great UI widgets but it had a form of OOP, it had a class system. Under the hood, all it was doing was using `function` with the `new` keyword and `prototype` to get that inheritance. So it was kind of a workaround to no classes to create a "manual" class system if you will. I love it and devoted the next decade to it!

## Old Mistakes

With the renewed interest in furthering JavaScript the language, we now have classes. We have a lot of new things that Ext JS did manually (and in early days even applied onto native prototypes, thankfully we got away from that!). When we created the ExtReact, it was just an adapter layer. ExtReact is not a true React component library, it's just a way to let Ext JS render a component somewhere in your React application.

Ext JS isn't alone in this but when React and other came onto the scene, Sencha was not prepared for it. We were fixing massive issues that Ext JS 4 brought. We were caught with our pants down, we were simply standing still while the entire ecosystem upended and ran right past us. To catch up, we needed to do more than incremental updates or else Ext JS was going to be destined for the legacy bin.

You can look at things like Google Trends but in my own experience, in 2012 my primary job was helping people on Sencha's forum and at my busiest month, I did almost 4,000 posts in a single month just trying to keep up. The community was vibrant and passionate. Look at the forum these days and you will see something vastly different. I wouldn't be surprised if there wasn't 4,000 posts total in a month let alone from a single person.

## A Fix

One potential fix would have been to create true React (and other) component libraries. Let React do what React does best, render fast. Ext JS doesn't do optimizations that things like virtual DOM do. Sure, there are some optimizations but that's no where near what virtual DOM would get you, it's more a little attempt to batch or delay certain things but it can also require the developer to code correctly whereas React basically just handles it for you. The only time you need to code a certain way is to do some advanced fine-tuning since not everything can know exactly what you want to do and how to handle it. Luckily, there are vibrant communities around React and other new libraries/frameworks.

But doing a massive restructure of Ext JS would be a major undertaking for a monolithic company like Sencha which made certain execs not buy it. They have a board to report to so I can understand the short sighted sense of those decisions but there are also ways to piece meal a lot of it. Maybe it was because a sale was more preferred so revenue and margins were looked at differently than if a company was going to invest in it's own future.

## Today's Mistake

I saw a [blog](https://motivationalcodepro.com/sencha-npm-tooling-with-ext-js-6-6/) about some new npm tooling and while you have to be a special MVP to get access today, there were some code snippets the blog showed. And once again, instead of using tried and battle-tested existing tools that have active communities they chose to build their own thing. It looks to be built from scratch so a perfect time to do it using existing tools.

One example showed generating an application. First, some constructive feedback for the blog author is that showing a long command in multilines would help readability as the command is over 300 characters long (maybe it was just a command that is missing the special code formatting so it's all thrown together). Here is my best guess at the nested nature of the command:

```sh
ext-gen \
  app \
    –template universalclassicmodern \
    –classictheme theme-graphite \
    –moderntheme theme-material \
    –name CoolUniversalAppext-gen \
  app–template classicdesktop \
    –classictheme theme-graphite \
    –name CoolDesktopAppext-gen \
  app \
      –interactiveext-gen \
  app \
    -a \
    —classictheme theme-graphite \
    -n ClassicAppext-gen \
  app \
    -a \
    -t moderndesktop \
    -n ModernApp
```

So there is an `ext-gen` tool that likely downloads (and maybe caches to local) templates from a GitHub repo (since Sencha uses GitHub with lots of private repos) or maybe from the customer only npm server. Just feels like Yeoman or the like could have done this. Honestly, this doesn't give you much as it's a command you execute at the start of a project and never against for that project so whatever.

Another example is building an app where the generated app likely has some predefined scripts in it's `package.json` that you can run things like `npm run build-desktop-testing`. Unfortunately the blog doesn't show what is being used here as the script could even use Cmd:

```json
"build-desktop-testing": "sencha app build testing"
```

Or it could use a new tool or just the Cmd NodeJS wrapper. If it's just a Node wrapper that executes Cmd commands for you then it's no better than using Cmd by itself except you get to run Cmd commands a different way. It's like using promises over callbacks, it's still just a callback-hell just different and maybe prettier. If it's a new tool altogether, I'll be pleasantly shocked and will attempt to be the first to congratulate them but it's still wouldn't be a perfect solution. It's still reliant on Ext JS development and with Ext JS being on it's own tiny island not using the better libraries, the tooling can only do so much. For example, I talked about ExtReact not being a true React library and neither is it's build tool. There is a Webpack plugin but it still uses Cmd under the hood but at least it allows you to use Webpack and not have to worry about Cmd. It at least tried to use what people want to use and not forcing a black box tool.

## Suggestions

Ok, so I outlines some issues I see coming down the pipeline. If I were to have a wish list, I would love Sencha to follow Ionic's path with web components. Ok, I just contradicted myself as going with web components wouldn't make Ext JS a true React library like I said Ext JS should be but this is a wish list and this would be my top wish list item... one code base could work with or without another library but could seamlessly work with any library without any adapters like ExtReact (and the future ExtAngular and others) will use. But that won't happen, however, it could have an adapter layer to get you web components without separate adapters for each new library you want to support, in fact I was playing around one day with this [fiddle](https://fiddle.sencha.com/#fiddle/1u8k) to prove a point internally.

Past web components, properly abstract the rendering of components so that you could use React or alike as the rendering layer of a component. That means Ext JS would sit on-top of other libraries like React that can handle the DOM much more efficiently.

Once you do some things with Ext JS, you can then use tooling that people want to use. You gotta stop wasting time getting new tools and force them on people. That's not what the field wants these days. They want to use what they know so if someone loves Webpack or Rollup, enable the devs instead of forcing something on them. You'll likely turn them off of everything including Ext JS.

Should I say something about going with modern toolkit at the very least here? If you do none of the above, modern toolkit has much more promise than classic toolkit. Don't walk backwards, you'll never go forward.

## Conclusion

Yes, I have been critical of Sencha and Idera but it's nothing I haven't been doing internally for years. These things I say here have been the same theme of what I've said for years internally. I firmly believe if you aren't willing to do major surgery (or figure out how to do it in phases) then you will get left behind in this field. Every major framework/library that has rose to the top has fallen. Some like Ionic are trying to keep innovating to keep up and even push the tech forward (come on web components, you've been a promise for years but we are so close!). Some like Dojo have even gone under the knife to try and stay relevant. Even the mighty React doesn't have a promised future. Ext JS is the tech of last decade, not the current and definitely not the future. If you want Ext JS to be around 10 years from now then you have to make some wild decisions and get experts to deliver on those.


Sencha Making The Same Mistakes


It's been a little bit since I [left Sencha](https://mitchellsimoens.com/next-chapter-in-2017/) and while working here at [Modus](https://moduscreate.com) has been great so far, there is still something I miss about Sencha. I worked at Sencha for almost 7 years and I did quite a lot of stuff during those years but there is one thing that I can say I miss...

[Sencha Fiddle](https://fiddle.sencha.com/) was something that was never officially announced but people just started using it. It was an application that I **owned, maintained and furthered**. I was able to do things with it (both front and back ends) that was able to push me, make me learn new things and truly enjoy. If I had it my way, I have solely worked on it but of course it didn't make money so I had to earn my salary other ways. Fiddle was also developed to streamline our internal processes but had obvious external usages such as support sharing code with a customer or someone helping someone else on the forums.

## Fiddle 1

In version 1, it was an [Ext JS](https://www.sencha.com/products/extjs/) 4 application that was served with PHP/Apache. At this time, there were many different departments within Sencha that was wanting to use Fiddle but for their own purposes so I architected it so features that were not part of the core app were [Sencha Cmd](https://www.sencha.com/products/sencha-cmd/) packages. This way, I could produce separate builds for these separate installations and include only the features they wanted. This seemed great and having Fiddle accepted everywhere was great. For example, training has it's own portal and code challenges that have to be run and of course that uses Ext JS so Fiddle was a no-brainer idea to be recycled.

## Fiddle 1 Issues

Fiddle 1 was a big success both internally and externally even without being officially announced. In fact, the first time it was seen was Don Griffin using it at SenchaCon 2013 in Orlando where we "launched" it. But, with every 1.0 release, there are certain things that are going to come up as not working or could be improved and you should always be open to some criticism (hopefully it's always constructive).

First up was the infrastructure. When Fiddle 1 was first released, the IT department was being remade. I can remember even the main webstack going down every time a newsletter was released because of all the extra traffic (I jokingly said the newsletter started DDoS attacks). Mike Estes took over the IT department and together (mainly him but I tagged along and learned some DevOps along the way) we turned to AWS Elastic Beanstalk to have an infrastructure that could scale with the demand. Only time I've seen things go down is when AWS has gone down or I checked in code that threw server errors but that's not the infrastructure's fault.

The way Fiddle ran it's code was all local, it basically threw all the source together and ran it. This worked unless you did some common things that made it not work. And if you wanted to load data (which you often want with a grid), the mock data requests magically happened but there was no way for you to see it.

The layout of Fiddle wasn't very pleasing and I had many people that outright told me they hated it. I get it, I'm an engineer and engineers aren't always the best at design. I focused on what worked, not too much how it should work.

## Fixing Issues

I could have let the new infrastructure run the existing PHP codebase but at the same time I was working on a new support portal that was also using a PHP codebase. There were obvious common things so I decided to take a large leap and trash the existing code and develop a new [Node.js](https://nodejs.org/en/) codebase since at the time Node was really starting to get a lot of traction (wasn't the 0.x days now!). Fiddle and the portal was now hosted by a Node server each but that was more used as an http server and for fiddle some extra things we'll get to in a bit. The actual CRUD and login was powered by an api server. This api server opened up a lot of possibilities. I can say, all the Node servers vs the PHP servers, the Node servers are much more performant than the PHP servers and saved the company some money (except the old PHP servers are still running to host some legacy apps). Plus, my node modules were built with all the new ES6+ syntax to allow me to keep up to date on it too.

Fiddle 2 decided to refactor the way code ran and used **real** network requests. This changed everything! Now your xhr requests can be inspected in the browser dev tools, you can require classes and other things could run arbitrary code on Fiddle. Like the training portal I mentioned earlier, the api documentation uses Fiddle to run the code snippets. I did't have to have separate Fiddle installations in order for other apps use Fiddle anymore which is definitely a win on many levels!

Luckily, going through some designs with the portal allowed me to create a common Cmd theme that could be shared among my projects, Fiddle being the first one. The design process with the portal was incredibly frustrating. The first design was said to be the future design Sencha tools were going to use. Then, I started seeing other tools using other designs, ok. I went through many complete redesigns that delayed the portal's release for over a year and there are people still not happy with it. These weren't just simple color changes, complete layout changes which take time to implement and gives opportunities for me to be put on other projects that needed help. Fiddle 2 got wrapped up in the design as it also changed in a dot release. But, the layout of things was much better and was a bit more familiar to any modern editor users.

## Pre 2.0

I was working on a few things that I actually scrapped.

First was a mock data inspector which was basically what you have in the browser dev tools but worked with the client mock data feature. This was removed since I moved to using real network requests but I was very excited about this! Here is a preview of what it was:

<iframe src="https://player.vimeo.com/video/121247419" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

I also had a form of Sencha Test before Sencha Test was a thing. It could record the user interactions and play them back while running unit tests also. Here is a simple test of it:

<iframe src="https://player.vimeo.com/video/121037209" width="640" height="360" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

## New Stuff

There were many things that I did just because I wanted to. I mean, I was a major user of the tool also and there were things I wanted that others wouldn't want. For example, did you know in the settings you can control where code was run? You can have it open a new tab or window and run code within it which allowed for device emulation and multiple monitor support (if you know me and my workstation, multiple monitor support is important). In fact, this affected how code was run also. When you press *Run* in Fiddle, it's the same exact thing as when the code snippets is run in the api docs! Any site can run code against Fiddle, I don't block non sencha.com requests iirc.

Since Fiddle uses real network requests, you can actually load code from one fiddle in another fiddle. I've had a base fiddle that had common code and just loaded those like I would in an Ext JS in other fiddles. This was more of a byproduct of how code is now running but it turned out to be handy.

## What Could Have Been

I had many future things I felt Fiddle could do that was prevented after my exit. The one thing that **could** have had a huge impact on the Ext JS ecosystem was what I called **FU** (**Fiddle University** with a fun acronym). Knowing that learning Ext JS at any stage is hard. The api docs and guides were much better but there wasn't an in-depth, guided training. I also felt Sencha's official training wasn't the most comprehensive, advanced labeled courses weren't very advanced but I have only attended one when I was there to help the students before a SenchaCon. So I was going to create a guided lesson plan that had code challenges and if management liked it, could have had videos that paused while a code challenge was waiting to be passed. You would write code by hand, run it and when ready submit it and there would have been different tests that would be run to provide a score. Get a good enough score and you could continue. I could have seen this provide huge value to the community to help new people to even more seasoned developers. And yes, I know, I would have likely killed training with it but it's not like training bringing in a ton of money.

Not that I was happy but there was a brand new theme that I believe Sencha Themer was the first to use that business wanted Fiddle to use. However, it wasn't created in a way that was sharable for other apps to use so I had to start my own. Then I found out the designer had started one and Sencha Test also had one. You can imagine my immediate frustration seeing four different people working on the same thing but this was common around Sencha too. There have been a few times where I thought, "I see this thing will be used in different things, let's create a reusable package/module!" but then get friction since people love doing things their way, but I digress. So I refactored Fiddle to use my new theme and it looks pretty good, I like it better than the overly white one. If you'd like to see it, looks like it's still up on the [test server](https://test-fiddle.sencha.com/). But I still heard bad things about it and it's hard to please everyone. There were a couple that likes a light theme but some like a dark theme and more and more apps allow you to pick one, I was going to work on that!

Depending on what else was going on, I was also going to migrate to use the modern toolkit which I thought would be great to say since Sencha was wanting to push the modern toolkit on people. This could also be an opportunity to clean up the code as there is always a better way and I'm sure there are opportunities there.

There was code in Fiddle that allowed you to write code on a computer but when you press *Run*, it would run locally (which could be disabled) but it would also run on remote browsers at the same time. I thought I had a video showing it but I had an iPhone, an Android tablet, iOS Simulator, Internet Explorer on a laptop among other browsers on my MacBook and the Windows laptop connected to my Fiddle session I had with Chrome on my MacBook. Press *Run* in Chrome and all connected browsers started running all at once. This was pretty cool and worked great locally except I ran into an issue when deployed as since I was in a load balanced environment, I had sessions saved one one server which you can imagine didn't work. So I made a `TODO` to circle back to use something like Redis where I could pub/sub or use some other messaging service. It really was pretty cool to see everything reload!

Fiddle has always been the tool that pushed the Ext JS Router and since I was also the developer maintaining the router, I was going to finally embark on a new, declarative router that could have changed Ext JS development. Big words but I had lots of ideas that I felt could have made Ext JS better. Plus, we were on the verge of working on Ext JS 7 and having the router much more integrated throughout Ext JS to make things just work with minimal configuration would have been a perfect opportunity. And Fiddle could have been the tool to keep on testing these ideas in production (each version of fiddle has lots of overrides to add features to the router, it's not using the out of the box router).

Quickly, some others were going to be an example redux (Fiddle could replace [examples.sencha.com](http://examples.sencha.com)), named fiddles (so you could go to fiddle.sencha.com/#basic-grid and it'd load the associated fiddle) and I was going to get the KitchenSink to be built from individual fiddles.

## Conclusion

Ok, a trip down memory lane was fun. Fiddle allowed me to push myself to build a tool used by many peers to make their work lives better. I can remember my first Monday as a non-Sencha employee starting work was odd and it wasn't just because I was no longer at a company I had spent a ton of hours at... it was because of Fiddle. I loved working on Fiddle, I loved dreaming about what Fiddle could be or the different ways I could do things. There are projects that you do and kick ass on, but then there are projects that you absolutely love. If there was one project I defined myself while at Sencha, it was Fiddle. Not having access to the code so I could keep working on it to make it better makes me sad. But, like anything in life, there will always be another project to fall in love with.


What I miss at Sencha


This last weekend, my wife and I decided that we wanted to take our daughter (who is 21 months old so almost 2 years old) to a pumpkin patch. And not just pumpkin patch, a legit one where we walk out into a field and cut one off the vine. We didn't want to just go somewhere like a church who has a bunch of pumpkins they got shipped in and set out on a field. So we Google'd and found one that was about a 30 minute drive away and had other activities like a hay ride and a corn maze. Fantastic! And before getting to the story, the end result was we had an amazing time. We got 5 pumpkins, bunch of pictures and some really great strawberry lemonade! And let me apologize if I start rambling and get off subject, this post is very emotional to me in a time where I am constantly emotional about my surroundings.

Where we live is Northern Florida (Gainesville, home of the UF Gators) and it gets country real fast here so driving 30 minutes we got to gravel roads and such. No biggie, I grew up driving on dirt roads but one thing I really hate is seeing all the Confederate flags people fly here. Why is that important? I'm white, my wife is black and therefore my daughter is mixed. Seeing these flags all around (and in town too) makes my wife uneasy which makes me uneasy.

On our way, we were just a couple miles away from this farm, when my wife said something that really upset me. She said, "I don't know about this, I don't feel comfortable out here. It really sucks that we don't feel comfortable going somewhere." And she's right, it does really suck so I told her since we are almost there that we should drive up to it but if she isn't comfortable, I won't turn in and we'll go home. This is something I hadn't had to deal with myself until her and I started dating almost a decade ago. And it's not just in our heads, we've gotten a lot of stares with disgusted looks (maybe they all have resting bitch face maybe?) and we have even been yelled at (can remember walking down town St. Louis and a chick yelling at me that I should be ashamed of myself).

And now we live in a town in the south where in a couple days an extreme racist (Richard Spencer) is going to give a speech just a couple miles away. We are in a state that has a motto of "The Sunshine State" but is very liberal with gun laws so it's nicknamed "The Gunshine State" and people flying the Confederate flags are definitely the kind that love their guns and would go down fighting if anyone tried to take them away. So we are in an area where we have armed racists that aren't shy at being racist towards us.

Before I got together with my now wife, I didn't have to deal with this. Since I never saw it (I lived in Missouri in an area that was predominantly white) it didn't exist. So it's shocking to me that in 2017, racism is still a big thing. And to make matters worse, we have a president that is ok with being racist and religionist and even sexist which only emboldens those groups. So now I live in an area where people feel like it's ok to be racist. So when people tell me to give Trump a chance, I'm sorry but you don't understand a lot of what goes on even if you think you do, you don't. I don't think I wouldn't either to be honest.

There was a story my wife told me that this young kid, who was mixed, was walking and a few teenagers in a car started following him and yelling racist things at him. Luckily it was just words but that does leave scars and here I sit, a father of a mixed little girl who's favorite phrase is "Thank you." I fear for her, I fear she will have this adversity that I never had to deal with, never thought of. This is the world these kids are having to grow up in and it's not a southern regional thing, it's everywhere! It's like my daughter has to win the lottery just to grow up without being attacked (physically or verbally) and that's no way to live.

I don't think a lot of my friends and family think about this and still support Trump with how he is, how he doesn't denounce outward racists. I know they only want us to be happy and I'm sorry to relate this story with Trump but he is seen as the President of the Racist States. You have no idea the mental drain we are always under when we go out together and that's indefinite.

How would you like to walk around where you have to look at people to see who is a threat? There was a time in a grocery store here where we were in the produce. I had my daughter in the cart with me but my wife went away to grab something. A white male approached her and he looked like he had a few screws loose. I see that and my eyes don't leave my wife, my hands did not leave my daughter and I started going to my wife as quickly as I can. I have to treat people like they are guilty until proven otherwise in the produce section because the one time I don't could just mean something happens. I'm not exaggerating this, we get looks and comments made towards us. Maybe I'm overreacting, it's possible but I'd rather overreact than under-react and let something happen.

So before you say that racism isn't a thing, it very much is and this is a white guy saying this about white people. Making racist jokes even if they are only joking is still racism. Saying certain words even if it's not in hatred is still racist. If you see racism, it's not ok. You should always stop it if you can. There is no ok if you do not condone racism. If you voted for someone that is racist, you support it; there is no, "I support other things but not his racism."


Interracial in 2017


About 10 years ago, I was a lonely developer that was creating small web sites more as a hobby, I wasn't getting paid much by some of the people I was developing for. This was ok at the time as I needed to get different projects under my belt but I was using [PHP](http://www.php.net/) and some libraries such as [Prototype](http://prototypejs.org/) and [script.aculo.us](https://script.aculo.us/). Then I saw [YUI](https://yuilibrary.com/) and then this thing called yui-ext and started moving all my development onto it. Eventually, it moved on to be called Ext JS and my life was forever changed.

### Sencha

Today marks my last day, I've spent almost 7 years with Sencha and have met some amazing people and have done amazing things. Quite simply, the best group of people I have worked with. Looking at myself then and to today's Mitchell, I can see a lot of changes and this was largely due to the people who have helped and mentored me. In my tenure at Sencha, I've served many roles from the professional services team to support, marketing, core developer and even IT team. Each team has always taken me in and helped me in more ways than they will ever know. I truly cannot thank these people enough and count them as lifelong friends (if they can put up with my hashbrown jokes). In fact, there were a couple people that I have met through working at Sencha that were in or attended my wedding.

I've also been able to meet a lot of great people both in person and online from the community. I have seen a lot of growth in my dev relation skills; being challenged all the time may not be fun but I've come to appreciate it and see ways to benefit from these encounters. I'm just short of 40,000 posts on the [Sencha Forum](https://www.sencha.com/forum/) and I hope some of them posts have and will continue to help people.

Also, I hope [Sencha Fiddle](https://fiddle.sencha.com) continues to be updated as new releases are released. If I had to pick one thing from Sencha that I'm most proud of, it's Fiddle. Fiddle has done so much to help both Sencha employees (collect bugs, provide examples to developers) to the community and I hope it continues to provide the a great benefit.

### My Future

As fate has it, when this acquisition was announced publicly, I saw a [tweet](https://twitter.com/ModusJesus/status/903352348700966912). So I brushed up my resume (which a free GlassDoor resume review told me to just rewrite it) and applied to [Modus Create](https://moduscreate.com/) along with more than twenty other jobs I found while looking around. While I was one of the lucky few that were not being laid off immediately, I thought this may be the time to look for an opportunity where I can continue to grow and spread my wings and going through Modus' interview process I was granted an offer and have accepted it. I had to make a tough decision as I was in the middle of two other interviews and their coding challenge portion of the process but I felt Modus would give me the greater chance to grow more as a professional. Basically, it boils down to I've been doing one thing for over a decade and it's time for a new challenge.

So on Monday (September 25, 2017), my new endeavor with Modus Create will start. One chapter is closing and a new one is starting. I'm very excited to be looking at a new challenge, challenges have been the fuel behind my growth and I see nothing but positive things ahead. I will not be working with many of my Sencha colleagues anymore and that makes me feel very sad, this change is bitter-sweet, but I know I'll still be in contact with them and they will go on to do more amazing things. This makes me very excited to see them conquer their own challenges. If they ever need me, I'll always be right there for anything they need.


Next Chapter in 2017


If you know me, you know that the router is very important to every application I build. And like every iteration of Ext JS' router, [Sencha Fiddle](https://fiddle.sencha.com/) is the application that has the most contribution and the most experimentation (Sencha Fiddle has a custom router with overrides to add new features to the Ext JS version it's using) on the router. Once again, with Ext JS 6.6, Sencha Fiddle exposed some features that would be great but it's also talking to the community that has provided many improvements as well. I want to talk about four new features that have landed in 6.6.

# Exit Handler

This feature came from a community member ([LesJ](https://www.sencha.com/forum/member.php?210320-LesJ) from the Sencha Forums).

There are many times when you create things in response to a route being executed that you may need to cleanup. For example, you may have opened an [Ext.window.Window](https://docs.sencha.com/extjs/latest/classic/Ext.window.Window.html) but when the route is executed, you need to close that window. So in your `action` handler, you create the window and likely cache it somewhere and when another route is executed you check to see if any windows are shown and clean that up. Ok, not the end of the world but this means code starts to get ugly and brittle and you start engineering things where Ext JS could make this easy.

With Ext JS 6.6, we are going to make this easy with a new `exit` handler and the use of it is just like the `action` and `before` handler:

```js
routes : {
    'foo/bar' : {
        action : 'onFoo',
        exit   : 'onExit',
        name   : 'foo'
    }
},

onFoo : function () {},

onExit : function () {}
```

So now your route can handle when the route no longer recognizes anything in the hash. Internally, each route keeps track of the last token it was executed on which allows it to know if it was being exited which is needed if you use multiple tokens as is the case in my apps like Sencha Fiddle.

# Single Routes

This improvement comes from a need for Sencha Fiddle.

At the start of Sencha Fiddle (and the support portal) I have to check user session and I also wait for certain stores to load before I want to continue with showing views and such. Currently, I have a global route with a before, here is a small example:

```js
routes : {
    '*' : {
        before : 'onBeforeGlobal'
    }
},

onBeforeGlobal : function () {
    return new Ext.Promise(function (resolve, reject) {
        // check if things have finished loading
    });
}
```

I have an array of stores I go through and check if it has [loaded](https://docs.sencha.com/extjs/latest/classic/Ext.data.ProxyStore.html#method-isLoaded). However, I felt like this was wasteful because it's going to check if these stores are loaded for each route as the `*` wildcard route fires before all other routes; I only needed it to check upfront. Taking a page out of the Observable listeners where you can pass `single: true`, routes will be able to define their singleness:

```js
routes : {
    '*' : {
        before : 'onBeforeGlobal',
        single : true
    }
}
```

Tough syntax huh? This will remove the route from the router after the `before` and `action` handlers have been executed. Once removed, the route will not longer be connected and will not execute anymore. Perfect!

Or is it? Why wait for a full, successful execution to remove the route? Why not always remove it? Knowing that all applications (or developers) do not have the same requirements, we decided to give a bit more control and so the `single` option can also accept `'before'` and `'after'`. These string values are about when to remove the route.

`'before'` will remove the route before the configured `before` handler is executed. This means the route will always get removed regardless if the `before` action is resolved or rejected.

`'after'` will remove the route right after the `before` handler has been resolved but prior to the `action` handler to be removed. This can be seen as very similar to the `true` value since the `action` handler cannot be stopped (assuming to errors occur), however, the difference is when you have other routes that have a `before`. Those other `before`s may reject which would then not execute our single route's `action` handler from executing which means the route would not get removed.

Kind of hard to grok fully from just text so I'll try another way of explaining it. When you defined the `routes` config, it will actually only create one route instance matching the route name (or pattern) and the `before`/`action` handlers are then added to that route's `handlers` array. So when a hash changes, it finds the matching route instance and then executes it. It creates two arrays: the `before`s and the `action`s. Execution will go through each before in an async stack (each before has to resolve before moving onto the next before) and then it will go through the action stack. So there are three insert points on where the route can be removed: beginning of the before stack, within the before stack after the matching `before` action, and on the end of the action stack. So it's very important to know when you'd want the route to be removed in that execution but the main point is whether to wait for a `before` or all `before`s to resolve.

We picked `true` to remove on the end of the action stack but are still discussing whether it should go on the beginning of the before stack so these values may change. This will be documented in the API Docs when 6.6 is released so I would recommend checking the final docs. Also, comment below if you feel strongly about this. I'll even see if I can create an example and/or image to show this a bit better, I'm still trying to find a great way to explain it with so many duplicate terms.

# Lazy Routes

This feature came out from the [coworkee app](https://github.com/sencha-extjs-examples/Coworkee) that was developed internally among some posts on the forum.

One issue with using routes in ViewControllers is that the ViewController may not be instantiated when the route was already executed. I personally don't spread routes around too much but people have been asking for this and it was easy to implement so ok. People asked for the routes defined on their ViewController to execute if it matches a current hash. We are calling this `lazy` and it can be defined like so:

```js
routes : {
    'user/:id' : {
        action  : 'onUser',
        lazy    : true,
        name    : 'user'
    }
}
```

This means, if the hash is already `#user/1234` when the ViewController is instantiated, this route will execute.

I'm personally not a fan of defining routes all around my application but I do see some value it in since I've built some heinous enterprise UIs and routes may only update a portion of the screen not simply swap out what view is in the center/content region.

# Named Types

This feature came from a mix of things from Fiddle to support tickets to a conversation between Don Griffin and I. This feature also aims to fix two different problems.

Ok, I teased this on Twitter and here is what this was about.

The first "problem" is people currently have to define custom matching RegExp strings to control the format of a url parameter. What I mean is say you have a user route that accepts an ID but that ID will only be numeric so you can define it as such:

```js
routes : {
    'user/:id' : {
        action     : 'onUser',
        name       : 'user',
        conditions : {
            ':id' : '([0-9]+)'
        }
    }
},

onUser : function (id) {}
```

Now, this route will only execute for hashes where `:id` is numeric such as `user/1234` but will not execute if there are other characters such as `user/1234abc`. One important note to make here is the [defaultMatcher](https://docs.sencha.com/extjs/latest/classic/Ext.route.Route.html#property-defaultMatcher) of a route is `([%a-zA-Z0-9\\-\\_\\s,]+)` so it will accept a few different characters that you may or may not want.

My initial proof of concept had a syntax such as :

```js
routes : {
    'user/:num' : {
        action : 'onUser',
        name   : 'user'
    }
}
```

And that `:num` would automatically use the `([0-9]+)` RegExp. This is pretty simple right? The issue with this syntax is what if you had a `:num` parameter in a route but didn't want that exact RegExp? There was also `:alpha` and `:alphanum`. The chance of collision here was very tiny but if you were one of the unlucky people that would have a name conflict, it likely would be a silent failure and you'd find out about it in production which is not good at all. So we discussed how we can prevent this and a couple different ideas came up like `:$num` or some character to signify this was to be treated as a named type. But we decided on this format:

```js
routes : {
    'user/:{id:num}' : {
        action : 'onUser',
        name   : 'user'
    }
},

onUser : function (params) {
    var id = params.id;
}
```

So we surround the parameter name and type in curly braces. Quick note, the type (`:num` in this case) is optional so you can have `:{id}` and the `defaultMatcher` will then be used. Other default types are `:alpha` and `:alphanum`. Also, for `:num` and `:alphanum`, numbers will be cast using `parseFloat` so you can have `#foo/10.4` and 10.4 will be a float instead of just a string.

Also notice in the `onUser` we have `params` which will be an object and the parameter names will not be the key of that object. This was another of the problems where having separate arguments in the functions could get a bit wildly and it can be a good rule of thumb if you have more than 3 arguments, an object will be more friendly. So if you use these new named typed, an object will always be passed to the handlers.

We have some detection if you reuse a param name, an error will be thrown in the console with what name was duplicated and what route this was defined in. So if you have `user/:{id}/:{id}`, you'd get an error in the console such as:

    "id" already defined in route "user/:{id}/:{id}"

Also, if you have a type that is not known, you'll also get an error. So say you have `user/:{id:foo}`, `:foo` is not a default type so you'd get this error:

    Unknown parameter type "foo" in route "user/:{id:foo}"

Since there is a difference between how the parameters are passed to the handlers, we don't want the two syntaxes mixed in a route. The older syntax is called "positional" and the newer being called "named". If you mix these syntaxes like so: `foo/:bar/:{baz}` you will get the error:

    URL parameter mismatch. Positional url parameter found while in named mode in the route "foo/:bar/:{baz}".

A couple thoughts here on the duplicate parameters. Right now, you cannot have duplicate parameter names in the same route. However, we've discussed turning the single value into an array to support duplicate names, however, we don't really think this will be something that many will use and an error may be more helpful. Once again, let us know your thoughts as we can have a config to allow this if people would want it, just provide us with a real world scenario where you'd want it.

You can define your own custom named types via an override. For example, in Sencha Fiddle a fiddle id will only be `[a-z0-9]` and I can have the route defined in a couple places so having a central place to have this and be able to be used anywhere would be a big pro. So you can add one:

```js
Ext.define('Override.route.Route', {
    override : 'Ext.route.Route',

    config : {
        types : {
            'fiddleid' : {
                re : '([a-z0-9]+)'
            }
        }
    }
});
```

Now I can define routes such as:

```js
routes : {
    'fiddle/:{id:fiddleid}' : {
        action : 'onFiddle',
        name   : 'fiddle'
    }
},

onFiddle : function (params) {
    Ext.Ajax
        .request({
            url : '/fiddle/get/' + params.id
        })
        .then(function (fiddle) {
            // ...
        });
}
```

So since we are now parsing parameters and their types, there is one thing that I've seen people ask for and that would be supporting an arbitrary number of parameters in a hash. For example, say you want to support hashes like `#view/foo` and `#view/foo/bar/baz` in a single route. Before, you'd have to do something complex with conditions and if you didn't want to get too complex, you'd have a static number of parameters defined in your pattern like `view/:foo/:bar/:baz` (this isn't a very good, full example of what would be needed). So we are attempting to handle this with this syntax:

```js
routes : {
    'view/:{args...}' : {
        action : 'onView',
        name   : 'view'
    }
},

onView : function (params) {
    // Ext.isArray(params.args) === true
}
```

By default, this syntax will match everything (uses `(.+)?`) and split on `/` so that you get an array of values. Like the `:num` and `:alphanum`, this will also attempt to cast numbers into floats. So if you have this hash `#view/foo/12.45/bar`, this is what the params object would be:

```js
{
    args : [ 'foo', 12.45, 'bar' ]
}
```

As you would expect, you don't need to have just the one parameter, you can have other parameters with their own types:

```js
routes : {
    'view/:{which}/:{amount:num}:{args...}' : {
        action : 'onView',
        name   : 'view'
    }
}
```

The params object would then be:

```js
{
    amount : 12.45,
    args   : [ 'bar' ],
    which  : 'foo'
}
```

Most people would be fine with splitting by `/` but if you wanted another character you can override this via:

```js
Ext.define('Override.route.Route', {
    override : 'Ext.route.Route',

    config : {
        types : {
            '...' : {
                split : '-'
            }
        }
    }
});
```

This also shows there are 3 things you can use when defining your own type. The `...` is just a type defined as such:

```js
'...': {
    re: '(.+)?',
    split: '/',
    parse: function (values) {
        var length, i, value;

        if (values) {
            length = values.length;

            for (i = 0; i < length; i++) {
                value = parseFloat(values[i]);

                if (!isNaN(value)) {
                    values[i] = value;
                }
            }
        } else if (Ext.isString(values)) {
            // IE8 may have values as an empty string
            // if there was no args that were matched
            values = undefined;
        }

        return values;
    }
}
```

Simple to understand, the `re` is the string that will control what pattern will be matched, `split` will turn the value into an array (or undefined if no matches) and `parse` allows you to parse the value into something else.

One type that could be useful and has come up a couple times in the last couple weeks is supporting query parameters in a hash. So you could use something like `#foo?bar&baz=2` and the query string like part would be turned into a nested object. You coul duse this override to support this:

```js
Ext.define('Override.route.Route', {
    override : 'Ext.route.Route',

    config : {
        types : {
            queryString : {
                re    : '(?:\\?(.+))?',
                parse : function (params) {
                    var name, value;

                    if (params) {
                        params = Ext.Object.fromQueryString(params);

                        for (name in params) {
                            value = params[name];

                            if (value) {
                                if (/^[0-9]+$/.test(value)) {
                                    // let's turn this into a float
                                    params[name] = parseFloat(value);
                                }
                            }
                            // an empty string would be ?foo
                            // which can be seen as truthy
                            else if (Ext.isString(value)) {
                                params[name] = true;
                            }
                        }
                    }

                    return params;
                }
            }
        }
    }
});
```

You'd then defined your route as:

```js
routes : {
    'foo:{query:queryString}'   : {
        action : 'onFoo',
        name   : 'foo'
    }
}
```

So if you had the hash as `#foo?bar&baz=2.1` then the params send to the `onFoo` method would be:

```js
{
    query : {
        bar : true,
        baz : 2.1
    }
}
```

# Summary

Once again, Sencha has listened to it's community and along with what we learn as we use the router, the router is only getting better. More and more people are using in different applications and knowing how people use the router has been immensely helpful in crafting new features. Keep letting us know what you'd like. Open a forum thread and get my attention (Twitter is a great way, [@LikelyMitch](https://twitter.com/@LikelyMitch)) and I'd be more than happy to discuss it with you and give my honest personal opinion. :)


6.6 Router Improvements


**Note** This blog is talking about features that are not yet released and can change at any time prior to launch.

## Story

Back in 2011, I was part of a contract for a very large financial company. This company had several departments (each department had to have it's own PO too, silos are fun) but the company was wanting a single business to business (b2b) application that all it's internal departments would take part of to interface with external businesses.

This application would be in the millions of lines of code and we had to support IE6. At the time, Ext JS 3 was a very stable platform, however, serving a single JavaScript file that contained millions of lines of code to IE6 was just not going to work. Furthermore, we didn't want to split the single file into loading several files at startup; basically we didn't want startup time to be huge while it loads all that code. So we engineered a means of module loading so we only load what we need at any given time. Architecting this large application into modules was a good idea anyway to keep one silo'd department from working on the same code as another silo'd department.

Ext JS never supported this module loading, that's about to change. Together with Sencha Cmd 6.5, Ext JS applications will have support for module loading! I wanted to take a moment to discuss how to get this to work, it's actually really simple. Sencha Cmd supports the concept of packages and each package can require or even extend another package, these packages are key to this loading as each package can be chosen to be loaded on the fly. In `app.json`, there is a new `uses` entry that is an array just like `requires`. This means, the application will use the package but it's not required to be bundled within the application. Cmd can then build the package as part of an application build but keep the package's source separate from the application so that you can load it on demand.

## Let's Code

First, we need to grab a copy of Ext JS 6.2 (this may change to 6.5 but currently I'm using the latest 6.2.2 nightly build) and use Sencha Cmd **6.5** (6.5.0 will be the minimum version required for Cmd) to generate a modern toolkit Ext JS application. *For this test, I'm using Ext JS 6.2.2.309 and Cmd 6.5.0.146*

```sh
sencha --sdk /path/to/ext generate app -modern MyApp /path/to/MyApp
```

Let's get into the application and run a dev build:

```sh
cd /path/to/MyApp
sencha app build --dev
```

If you load up the application (http://localhost/MyApp for me) you will see a tab panel with bottom tabs, first tab has a grid with the others having some simple lorem ipsum text. We now need to require the `package-loader` package that Cmd will download and install into your application automatically. To do this, we just need to add that package to the `requires` array in `app.json` which will look like:

```js
"requires": [
    "font-awesome",
    "package-loader"
],
```

We need to now refresh the application:

```sh
sencha app refresh
```

If you look at `/path/to/MyApp/packages/remote` you will see the `package-loader` package now. Right now, we don't have any packages to load so let's generate a package for three of the tabs (Users, Groups and Settings):

```sh
sencha generate package -require Users \
    then generate package -require Groups \
    then generate package -require Settings
```

**Note** the `-require` switch is there to prevent Cmd from adding the new packages to the `requires` array.

If you were to look in `/path/to/MyApp/packages/local` you will now see all three packages listed there now. In each package, let's add a main view and let's call them all `MyApp.view.<pkgname>.Main` where `<pkgname>` is the package name so we'd have `MyApp.view.groups.Main`, `MyApp.view.settings.Main` and `MyApp.view.users.Main`. Here is the source with the file location for the three views:

```js
// /path/to/MyApp/package/local/Groups/src/Main.js
Ext.define('MyApp.view.groups.Main', {
    extend : 'Ext.Component',
    xtype  : 'myapp-groups-main',

    html    : 'This is the <strong>groups</strong> view!',
    padding : 20
};

// /path/to/MyApp/package/local/Settings/src/Main.js
Ext.define('MyApp.view.settings.Main', {
    extend : 'Ext.Component',
    xtype  : 'myapp-settings-main',

    html    : 'This is the <strong>settings</strong> view!',
    padding : 20
});

// /path/to/MyApp/package/local/Users/src/Main.js
Ext.define('MyApp.view.users.Main', {
    extend : 'Ext.Component',
    xtype  : 'myapp-users-main',

    html    : 'This is the <strong>users</strong> view!',
    padding : 20
});
```

Ok, very simple views but just enough to hopefully show a couple things. First, I want to point out that I am nesting the classes within the package in both the class name and xtype/alias. This is more optional but I think it's important to do so for architecture purposes. I also named each class `Main`, this is a common pattern for the entry class for applications and packages but you can name it whatever you want. I'd pick something common for all your packages so the logic within your app is minimal.

At this point, the application doesn't know about these packages let alone the class within each. Like I mentioned before, we need to add the packages to the `uses` array in `app.json`, I like to place this array next to the `requires` array just to keep similar things close to each other so I'd have:

```js
"requires": [
    "font-awesome",
    "package-loader"
],

"uses": [
    "Groups",
    "Settings",
    "Users"
],
```

Let's run another build with a tweak to tell Cmd to look for the `uses` array:

```sh
sencha app build --dev --uses
```

You will see this will take a bit more time as it has to build those three packages and then build the app so essentially we are building four apps. It's not only bundling the JavaScript sources, it will also use fashion to compile the `scss` files into a CSS file. Now that all the bootstrap data has been generated, we can now start using that `package-loader` package to load our package's JavaScript and CSS files. Let's prepare first by editing `/path/to/MyApp/app/view/main/Main.js` to add an `activate` listener and make the `items` array be:

```js
items: [{
    title: 'Home',
    iconCls: 'x-fa fa-home',
    layout: 'fit',
    items: [{
        xtype: 'mainlist'
    }]
}, {
    title: 'Users',
    iconCls: 'x-fa fa-user',
    layout: 'fit',
    pkg: 'Users'
}, {
    title: 'Groups',
    iconCls: 'x-fa fa-users',
    layout: 'fit',
    pkg: 'Groups'
}, {
    title: 'Settings',
    iconCls: 'x-fa fa-cog',
    layout: 'fit',
    pkg: 'Settings'
}],

listeners: {
    activeitemchange: 'onItemActivate'
}
```

Let's pause and see what we are expecting here. The first tab (`Home`) will use `mainlist` which is `List.js` in the application, this isn't going to use the package loading but could if you choose too. The other three tabs have removed the `bind` statement and added the `layout` and `pkg` configs. The `layout` config is an Ext JS config as we need the tab to be present so the user can click on something but there are no items or anything as when we load the associated package (defined by the `pkg` custom config) we are going to add the `Main` view to this tab so fit layout is needed in this case. The listener is there to tell the controller about the tab change so that we can decide if we need to load the package or not.

If you were to look at the app, the `Home` tab stayed the same but the other three tabs will show a blank screen because the tabs have no child items. We need to edit `/path/to/MyApp/app/view/main/MainController.js` to require the `Ext.Package` class that comes from the `package-loader` package by adding this:

```js
requires: [
    'Ext.Package'
],
```

Now we need to handle the `activeitemchange` event. For this, let's a couple methods to `MainController`:

```js
onItemActivate: function (tabpanel, tab) {
    var pkg = tab.pkg;

    if (pkg) {
        if (Ext.Package.isLoaded(pkg)) {
            this.handlePackage(pkg);
        } else {
            tabpanel.setMasked({
                message: 'Loading Package...'
            });

            Ext.Package
                .load(pkg)
                .then(this.handlePackage.bind(this, pkg));
        }
    }
},

handlePackage: function (pkg) {
    var tabpanel = this.getView(),
        tab = tabpanel.child('[pkg=' + pkg + ']');

    tabpanel.setMasked(null);

    //only add item if the item isn't already added
    if (!tab.hasPkgItem) {
        tab.hasPkgItem = true;

        tab.add({
            xclass: 'MyApp.view.' + pkg.toLowerCase() + '.Main'
        });
    }
}
```

In `onItemActivate`, if the tab has the `pkg` property, we need to check to see if the package is loaded or not. If it is, go ahead and jump to `handlePackage` but if not then we need to tell `Ext.Package` to load the package and then go to `handlePackage`. If a load is required, I like to mask the app so we don't get racing conditions because the user clicked on something else. Within `handlePackage`, we have to get the tab, unmask the tab panel and check if the tab has the `Main` class already. For performance, I tend to set a property on the tab that can easily be checked. If it hasn't been set, then we need to add the item with the generated class name; this is where having a common name format can help but this will depend on what your application is doing.

Now if you load the app and click through the tabs, you will notice when a tab is first activated, it will load the bundled JavaScript and CSS assets and will then add the `Main` view to the appropriate tab and that's it!

## Summary

This was a simple example of how Sencha Cmd 6.5 and Ext JS are employing this dynamic package loading. Once Sencha Cmd 6.5 is released, we will have examples that are similar to this along with guides about some other Cmd commands instead of just the `sencha app build --dev --uses` that we used to accomplish some other things like working with packages in development without rerunning builds all the time.

Imaging the possibilities with this. Startup times will improve since you can load only the core of the application and then load what you need as the user uses the application. I work a lot with user sessions and different permissions so I can see my server disallowing loading of a package based on the session since you cannot trust the client giving better security. Lots of great things now come from this and we hope you enjoy it!


Package Loading on the Fly


When Fiddle 1 was being developed back in 2013, Ext JS 5 was in development. At that time, Ext JS did not have a router but Fiddle did. It was obvious that users of Ext JS would benefit so the router was implemented in Ext JS from what Fiddle did. Fast forward to today and we have a new support portal and a new fiddle and there are many things I needed from the router that the router simply did not support. So those new web apps are using a highly overridden router; wouldn't it be great if Ext JS' router would get an update with some of these new things? I thought so, so the next major version of Ext JS has an updated router and I'd like to take a minute to describe some of the updates.

### Update (02-13-2016)

This will be part of the Ext JS 6.5 release. I do not have a release date to provide at this time.

# Mixin
One thing I've seen many people ask for is a mixin to allow any class to use routes. This can be either because you aren't using an architecture (MVC or MVVM) or your application is structured to use utility singletons. Regardless the reasoning, we will have `Ext.route.Mixin` so that you can use the router wherever you want... even a store if that's your thing.

# Global befores
The support portal requires a user to be logged in, fiddle wants to know the session state up-front. Therefore, the routes need to not fire before the session is checked. The way I was doing this was to have a shared before action but this didn't scale very well. What is needed is a global means to have a before action to delay all routes. The router now has a wildcard route concept that will always fire before all routes:

```js
routes : {
    '*' : {
        before : 'onBeforeRoute'
    }
}
```

And like any other before, you just need to execute that `action.resume()` or `action.stop()`. A great place for this would be in your `Application` class.

# Promise support in befores
One drawback to how befores work is the `action` argument is always the last argument which is important for routes having variable number of url parameters. It's not that it's hard to get the last argument, it's just a bit ugly to always have that code. Also, if you've follow me on [twitter](https://www.twitter.com/LikelyMitch), you may have noticed that I used to hate promises but now am a lover. So you can now use promises and `resolve()` or `reject()` to resume or stop the route's execution:

```js
onBeforeRoute : function() {
    return new Ext.Promise((resolve, reject) => {
        setTimeout(() => {
            resolve();
        }, 500);
    });
}
```

Now you don't need to find that last argument and some Ext JS classes support promises in their API so it feels much more natural. But the choice is yours, just don't choose both. :)

# Named routes
The support portal and fiddle use multiple tokens in the document fragment. In fiddle, you may see `view/editor&fiddle/abc` and there are two tokens/routes there: `view/editor` and `fiddle/abc`. Click on the search icon on the left and it updates to `view/search&fiddle/abc`. To do this with out-of-the-box router in Ext JS 5 or 6, you'd have to manually parse out the string and replace the single token, definitely not developer friendly.

To solve this, a route can be named. So for this example, I could have this:

```js
routes : {
    'fiddle/:id' : {
        action : 'onFiddleChange',
        name   : 'fiddle'
    },
    'view/:type' : {
        action : 'onViewChange',
        name   : 'view'
    }
}
```

In fiddle, I now can use `redirectTo` with an `Object` to update that one view token but leave the fiddle one alone:

```js
this.redirectTo({
    view : 'view/search'
});
```

If I wanted to remove the fiddle token but leave the view one intact, just pass `null`:

```js
this.redirectTo({
    fiddle : null
});
```

and the document fragment will then be `view/editor`. You can still pass a `String` to `redirectTo` if you want to completely replace the entire document fragment like you would in Ext JS 5 and 6.

**Note:** If you do not specify a name in the route object, it will default to the url provided. So the name of this route would be `view/:type`:

```js
routes : {
    'view/:type' : 'onViewChange'
}
```

but that's not really friendly but can be useful.

# New `Action` class
In a route's before function, you may have used or seen the `action` argument. Before, this was just an `Object` literal with a `resume` and `stop` function. We are now elevating this to a class to add additional functionality and is really much more than that old `Object` literal. The job of the `Action` class is more of a runner when a route is being executed. An `Action` may have multiple `before` and `action` functions that need to be executed in sequence.

Within a `before` action, you can now add a `before` or `action` as you please:

```js
action.before((action) => {
    action.resume();
});
```

You can also add handlers when the `Action` class has either been fully resolved or if it was stopped by using the `then` method:

```js
action.then(function() {}, function() {});
```

# Suspend/Resume the router
This is one feature I didn't have a need for personally but I have been asked about it and it's simple to implement. If you want to suspend the router completely during some task, you will be able to:

```js
Ext.route.Router.suspend();
Ext.route.Router.resume();
```

Boom! Done! Exactly like [suspendEvents](http://docs.sencha.com/extjs/6.2.1/classic/Ext.mixin.Observable.html#method-suspendEvents) and [resumeEvents](http://docs.sencha.com/extjs/6.2.1/classic/Ext.mixin.Observable.html#method-resumeEvents), you can also tell the `suspend` method to queue the routes while the router is suspended or discard the routes when the `resume` method is executed:

```js
Ext.route.Router.suspend(false); // will not queue routes while is suspended
Ext.route.Router.resume(true);   // will dump the queue before it is resumed
```

# Unit tests
In today's Sencha, having unit tests is a priority. We now have over a hundred unit tests for the 4 classes. Do note, you can never say you have enough unit tests so the number will be growing (100% code coverage !== no bugs).


New Router for Ext JS


Lately, I've been working on a few projects and I've been using [Ext JS](https://www.sencha.com/products/extjs/) served with [Node.js](https://nodejs.org/). We use [AWS](https://aws.amazon.com/) as our ISP using [EB](https://aws.amazon.com/elasticbeanstalk/) with [Docker](https://www.docker.com/). Things are working very well for us but one of the projects I've been working on makes use of [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) where I use [socket.io](http://socket.io). Locally things are going great but one thing that I know is that EB doesn't specifically like WebSockets. Well, it's not that it doesn't like WebSockets, it's more that the default config doesn't allow for it.

## Setup

First things first, let's create a simple Node.js app that will allow us to use WebSockets and push events to all connected sockets. Since I don't want to step through code in this blog, I've created a [GitHub repo](https://github.com/mitchellsimoens/Simple-WebSocket). I also assume you have the [eb cli](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3.html) installed.

The eb cli wants to use git so you should have a git repo all setup. I always create git repos and commit code often to preserve a history and ease of rolling back code. So I assume that you have the code from my repo brought down and using your own git repo.

## Initializing the eb project

In your local git clone, you need to execute [`eb init`](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-init.html). I like to add the `-i` flag to force getting asked everything but it's up to you. You'll be asked what region you want to be deployed to, what application (you can create an app also), what type of application (select Docker) and version 1.11.1, and any SSH keys.

Once you have your eb project initialized, you can create an environment. For this, you should use the [`eb create [env name]`](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-create.html) command. This should take a bit of time to setup everything and will also deploy your committed code.

Once done, you can load your project in the browser. If you don't know the URL then you can use the [`eb open`](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-open.html) command which will get the URL and open in your default browser. You should see some text and a button but if you were to check the dev tools you'll notice the WebSocket handshake failed with a 400 status code. This is where I said EB doesn't like WebSockets.

## Configuring nginx

For those that do not know, EB uses [nginx](https://www.nginx.com/) as a proxy, basically nginx receives the request and determines what to do with it. We need to configure it to support WebSocket. I'm already checked in [`.ebextensions/files.config`](https://github.com/mitchellsimoens/Simple-WebSocket/blob/master/.ebextensions/files.config) in my GitHub repo so what you already deployed has nginx configured. Also note that during my initial investigations I saw many different ways, this is the way I found that worked for me based on what an AWS team member originally suggested on their [forums](https://forums.aws.amazon.com/thread.jspa?messageID=729795) but without the shell script. So in the last 2 years, there may be a better way to configure nginx but anyway, nginx can now know how to handle WebSockets.

Not all of the settings should be needed, the important bits are:

```
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
```

## Configuring EB

So nginx is configured and we still got the 400 status code on the handshake so what gives? At this point, I wasn't 100% sure I'd figure this out. However, searching the web I kept seeing something about using TCP connections instead of HTTP. So I gave it a shot and all of a sudden everything started working! Using two browsers (Chrome and Firefox), I was able to click the button and each browser get the event pushed to it and I could see the WebSocket upgrade request.

So how do we setup EB to use TCP connections? Go into the [EB dashboard](https://us-west-2.console.aws.amazon.com/elasticbeanstalk/home) and click on the environment for your app. This is where it shows some recent events, the health and other quick info. On the left, there is a vertical list and one of them is `Configuration` which you should click on. If you scroll down and find the Load Balancing box, click the edit tool in the upper-right corner of that box to configure the load balancer. In this form, the second field should be labeled `Protocol` and have two options: HTTP (which should be selected) and TCP. Yup, you guessed it, select TCP and scroll down and save. Go back to the Dashboard for your app's environment and it should be deploying the new configuration.

Once done, you should be all setup. Go to the url of your app and everything should be working!


WebSockets Behind Elastic Beanstalk


Through a lot of my professional life, I've been given steps. Sometimes I didn't get all steps or the steps weren't the most clear so I'd have to figure things out which is fine and in many cases I prefer. The more complex the steps were, the more I'd have to figure things out. I love the challenge; it's like a murder mystery. As I've grown in my roles, the less steps people give me and the more I have to pass down. Knowing that sometimes without proper direction, the project can be quite frustrating for some people. This is where flowcharts are a perfect tool to keep everyone on the same page.

## Flow what?

So what is a flowchart? Well, it's basically a picture of the individual steps (at any certain accuracy) with connectors between the steps to show the flow. [Wikipedia](https://en.wikipedia.org/wiki/Flowchart) has a great explanation as usual. In fact, here is a very simple flowchart from there:

![simple flowchart](./220px-LampFlowchart.svg.png)

As you can see above, each shape is a step and each step is connected with arrow connectors so you can see the flow of turning a lamp on. Now imagine if you apply this to a project or the flow of a particular feature within a project.

## When to flowchart, when to not

Normally I start with a high level flowchart at the beginning of the project without doing work first. I look at the project and get the overall view and build that chart. Usually, there are areas of the project that are more crucial (maybe even due to a deadline) that I need to drill in with another flowchart. You can really get as detailed and have as high project coverage as you want but I normally only focus on high level and crucial areas of a project. As the project goes on, I'll create more on the fly as I see where the project goes.

I wouldn't create a flowchart for everything, it can also be a waste of time. For example, the lamp flowchart above is really not needed, it's really too simple. It definitely depends on the project and what parts of that project are but starting high level and focusing on the crucial areas is a great start and drilling down as needed.

If someone is having a hard time understanding how something should work, a flowchart is a great visual way to explain things to get people on the same page. For example, I had a project where we had a tight deadline. I know most of it but there was a part where someone else know exactly how it's supposed to work. I created a flowchart for the overall flow and with that person's input on the part I didn't know, I was able to finish the flowchart so that everyone knew exactly how it works. Without a flowchart, it's was up to people describing how things work and in meetings (especially online meetings) people tend to drift off and miss parts of the meeting.

## Tools

So how do I create flowcharts? I've used [omnigraffle](https://www.omnigroup.com/omnigraffle) quite a bit before but have since moved onto [draw.io](https://www.draw.io/). What I like about draw.io (other than it's free) is that it's integrated into [Google Drive](https://drive.google.com/) and is just a well made web app. I've applauded them on their execution of this app, it's dead simple and automatically saves to Google Drive for me which also allows for other people to contribute (I haven't yet had multiple people working on the same chart at the same time). The only drawback is sharing, it shares the rendered flowchart but is usually quite small of a preview making me take screenshots to share.


Flowcharts for the win!


Earlier today, I noticed a conversation about how [React](https://facebook.github.io/react/) was "far more flexible when it comes to customizing" than [Ext JS](https://www.sencha.com/products/extjs/).

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr"><a href="https://twitter.com/dmitrybrin">@dmitrybrin</a> It&#39;s component-based like Ext JS but far more flexible when it comes to customizing. Also really fast.</p>&mdash; Arthur Kay (@arthurakay) <a href="https://twitter.com/arthurakay/status/719477208012578817">April 11, 2016</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

So being an Ext JS dev, I disagree with this statement except the last sentence, React is really fast no doubt. React being far more flexible is very debatable. Yes, with React you are the one creating the DOM whereas Ext JS' produced DOM can be bloated a bit and if you're writing your own library of widgets to suit your application you can create it in a way that is best for your application. However, comparing React to Ext JS is like comparing a go-kart to a semi truck. React doesn't do that much, it's just the view layer that you can build on top of whereas Ext JS is a full framework and gives a huge set of widgets out-of-the-box. Sure, you can drive a go-kart but you can't haul things like a semi can.

Let's be honest, having a full framework like Ext JS has it's pros and cons. The pros are self evident (huge set of widgets, opinionated code structure, etc) however there are cons like the produced DOM. That DOM may be bloated for your use but when you flex the full functionality of the framework, that "bloat" isn't actually bloat. I bet you don't use every feature of Microsoft Word but still use it (and yes, I'm sure still holds true for OpenOffice etc). But with Ext JS, you don't have to build and maintain the set of widgets which can quickly get expensive and risky of developer lock-in and supporting all the features it does and configurations developers need it to support for the vast difference of applications out there, that "bloat" is needed. And I'll be honest again, I'm sure not all the bloat is necessary, I'm sure there are opportunities for improvement but it wouldn't be night and day I'm sure.

It really shouldn't be React vs Ext JS as either will win for what either attempts to fulfill. Each project should determine which thing it should use. You cannot say:

> I want to have all these features built-in but still be lightweight.

You cannot have both. You cannot make a truck be as fast as a sports car but still be as lightweight as the car. I know, I'm analogy full today.


Full featured or lightweight, cannot have both


Last week, we deployed a major update to an application and after a couple days it finally fell on it's face. The server, hosted on AWS, randomly went into a red state and was unreachable from outside requests overnight. The servers were using an older version of Docker and Elastic Beanstalk commands were taking a long time to complete so we initially thought it was in our AWS setup. I know, noob mistake to jump at guessing the issue instead of looking at the logs.

After trying 15 different configurations, we took a look at the logs and noticed npm was throwing some errors. The errors were during the `npm install` and the JSON that was being returned would randomly fail to fully return causing issues when npm tried to parse the JSON. We then noticed that the install npm's version was 1.3 whereas what we were using locally would be v3. We installed v3 and that issue went away, however, we were not very happy.

The server is running Ubuntu 14.0.4 LTS. Normally vendors do a decent job adhering to the LTS standing but doing an `apt-get install -y npm` would install npm 1.3 but that version is not supported anymore. What npm should do is update what is installable in apt. To work around this, we installed Node v5:

```sh
apt-get update
apt-get install -y build-essential curl
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
apt-get install -y nodejs
```

Now we have Node 5 and npm v3. So thanks npm!


npm failed me


Open source is great, except when it's not. If you were under a rock this week, some big projects broke due to a module being removed (left-pad). So if you were using Babel or React, it broke if you attempted to `npm install` it. You can read about it [here](http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) and [here](http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/). Now of course this will be incredibly simple to fix as the required code is extremely small but it also shows that open source comes with it's risks.

I personally think this whole fiasco could have been handled much better, when you use a piece of code, you get into a sort of contract with the maintainer. As an author of a few repos on GitHub that some people do use, I attempted to work with people to make what I made work better for them (implement features, change features) but life got busy and I simply didn't have time to maintain it. It's not that I didn't have intention to keep maintaining it, I simple couldn't dedicate any time to it so as a maintainer, I failed the open source community and therefore broke the contract where they were using my code and expected it to work.

The drama this week was much more than simply not having enough time to maintain left-pad but since this blog is geared towards Sencha products, I'll highlight one of the big benefits of using something from Sencha. While the whole web dev community is hot on building their own framework made up of many different libraries, Sencha provides a framework that is setup to work together. So if you want components and MVC/MVVM, Sencha works to have it work out of the box. Want a data package with charting? Sencha has it all working and they maintain it. So instead of mixing React with Bootstrap and Highcharts and so on, you just need to download Ext JS and start working. If one of the libraries in your DIY framework is updated and you want to use it, you have to update it and make sure all the different pieces of your DIY framework work with that update. Whereas with Ext JS, when an update is released you just need to replace Ext JS.

We all know that any software update may come with API changes and Sencha has been releasing [API Diffs](http://docs.sencha.com/extjs/6.0/api_diffs/601_classic_diff.html) now and even really good upgrade guides for major version upgrade like [this](http://docs.sencha.com/extjs/6.0/upgrades_migrations/extjs_upgrade_guide.html). Sencha has been putting a lot of effort into documenting any API changes and keeping backwards compatibility where possible.

So in the open source vs commercial company debate, I won't say which is better. What I will say, commercial still has a place these days. Sure commercial isn't always the cheapest but when you look at what you get, it may actually be cheaper in the long run. What you get with Ext JS can outweigh the cost of developing your DIY framework, maintaining it and training new people on it.


No dependencies, no drama!


When [Ext JS](https://www.sencha.com/products/extjs/) 5 was released it brought with it data binding including two-way data binding. Although some argue that two way data binding is an anti-pattern, it does have it's uses. Many Ext JS components have two-way binding ready by default (for example, [this Kitchen Sink example](http://examples.sencha.com/extjs/6.0.1/examples/kitchensink/#binding-two-way)) but there may be cases where you want to setup a custom bindings. At a high level, what I want is when one component changes, another component changes in response automatically and if that second component changes, the first component also changes.

## First Attempt

As a use case, I was recently asked how to collapse/expand a `Ext.form.FieldSet` using data binding. Without any custom things, it's possible like so:

<iframe style="border: 0;height: 600px;width: 600px;" src="https://fiddle.sencha.com/fiddle/120u"></iframe>

In this fiddle, the`Ext.form.field.Checkbox` under the `FieldSet` will toggle whether the `FieldSet` is expanded or not. However, that's kind of weird because we are binding to `expanded` but that's not a config of `FieldSet`. The reason I used it is because binding requires a setter function so in this case the `FieldSet` needs (and does albeit being private) have a `setExpanded` method in order for binding to work. `FieldSet` does have a `collapsed` config but binding needs a setter and there is no `setCollapsed` method. We could create a simple override to add one:

<iframe style="border: 0;height: 600px;width: 600px;" src="https://fiddle.sencha.com/fiddle/120v"></iframe>

That looks better! However, if we manually collapse/expand the `FieldSet`, the `Checkbox` will not reflect this change so it's only one-way currently. This is where we need to do some custom stuff in order to have two-way binding. There are two ways to have two-way binding and which to use depends on if the config you want to change is within the config object (so setter and getter methods are automatically created for you).

## Manual Two-Way Binding

To get the new value up to the `Ext.app.ViewModel` on the form, the `publishState` method must be executed passing in the name and value. The `FieldSet` will fire `collapse` and `expand` events when it has been collapsed/expanded so we can add listeners to it in order to execute that `publishState` method:

<iframe style="border: 0;height: 600px;width: 600px;" src="https://fiddle.sencha.com/fiddle/120t"></iframe>

In the `initComponent` method, I add listeners to the `collapse` and `expand` events which will execute the `publishCollapsed` method. If rendered, this will execute `publishState` meaning two-way binding is setup.

## Automatic Two-Way Binding

Like I said before, the way to know if you need to hookup the `publishState` method execution or if Ext JS can handle it automatically for you is whether the config you are binding to is within the config object. The `collapsed` config is not part of the config object but what if we had a custom config, how can we get that custom config to be two-way bindable? This is where `twoWayBindable` comes in handy to hook things up for us:

<iframe style="border: 0;height: 600px;width: 600px;" src="https://fiddle.sencha.com/fiddle/121e"></iframe>

When `setFoo` is executed, we check to see if the `FieldSet` is already collapsed/expanded and then execute the `setExpanded` if not. We had to add the `setFoo` call to `setExpanded` also to hook into when the `FieldSet` is manually collapsed/expanded by the user. That has nothing to do with the binding tho, the bit to pay attention to is the config object and the `twoWayBindable` property. The `twoWayBindable` property is an array of configs and it will then hook into the `updater` for that config to then automatically execute that `publishState` method. So the binding is automatic, the other code is to handle collapsing/expanding when the `foo` config changes.

## Summary

Data binding can be a bit mysterious but having some form of understanding the sequence of things helps go a long way. Knowing that `publishState` and having an associated setter method are important pieces of the binding puzzle. For more, check out the [guide](http://docs.sencha.com/extjs/6.0/application_architecture/view_models_data_binding.html) that goes over binding.


Custom Two Way Binding!


Personally, I use a technology called Ext.Direct for my projects. Ext.Direct is platform and language agnostic remote procedure call protocol. I'm not going to go into the features and benefits of using Ext.Direct in this post, I'll save it for a different post but you can check out the [spec](http://docs.sencha.com/extjs/latest/direct/specification.html) we released.

### Bad Ways

Lately, I've seen a few methods people are using to load the api descriptor and I'd like to show them and discuss why they are a bad idea and then of course show the proper way. First means of loading the api I recently saw is this:

```js
Ext.define('MyApp.DirectAPI', {
    requires: ['Ext.direct.*', 'Ext.Ajax']
}, function() {
    Ext.Ajax.request({
        url: "/DirectApi",
        async: false,
        success: function(xhr) {
            Ext.globalEval(xhr.responseText);
        },
        failure: function(xhr) {
            throw "Direct API load failed with error code " + xhr.status + ": " + xhr.statusText;
        }
    });
    Ext.direct.Manager.addProvider(Ext.app.REMOTING_API);
});
```

What this is doing is if the application requires `MyApp.DirectAPI` it will then do a synchronous ajax call, eval the response and then add the provider.

Another means I saw is:

```js
Ext.define('MyApp.DirectAPI', {
    requires: ['Ext.direct.*']
}, function() {
    Ext.Loader.loadScriptsSync('api.php');
    /*
    Add provider. Name must match settings on serverside
    */
    Ext.direct.Manager.addProvider(Ext.app.REMOTING_API);
});
```

This is basically the same thing as the first code, just uses `Ext.Loader.loadScriptsSync` instead of `Ext.Ajax.request`. The only difference is the `loadScriptsSync` does the eval for you, both use `XMLHttpRequest`.

### The Why

So these techniques work but why are they bad? The main issue in both is the use of a synchronous call. Let's look at this from a user standpoint. The user has to wait for the application to load (Ext JS apps are normally larger), then the browser locks up for a period of time and then the application renders. What would you do if every time you visit an app you had a period where it locks up the entire browser? Honestly, I wouldn't use it or if I had to I'd complain about it. Networks fail, servers can be complex and slow. If the call to load the Ext.Direct api took 10 seconds, you'd have 10 seconds where the user is sitting looking at the screen with a browser that cannot do anything. I've forced closed apps for that before. In fact, at one client an async request took over a minute to complete and I fought to have them fix that, their solution was for me to raise the timeout. People need to look at the issue and see the proper way to fix issues, not just what's fast and easy.

### The Proper Way

If you are using [Sencha Cmd](https://www.sencha.com/products/extjs/#sencha-cmd) (which I would highly recommend), instead of the code ways above all you have to do is add the script to the `app.json`'s `js` array:

```json
"js": [
    {
        "path": "app.js",
        "bundle": true
    },
    {
        "path": "/direct/api",
        "remote": true
    }
]
```

Now, after you run a `sencha app watch` or `sencha app build`, Ext JS will automatically create a `<script>` tag to load the direct api and defer the application's `launch` method from executing until it has loaded. Then in the `launch` method you can then use the `Ext.direct.Manager.addProvider`.

If you're not using Sencha Cmd, then all you have to do is add a `<script>` to your index.html and your application's `launch` method or `Ext.onReady` will defer till it loads:

```html
<script type="text/javascript" charset="UTF-8" src="/direct/api"></script>
```

Without doing anything on the server, the application will still wait for the direct api to load so you still will have that issue to contend with but the browser will not be locked up. If the person wants to close the browser for whatever reason or open a new tab to do something else they can. So the difference is if the browser will be locked up or not, I'd choose not to lock the user's browser up. Even if the load takes < 1 second, since there is a way not to do it I wouldn't.


Loading Ext.Direct api


I have a project that I want to start working on but first needed to create a quick proof-of-concept (POC) to make sure I can do what I wanted. I was about 99% sure what I want to do is possible, just that 1% is due to never doing it. So the POC was to create a SFTP server that saved public keys in a database like GitHub does. I know you can install an ssh server and use the [`AuthorizedKeysCommand`](http://linux.die.net/man/5/sshd_config) but if possible, I wanted to do everything within [Node.js](https://nodejs.org/en/), not install another server onto my server.

First thing most people do, off to search [npm](https://www.npmjs.com/). I quickly found the [ssh2](https://www.npmjs.com/package/ssh2) module which seemed to have active development still (GitHub repo started in August 2012 and still has commits from a couple days ago). After setting up example server and client scripts, I needed to get a file downloaded from the server. I did have a bit of trouble with this but [mscdex](https://github.com/mscdex) gave me a [boost](https://github.com/mscdex/ssh2/issues/322#issuecomment-140930439), much obliged! So I got a file downloading and even got it to authenticate based on private/public keys reading from my filesystem. Looking at the code, it's async so I knew I could do this by saving it in a MySQL database and it's was extremely easy.

I've setup a simple example GitHub [repo](https://github.com/mitchellsimoens/SFTPServer). The server is `server.js` and a test client script is in `client_test.js`. You'll have to change some configs in both scripts. You'll also need to setup the table I use, this is what I have:

```sql
  CREATE TABLE `user_public_keys` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `username` varchar(200) NOT NULL,
    `name` varchar(25) NOT NULL,
    `key` text NOT NULL,
    `added` datetime NOT NULL,
    PRIMARY KEY (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
```

Once you setup the MySQL connection details in `server.js` you'll be able to read from the table. You'll have to generate an RSA host key, check out `keys/README.md`, it's a simple command but pay attention to where it wants to save the file, I placed it at `keys/host_rsa`.

Not sure what other steps are needed but that should be it. Some configs in `server.js` and `client_test.js`, MySQL table, host key and of course the `npm install` command to install module dependencies. Should be able to start the server (`node server`) and then try the client script (`node client_test`) and it should download the file. The server will remain up and you should see some logs that show the OPEN, FSTAT, READ and CLOSE steps.


SFTP server in Node.js


[React](https://facebook.github.io/react/) is a very fast view layer and that's it. Ok, we all know that (I hope). React doesn't handle any business logic for user interactions. For example, if someone clicks on a button React doesn't do anything. For that, you would need to use a dispatcher (or some other means).

## Improved event handling

Luckily, [Facebook](https://www.facebook.com/) also has [Flux](https://facebook.github.io/flux/) which has a [dispatcher](https://facebook.github.io/flux/docs/dispatcher.html#content) class where you can register callback listeners for when something is dispatched. Here's a simple example of this (taken from their documentation):

```js
var flightDispatcher = new Dispatcher();

flightDispatcher.register(function(payload) {
    if (payload.actionType === 'city-update') {
        CityStore.city = payload.selectedCity;
    }
});

flightDispatcher.dispatch({
    actionType: 'city-update',
    selectedCity: 'paris'
});
```

Ok, that's pretty simple. However, in practice I don't like one thing and that is when something is dispatched, **ALL** registered callbacks will execute. Each callback has to check if they care about the dispatched event. This seams quite wasteful and unneeded logic in the callback especially since you will likely have lots of registered callbacks. Sure, you can build something on top of it:

```js
function callbackCreatorThing(property, value, callback) {
    return function(payload) {
        if (payload[property] === value) {
            callback(payload);
        }
    }
}

flightDispatcher.register(
    callbackCreatorThing('actionType', 'city-update', function(payload) {
        CityStore.city = payload.selectedCity;
    })
);
```

So I created a function factory that will call the actual callback when `payload.actionType` is equal to `city-update`. Ok, so that's not the end of the world and of course there are many other ways to do it but still... more work than you should have to do. I come from an [Ext JS](https://www.sencha.com/products/extjs/) world where things are event driven meaning you add a listener for when a certain event is driven. So I'd do something like this in Ext JS:

```js
cls.on('city-update', function(payload) {
    CityStore.city = payload.selectedCity;
});

cls.fireEvent('city-update', payload);
```

So when the `fireEvent` is called, only those listeners listening to that event will be fired. So I need this:

```js
flightDispatcher.register('city-update', function(payload) {
    CityStore.city = payload.selectedCity;
});

flightDispatcher.dispatch('city-update', {
    selectedCity: 'paris'
});
```

So I have to create my own dispatcher class (which is very easy). While I'm at it, why not extend this and allow certain actions to be dispatched and registered so a user can really get fine grained:

```js
flightDispatcher.register('city', 'update', function(payload, listener) {
    CityStore.city = payload.selectedCity;
});

flightDispatcher.dispatch('city', 'update', {
    selectedCity: 'paris'
});
```

Here, the event is `city` and the action being taken is `update`. I even get access to the listener. In fact, we could support all three cases:

```js
flightDispatcher.register('city', 'update', function(payload, listener) {
    CityStore.city = payload.selectedCity;
});
flightDispatcher.register('city', function(payload, listener) {
    //something happened to a city
});
flightDispatcher.register(function(payload, listener) {
    //something happened
});

flightDispatcher.dispatch('city', 'update', {
    selectedCity: 'paris'
});
```

There are valid reasons to have catch all listeners like what Flux has.

## Event Class

So the listening to dispatched events has been improved. However, there is one more thing that I like in Ext JS: the separate event (`Ext.event.Event`) class. This class holds many things but one thing I use a lot is the ability to stop an event in a listener. Maybe some business logic says that the user isn't able to update a city, then you should be able to stop an event from firing other listeners. For this, I created a separate Event class which the Dispatcher creates when it finds all the listeners for the event and action being dispatched. So now you can do this:

```js
flightDispatcher.register('city', 'update', function(e) {
    e.stop();
});
flightDispatcher.register('city', function(e) {
    //something happened to a city
});
```

In the first registered callback, I stop the event from firing so the second registered callback will not be executed. This gives further control over the flow of the events in an application.

## Conclusion

Using React with Flux versus using Ext JS shows how mature Ext JS is, it's been around for almost 10 years now so I'd expect it to be. However, this doesn't mean that some ideas from Ext JS cannot be applied to a React application.

I've quickly put the code up on [GitHub](https://github.com/mitchellsimoens/react-idispatcher) and [npm](https://www.npmjs.com/package/react-idispatcher). The dispatcher class is a singleton (I create an instance and return it in `module.exports` as there really should only be one message bus.


React dispatcher, improved


Playing around the other day with ES6 and classes and ran upon a strange error. It was simple code, a base class, a subclass and a constructor:

```js
class Base {}

class Sub extends Base {
    constructor(config) {
        console.log(this);
    };
}

new Sub();
```

This resulting in a `ReferenceError` that `this` was `undefined`. This was, quite simply, the only time I've ever see `this` be `undefined`. I mean, even if I were to try to make it `undefined` I couldn't:

```js
function Foo() {
    console.log(this);
}

Foo.call(undefined);
```

Within `Foo`, `this` would be equal to `window`. So how can it ever be `undefined`? My first thought was that ES6 is very new and not fully implemented anywhere yet (Babel and Traceur are coming close to transpiling it though) and the browsers are definitely not close for real native development (see kangax's [chart](https://kangax.github.io/compat-table/es6/)) so then it must just be a browser error. Since I know Babel is quite far along and they have a [playground](https://babeljs.io/repl/) that can run in the browser I threw the code in there and finally got an error that explains it:

    'this' is not allowed before super()

What a curious bug but trying it out this code does indeed work:

```js
class Base {}

class Sub extends Base {
    constructor(config) {
        super(config);

        console.log(this);
    };
}

new Sub();
```

So `this` can only be used after calling `super` huh? Why? And I don't mean technically why but theoretically why? What if I wanted to do something before calling the superclass' method and use `this`? So now a superclass has to take into account any subclasses. So if I wanted to do something, I guess I would have to execute a function in the superclass so that a subclass can enact on it:

```js
class Base {
    constructor(config) {
        if (this.doSomething) {
            this.doSomething(config);
        }
    }
}

class Sub extends Base {
    constructor(config) {
        super(config);

        console.log(this);
    };

    doSomething(config) {
        console.log(this);
    }
}

new Sub();
```

Yuck! I hope someone else has found a better way to use `this` in a subclass.

Ok, so there's a limitation there and as developers we can beat our heads against a brick wall (you can't beat the interpreter) or you can develop around the limitation. I was just hoping, in a new spec in modern day, that I wouldn't have such limitations. I come from a PHP background and have no problems like this. Currently use Ext JS and it's class system and have no problems like this.


this is undefined, what?


Yesterday, I posted about a gripe on not [pluralizing text](https://sencha.guru/2015/08/12/pluralize-text/) based on the value that text was associated to. Today, I visited a site and noticed some of their numbers were not formatted (some were). Once again, I was surprised how much this annoyed me...

![bad number formatting](./bad-number-formatting_zqjzot.png)

You can see the '1000000' is not formatted, in fact I had to count a couple times to make sure I had enough zeros because my eyes were playing tricks on me when trying to count the number on the site. That's why you format the numbers! So your users don't have to struggle!

Once again, Ext JS to the rescue! `Ext.util.Format` has a `number` method that will take a value and a format string. The format string has quite a lot of options and luckily is pretty well [documented](https://docs.sencha.com/extjs/6.0/6.0.0-classic/#!/api/Ext.util.Format-method-number). Let's look at a simple example that will format that text correctly (least for my locale):

<iframe src="https://fiddle.sencha.com/fiddle/s3q?height=200" style="height:200px;width:600px;border:0;"></iframe>

As you can see, it outputs '1,000,000' and I can easily see what the actual value. Before formatting, it could have easily been 10,000,000 or 100,000 but now I know for sure it's 1,000,000. Let's look at usage in an `Ext.XTemplate`:

<iframe src="https://fiddle.sencha.com/fiddle/s3q?height=200" style="height:200px;width:600px;border:0;"></iframe>

Ext JS making it simple! Let's look at doing this in a grid, there's three ways to do it. Here's a grid with three columns that's doing it the three different ways:

<iframe src="https://fiddle.sencha.com/fiddle/s3s?height=400" style="height:400px;width:600px;border:0;"></iframe>

The first column has a renderer that uses `Ext.util.Format.number` directly, nothing really wrong with this but we can simplify this version by using `Ext.util.Format.numberRenderer` as in the second column. What the `numberRenderer` method does is basically returns a function and within this function uses `Ext.util.Format.number` just like in the first column. In fact, it's exactly the same thing, just a shorthand version. Those two are more for manual usage and backwards compatibility. The third column, for a grid, is the preferred way using `Ext.grid.column.Number` with a simple format config. Just like before, `Ext.grid.column.Number` just defines the `renderer` config for you and uses `Ext.util.Format.number` method just like in the first column.

When should you use one over the other. `Ext.grid.column.Number` was introduced in Ext JS 4.0 so if you are using Ext JS 3 or older, of course you cannot use it then, maybe you should update! :) The benefit of using `Ext.grid.column.Number` is it sets up the `updater` method on the column which means potential faster grid cell updates. I still use the other two when I need to use a different column but still need to format the number. For example, `Ext.tree.Panel` is actually just a grid but with a special column to show the expand and node icons. That means you have to use `Ext.tree.Column` and cannot use the `Ext.grid.column.Number` so you have to use one of the manual ways, like this:

<iframe src="https://fiddle.sencha.com/fiddle/s3u?height=400" style="height:400px;width:600px;border:0;"></iframe>

Here, we have to use the `treecolumn` so we can expand/collapse the Items node so we have to define the renderer. Since some `text` values may not be a number and therefore do not want to format them, I use a quick ternary to check if it's a number then format it, otherwise return it.


Format your numbers!


One of my gripes is when I see text that should be singular but shows plural when the value before it is one. It's 2015, surely we can detect when we should show singular there. Now admittedly, I've missed these opportunities but I do try to show the appropriate form of a word. So if you see `1 items` wrong! Should be `1 item` and `3 items`. I mean all that has to be done is a simple ternary expression:

<iframe src="https://fiddle.sencha.com/fiddle/s41?height=200" style="height:200px;width:600px;border:0;"></iframe>

Done! So what does this have to do with Ext JS? Ext JS makes this a bit easier and has a function that you can call. That code there can be replaced with:

<iframe src="https://fiddle.sencha.com/fiddle/s40?height=200" style="height:200px;width:600px;border:0;"></iframe>

All the `plural` method does is adds the 's' onto the term you pass but also prepends the value you pass in. The `plural` method doesn't do too much magic in determining whether or not to add the 's' so for words that need to be changed more than just adding the 's' then you can pass the plural version as the third argument:

<iframe src="https://fiddle.sencha.com/fiddle/s42?height=200" style="height:200px;width:600px;border:0;"></iframe>

Ok, so this isn't really getting me much except a friendly API. Where I really love using this is in an `XTemplate`. Code like this:

<iframe src="https://fiddle.sencha.com/fiddle/s43?height=200" style="height:200px;width:600px;border:0;"></iframe>

can be replaced with this:

<iframe src="https://fiddle.sencha.com/fiddle/s44?height=200" style="height:200px;width:600px;border:0;"></iframe>

Super clean! In a grouped grid, I use `plural` in the `groupHeaderTpl` and love how clean it is. Just for completeness, you can still pass the plural version too:

<iframe src="https://fiddle.sencha.com/fiddle/s45?height=200" style="height:200px;width:600px;border:0;"></iframe>


Pluralize text


I've been seeing something a lot lately and I wanted to take a quick second to talk about it. This is creating instances and placing them on the prototype and all the issues this can cause and it may not be obvious to the developer. Let's take a look at such a case:

```js
Ext.define('MyApp.view.Main', {
    extend : 'Ext.grid.Panel',
    xtype  : 'myapp-main',

    requires : [
        'MyApp.store.Foo',
        'MyApp.store.Bar'
    ],

    store : Ext.create('MyApp.store.Foo'),

    columns : [
        {
            text      : 'Foo',
            dataIndex : 'foo',
            flex      : 1,
            editor    : new Ext.form.field.ComboBox({
                store : {
                    type : 'myapp-bar'
                }
            })
        }
    ]
});
```

Here, I am creating two store instances and placing them on the prototype; yes, this code does have missing bits to not have super long code. I use `Ext.create` to create an instance of the `MyApp.store.Foo` class and using the `new` keyword to create a `ComboBox` instance as the editor of a column and in the `ComboBox` I specify the store using a config object that will use the `MyApp.store.Bar` via it's alias.

Let's first look at the `store : Ext.create('MyApp.store.Foo'),` line and why it's bad. Even though `MyApp.view.Main` is requiring `MyApp.store.Foo`, which is proper, the `Ext.create` call will be executed by the browser right away before anything else happens, even before the `MyApp.view.Main` class is defined. This is because the browser evaluates the code in that file when the file is downloaded, all prototype members are evaluated to create the object literal being passed into the `Ext.define` call. This means the `Ext.create` call will be executed before the requires is even required. Therefor `Ext.create` will then synchronously load the `MyApp.store.Foo` class and create an instance and place it on the `store` member of that object. This is bad for a couple reasons:

 - The class is synchronously loaded and therefor affects startup performance
 - You expect a new store class to be created for each `MyApp.view.Main` instance creation however all `MyApp.view.Main` instances will share the same `MyApp.store.Foo` store instance because the instance is set onto the prototype. This means if you sort/filter one instance, any and all other instances of `MyApp.view.Main` will reflect that sort/filter even if the instance of `MyApp.view.Main` is created later. It's sharing the store instance.

To fix this part of the code, it should be using a config object:

```js
store : {
    type : 'myapp-foo'
    //xclass : 'MyApp.store.Foo' //or using xclass
}
```

This way, each time an instance of `MyApp.view.Main` is created, a new instance of `MyApp.store.Foo` is created. If you do want to share a store instance, I'd suggest adding the store to your application's `stores` config and then setting the `store` config on `MyApp.view.Main` to the appropriate `storeId` your global store is given.

Next, let's look at the `ComboBox`. Let's assume `Ext.form.field.ComboBox` has already been defined (otherwise you'd get a nice syntax error) the underlying issue is the same as with the `Ext.create` usage, the browser will try to create an instance of `Ext.form.field.ComboBox` which will then try to create an instance of the store before the `MyApp.view.Main` is ever defined which then means those two stores being required are not even requested to be required. You'll then get a nice pretty error from Ext JS like this:

    [Ext.createByAlias] Unrecognized alias: store.myapp-bar

This error is basically saying the `MyApp.store.Bar` store has not been defined yet which is to be expected since the `ComboBox` is being instantiated before the store is ever required.

To fix this part of the code, you simply use a config object for the `ComboBox`:

```js
columns : [
    {
        text      : 'Foo',
        dataIndex : 'foo',
        flex      : 1,
        editor    : {
            xtype  : 'combobox',
            store  : {
                type : 'myapp-bar'
            }
        }
    }
]
```

Now, when the `MyApp.view.Main` is instantiated, when that `Foo` column is instantiated it will create an instance of the `ComboBox` properly.

### Conclusion

I never create an instance and place it on the prototype. There are much better ways to have a global instance of something.


Instances on prototype are bad!


With [Ext JS 6](https://www.sencha.com/products/extjs/) modern toolkit and [Sencha Touch 2](https://www.sencha.com/products/touch/), you can have docked items on an `Ext.dataview.List` without wrapping the `List` in a `Container` or `Panel` like this:

<iframe style="border:0;width:600px;height:600px;" src="https://fiddle.sencha.com/fiddle/r3a"></iframe>

Notice the `docked` config on the toolbar and notice in the preview this adds the toolbar to the bottom of the list and does not take part in the scrolling of the list. What if you wanted to add a component to be beginning or end of the list and take part in the scrolling of the list? For this, Sencha Touch 2 has had the `scrollDock` config since 2.4.0 I believe, not sure exactly when this was first introduced and of course in the merge of Ext JS and Sencha Touch into Ext JS 6, this config still exists. You use it just like the `docked` config:

<iframe style="border:0;width:600px;height:600px;" src="https://fiddle.sencha.com/fiddle/r3b"></iframe>

Now the toolbar isn't just docked to the bottom but is at the end of the list and will scroll with the list.


List and the scrollDock config


Ever since I was able to implement a router into Ext JS (beginning with 5.0.0) it has been one of the best feature adds for application developers. It may not be flashy or spoken about a lot but it one of those missing features that should be a requirement for single page web applications. If you don't have it in your Ext JS application, you should drop everything and implement it. :)

Using it a lot myself and hearing of others using it, there are a few improvements to the Router to make it much better. It's incredibly useful now, it can be much more useful. I'm currently rewriting the support portal (in internal testing currently) and Sencha Fiddle (almost ready for internal testing) and I'm testing some overrides for many of the improvements. One such improvement is implementing the listening of routes and the `redirectTo` method as a mixin so you can literally work with the Router in any class such as a utility singleton.

All the router functionality is meant to work within a controller whether if be a global controller (extending `Ext.app.Controller`) or a view controller (extending `Ext.app.ViewController`) and since I wrote it I knew it was all implemented in the `Ext.app.BaseController`. So all I have to do is get the code from `BaseController` onto a mixin class and Ext JS has a method that makes this extremely easy. You'll be surprised how easy this was:

```js
Ext.define('Ext.app.route.Mixin', {
    extend : 'Ext.Mixin',

    requires : [
        'Ext.app.BaseController'
    ],

    mixinConfig : {
        id : 'route'
    },

    config : {
        routes : null
    }
}, function(Mixin) {
    Mixin.borrow(Ext.app.BaseController, ['redirectTo', 'updateRoutes', 'getBefore', 'isActive']);
});
```

The important part here is the third argument I pass into `Ext.define` which is a callback method that gets called when the class I'm defining is defined. In this method, I use the [`borrow`](http://docs.sencha.com/extjs/6.0/6.0.0-classic/#!/api/Ext.Base-static-method-borrow) method which will take an array of strings that are members (can be methods or properties) to take the 4 methods from `BaseController` and apply them onto my mixin class. Now, any class I mix in this mixin class, they will get those 4 methods and therefore will be able to use the router as if the class was a controller.

Let's look at how to then implement it. First, this class needs to be placed where it can be loaded. For this, since I use Sencha Cmd for all my apps, there is a way to include this without requiring it. Any class placed in the `overrides` directory will automatically be included regardless if it's an override or not. So I place this class in the `overrides/app/route/Mixin.js` and after a `sencha app watch` (or a build or refresh) and this mixin will automatically be included in my app. I do this because when this gets implemented into the framework, I don't have to look for any requires throughout my app, I can just remove the file.

Next, we need to add the mixin into a class. For this I create a ViewRouter utility class for starters:

```js
Ext.define('Fiddle.util.ViewRouter', {
    singleton : true,

    mixins : [
        'Ext.app.route.Mixin'
    ],

    config : {
        routes : {
            'home'            : 'onHome',
            'view/:view:item' : {
                action     : 'onView',
                conditions : {
                    //make :item optional
                    ':item' : '(?:(?:/){1}([a-z]+))?'
                }
            }
        }
    },

    onHome : function() { /* */ },

    onView : function(view, item) { /* */ }
});
```

Just like you'd expect, you can listen for routes as if this singleton was a controller. You can also use `this.redirectTo('foo')` in this class to redirect the app to a hash also.

# Disclaimer

Writing about this here makes no promise of it actually being implemented into Ext JS. I do want to but do not make any promise of if or when. If implemented, this will be 100% backwards compatible with Ext JS 5 and 6 applications where you would be handling the routes within a controller.


Ext JS Router Mixin!


I have a need that I've solved before but have never been happy with my solutions. So today I decided to give it another go. It's taking hierarchical data (tree data) and saving it into a MySQL database. Searching around, there wasn't a solution that I liked. Some were SQL only but didn't seem to fit how I am presented with data. Some were using server-side frameworks, however, I'm not using any.

### Server Overview

When I said I'm not using any server-side framework it's not 100% true. I am using [ExpressJS](http://expressjs.com/) which is a framework but not in the sense of a framework that manages data; it's much more of a framework around creating a server. There isn't an MVC aspect of it. I've built my own framework to be custom to the projects I own within [Sencha](https://www.sencha.com/) and I name it node-sencha (not on npm currently) and reflects the API of Ext JS. So I basically have a pretty bare bones setup that I've built on top. For communication with my MySQL databases I use the [mysql](https://www.npmjs.com/package/mysql) module. I feel using ExpressJS and mysql module is a very common setup so I won't go into it more than just that. Technically, the mysql module isn't required for this but it's serving as an important piece on how I construct the SQL queries.

### Pre-Thoughts

I've seen some solutions that had some pros and cons and some of the cons were that it was very expensive. I control both the client (which is Ext JS) and the server so I can do things any way I want (some would be jealous, some would be scared :) ). Starting off I decided to go ahead and send the full tree when saving regardless of if the nodes had been changed or not. This is great for its total ease but something I'll definitely have to revisit at a later time to better the performance and not have unneeded queries.

For saving tree data you need to deal with creating, updating and deleting nodes. Since I'm going to have the full tree, this will be easy to do all three actions in a single MySQL transaction. The only hard part is dealing with the parent-to-child relationship where the parent may or may not already exist.

### Ext JS

When using `Ext.data.TreeStore` and the related classes, Ext JS will create IDs for each node that you create on the client. I can use this to determine if the node passed to the server is a phantom (does not exist in the db) or not. Ext JS does set the `phantom` property on the model but using the ID is a single way to handle create vs update. The data I send back to the server is like this:

```json
[
    {
        "id"       : "Model-1",
        "text"     : "Parent 1.1",
        "children" : [
            {
                "id"   : "Model-3",
                "text" : "Leaf 1.1"
            }
        ]
    },
    {
        "id"       : "Model-2",
        "text"     : "Parent 1.2",
        "children" : [
            {
                "id"   : "Model-4",
                "text" : "Leaf 1.2"
            }
        ]
    }
]
```

Each node is an Object in the JSON and each node can have a `children` property and can nest as many children. If we look at the `id` property, it's in a format that has the Ext JS model's class name and an auto-incremented number joined by a hyphen. This is Ext JS creating a client side ID for a phantom record. In the database, I expect only integers for IDs so if it's a string and has a hyphen, chances are it's a phantom. Right there is how I determine if the node needs to be created or updated. In the database I also have a `parentid` field in the table so that a child can relate to its parent. You can see there is no `parentid` because on the server I can just get it from when I iterate through things. The trick there is to determine if the parent is phantom or not and getting the ID when the parent is being created.

### Server Stuff

On the server, I pass the data to a `Tree` function and execute the `save` method on it:

```js
var Tree = require('./Tree');

new Tree(data).save(function() { /* */ });
```

In the `Tree.js` file, I start with code like this:

```js
var mysql       = require('mysql'),
    phantomIdRe = /-/g;

function Tree(data) {
    this.data    = data;
    this.sqls    = [];
    this.inserts = [];
    this.vars    = {};
    this.realIds = [];

    return this;
}

Tree.prototype.isArray = function(value) {
    return Object.prototype.toString.call(value) === '[object Array]';
};

Tree.prototype.isIdPhantom = function(id) {
    return typeof id === 'string' && id.indexOf('-') > -1;
};

Tree.prototype.parsePhantomId = function(id) {
    return id.replace(phantomIdRe, '_');
};

Tree.prototype.save = function(callback) {
    var data    = this.data,
        sqls    = this.sqls,
        inserts = this.inserts,
        tree;

    this.parseChildren(data);

    if (this.realIds && this.realIds.length) {
        //delete any nodes that were not passed
        sqls.unshift('DELETE FROM my_table WHERE id NOT IN(?);');
        inserts.unshift(this.realIds);
    }

    //execute the sqls
    console.log(mysql.format(sqls.join(''), inserts));

    callback();
};

module.exports = Tree;
```

Nothing special so far, the `isIdPhantom` function will do the checking if the id has a hyphen. The `parsePhantomId` will replace hyphens with underscores, more about that later. The `save` method is what really kicks things off. It first executes the `parseChildren` method which allows for recursion:

```js
Tree.prototype.parseChildren = function(children, parent) {
    if (!this.isArray(children)) {
        children = children.children;
    }

    var i        = 0,
        length   = children.length,
        parentid = parent && parent.id,
        node;

    if (length) {
        for (; i < length; i++) {
            node = children[i];

            this.parseNode(node, parentid);

            if (node.children) {
                this.parseChildren(node.children, node);
            }
        }
    }
};
```

The important part here is it'll call `parseChildren` if the current node has any children but also the new `parseNode` method which does the real "magic". Hope I'm not loosing you yet, here's `parseNode` and it's a little long:

```js
Tree.prototype.parseNode = function(node, parentid) {
    var sqls    = this.sqls,
        inserts = this.inserts,
        vars    = this.vars,
        id      = node.id,
        parentVar;

    if (parentid) {
        if (this.isIdPhantom(parentid)) {
            parentVar = vars[parentid];

            if (!parentVar) {
                //no variable means it wasn't a phantom
                parentVar = '?';
                inserts.push(parentid);
            }
        } else {
            //wasn't a phantom
            parentVar = '?';
            inserts.push(parentid);
        }
    } else {
        //is a root child node
        parentVar = '?';
        inserts.push(null);
    }

    if (this.isIdPhantom(id)) {
        sqls.push('INSERT INTO my_table (`parentid`, `text`) VALUES (' + parentVar + ', ?);');

        inserts.push(
            node.text
        );

        if (node.children) {
            id = this.parsePhantomId(id);

            //create the mapping of the phantom id to the SQL variable
            vars[node.id] = '@' + id;

            //use SET query to set the variable to the last inserted id
            sqls.push('SET @' + id + ' = LAST_INSERT_ID();');
        }
    } else {
        this.realIds.push(id);

        sqls.push('UPDATE my_table SET `parentid` = ' + parentVar + ', `text` = ?  WHERE id = ?;');

        inserts.push(
            node.text,
            id
        );
    }
};
```

So let's take this slowly. First, we have to check if the `parentid` exists for the sake of if the node has a parent or if it's a root child. This is also where we check if the parent is being created or updated. This also exposes the trick of handling create vs update, I use SQL variables. We'll talk about that more in a bit. If the parent wasn't a phantom (it already exists in the db) then we can set the `parentVar` variable to the `?` so that the mysql module can insert the parent's id into the ending SQL query. If the parent is a phantom, then we are going to use the assigned SQL query for the parent node.

Next, we handle the current node. We first check if the node's `id` designates it as a phantom or not. If it does then we add the INSERT SQL query to the array of queries but we use that `parentVar` that is either `?` or the SQL variable. If the node has children, then we need to assign that node a SQL safe variable (using the `parsePhantomId` method that replaces hyphens with underscores), cache that SQL variable to the `vars` Object for lookup in child nodes and then add the SET SQL query that will set the SQL variable to the last insert id from the last INSERT query. So now we see something like this:

```sql
INSERT INTO my_table (`parentid`, `text`) VALUES (?, ?);
SET @Model_1 = LAST_INSERT_ID();
INSERT INTO my_table (`parentid`, `text`) VALUES (@Model_1, ?);
SET @Model_3 = LAST_INSERT_ID();
INSERT INTO my_table (`parentid`, `text`) VALUES (@Model_3, ?);
```

So now you can start to understand what I'm building. Using SQL variables to cache that real last insert id in the db will allow the whole tree data to be saved to the db in a single transaction. Of course if the node already exists I use an UPDATE instead of an INSERT and of course I don't need to set a SQL variable since the parent exists. So I could have something like this if the first node existed:

```sql
UPDATE my_table SET `parentid` = ?, `text` = ? WHERE id = ?;
INSERT INTO my_table (`parentid`, `text`) VALUES (@Model_1, ?);
SET @Model_3 = LAST_INSERT_ID();
INSERT INTO my_table (`parentid`, `text`) VALUES (@Model_3, ?);
```

However with a node that already exists, I do cache the real id to the `realIds` array so that I can delete all existing nodes that do not match those IDs since I expect the entire tree data to be sent back to the server.

### Conclusion

I hope I didn't loose you, it can be hard to blog about something like this and not just dump a bunch of code on you. I wanted to show that with a single flat array of SQL queries you can save a hierarchical tree structured data in a way where it can account for if the node and its parent are already existing in the database or not with the use of SQL variables. I'm really enjoying the actual simplicity of this and is thus far really working well. Like I said at the start, I am sending the entire data tree back which isn't optimal but for a start is perfect. I'd have to deal with deletes and specifying the parent's id on the client with the nodes being sent to the server to help with the relationship.

Just in case the broken up code is a bit hard to follow, here is the `Tree.js` file I have:

```js
var mysql       = require('mysql'),
    phantomIdRe = /-/g;

function Tree(data) {
    this.data    = data;
    this.sqls    = [];
    this.inserts = [];
    this.vars    = {};
    this.realIds = [];

    return this;
}

Tree.prototype.isArray = function(value) {
    return Object.prototype.toString.call(value) === '[object Array]';
};

Tree.prototype.isIdPhantom = function(id) {
    return typeof id === 'string' && id.indexOf('-') > -1;
};

Tree.prototype.parsePhantomId = function(id) {
    return id.replace(phantomIdRe, '_');
};

Tree.prototype.save = function(callback) {
    var data    = this.data,
        sqls    = this.sqls,
        inserts = this.inserts,
        tree;

    this.parseChildren(data);

    if (this.realIds && this.realIds.length) {
        sqls.unshift('DELETE FROM my_table WHERE id NOT IN(?);');
        inserts.unshift(this.realIds);
    }

    //execute the sqls
    console.log(mysql.format(sqls.join(''), inserts));

    callback();
};

Tree.prototype.parseChildren = function(children, parent) {
    if (!this.isArray(children)) {
        children = children.children;
    }

    var i        = 0,
        length   = children.length,
        parentid = parent && parent.id,
        node;

    if (length) {
        for (; i < length; i++) {
            node = children[i];

            this.parseNode(node, parentid);

            if (node.children) {
                this.parseChildren(node.children, node);
            }
        }
    }
};

Tree.prototype.parseNode = function(node, parentid) {
    var sqls    = this.sqls,
        inserts = this.inserts,
        vars    = this.vars,
        id      = node.id,
        parentVar;

    if (parentid) {
        if (this.isIdPhantom(parentid)) {
            parentVar = vars[parentid];

            if (!parentVar) {
                //no variable means it wasn't a phantom
                parentVar = '?';
                inserts.push(parentid);
            }
        } else {
            //wasn't a phantom
            parentVar = '?';
            inserts.push(parentid);
        }
    } else {
        //is a root child node
        parentVar = '?';
        inserts.push(null);
    }

    if (this.isIdPhantom(id)) {
        sqls.push('INSERT INTO my_table (`parentid`, `text`) VALUES (' + parentVar + ', ?);');

        inserts.push(
            node.text
        );

        if (node.children) {
            id = this.parsePhantomId(id);

            //create the mapping of the phantom id to the SQL variable
            vars[node.id] = '@' + id;

            //use SET query to set the variable to the last inserted id
            sqls.push('SET @' + id + ' = LAST_INSERT_ID();');
        }
    } else {
        this.realIds.push(id);

        sqls.push('UPDATE my_table SET `parentid` = ' + parentVar + ', `text` = ? WHERE id = ?;');

        inserts.push(
            node.text,
            id
        );
    }
};

module.exports = Tree;
```


Saving hierarchical data in MySQL with Node.js


I'd like to first state that there are literally thousands of ways to handle this and is dependent on how you handle user sessions within your application.

### Simple Beginnings

In almost every Ext JS application I've built I've had to deal with user sessions. Most apps require login before entering the application (like the [support portal](https://support.sencha.com), new one on the way too!), some allow you to use parts of the app without a login (like [Sencha Fiddle](https://fiddle.sencha.com), new on on the way too!). At the start of the application I check to see if there is an active user session from the server. I personally use Ext.Direct to do this but I'll stick with a plain `Ext.Ajax` request:

```js
Ext.Ajax.request({
    url     : '/session',
    failure : function() {},
    success : function(response) {
        MyApp.user = Ext.decode(response.responseText);
    }
});
```

This code is simplified and not complete but what's happening is when the request succeeds decode the JSON and set it to the `user` property on the `MyApp` namespace. If the request fails (returning a 403 for example), there is no session. I'll state again, this code is simplified and not complete, just showing an example and saving it to `MyApp.user` for ease of retrieval. (and yes, you can use promises with Ext JS 6 instead of callbacks but that has nothing to do with this)

When an application starts, it may have a hash in the URI and therefore Ext JS is going to take action on it. This will likely be before the above `Ext.Ajax.request` is finished which would cause an issue. If the user is already logged in, then the route may be ok to execute but if there is no session, you need to prevent the route from executing and redirect them to the login. For this, I use the `before` config on my routes and check `MyApp.app` and take appropriate action. Here is a simple controller to show this:

```js
Ext.define('MyApp.view.MainController', {
    extend : 'Ext.app.ViewController',
    alias  : 'controller.myapp-main',

    routes : {
        'user' : {
            before : 'checkSession',
            action : 'showUser'
        }
    },

    checkSession : function() {
        var args   = Ext.Array.slice(arguments),
            action = args[args.length - 1];

        if (MyApp.user) {
            action.resume();
        } else {
            action.stop();

            this.redirectTo('login');
        }
    },

    showUser : function() {}
});
```

Inspecting this controller, we have a single route with the `before` and `action` configs. In the before, we get the action argument (it'll always be the last argument but some routes may have many arguments), check if `MyApp.user` exists and if so then resume the action. If it's not, we stop it and then redirect the app to the `#login` hash.

So now, the `user` route requires a user session. If you have a route that doesn't require a user session, you can simply remove not have the `before` config and it will execute regardless of the `checkSession` method.

**Side Note:** Each action would need to have the `before` config. We do have some feature requests to help in this area to have a single before action that will execute for all routes.

### More Advanced

That's great but a keen mind will understand that if the `Ext.Ajax.request` finishes after the `checkSession` method executes from an initial route execution, the action will be stopped regardless if that user session check was successful. Not good. For this I set a property signifying the app is ready and fire an event on the application instance. This way the `checkSession` method can tell if the app is actually ready to handle things. First, let's look at how the `Ext.Ajax.request` would be changed to do this:

```js
launch : function() {
    Ext.Ajax.request({
        url     : '/session',
        scope   : this,
        failure : function() {
            this.onUser();
        },
        success : function(response) {
            this.onUser(
                MyApp.user = Ext.decode(response.responseText);
            );
        }
    });
},

onUser : function(user) {
    this.appready = true;
    this.fireEvent('appready', this, user);
}
```

This would be code you can have in your `app/Application.js`. In the `failure` and `success` callbacks, I execute the `onUser` method. In this method, I set the `appready` property to `true` so anything can check `MyApp.app.appready` to see if it's ready. Along with the property, the application also will fire the `appready` event passing the application (it's a convention to pass the class firing the event as the first parameter) and the user if one was set. So now we can react to both the property and event in our `before` action:

```js
checkSession : function() {
    var me     = this,
        args   = Ext.Array.slice(arguments),
        action = args[args.length - 1],
        app    = MyApp.app;

    if (app.appready) {
        if (MyApp.user) {
            action.resume();
        } else {
            action.stop();

            me.redirectTo('login');
        }
    } else {
        app.on(
            'appready',
            Ext.Function.bind(me.checkSession, me, args),
            me,
            { single : true }
        );
    }
}
```

In this new `checkSession` method I do a few things. First I set an `app` variable to `MyApp.app`, this is your application instance where we set the `appready` property. If the `appready` property is `true` then we know the user session check has already happened and therefore we can check the `user` property and resume/stop the action. If the `appready` property is `false` then we need to add a listener to the `appready` event. The reason I use `Ext.Function.bind` is because I need to control what arguments are passed when the event is fired so that the `action` argument is the last argument. With this function binding, I know the arguments will be the same as when it originally was executed. And lastly I make sure that when the event is first listened to it will remove itself with the `single` event option.

So now if the `MyApp.app.appready` property is `false`, the user session request is still happening. When that request finishes, successful or not, the `checkSession` method listen for the `appready` event to fire signifying the user session was completed.

###Even More Advanced

To go a step further, I often have to deal with different user types like normal user and admin. Admins should have access to certain parts of the application a user should not and therefore we need to stop a user trying to gain access. For this, I have a separate method that will look like `checkSession` but will check what kind of user is present:

```js
checkIsAdmin : function() {
    var me     = this,
        args   = Ext.Array.slice(arguments),
        action = args[args.length - 1],
        app    = MyApp.app;

    if (app.appready) {
        if (MyApp.user) {
            if (MyApp.user.user_type === 'admin') {
                action.resume();
            } else {
                action.stop();

                me.redirectTo('home');
            }
        } else {
            action.stop();

            me.redirectTo('login');
        }
    } else {
        app.on(
            'appready',
            Ext.Function.bind(me.checkSession, me, args),
            me,
            { single : true }
        );
    }
}
```

In this before action the difference is within the first conditional. If `MyApp.user` is `truthy` then we need to check the type of user. If the user is an admin, resume the action. If not, stop the action and send the user back to `#home`. Now, to not have duplicate code you can have a shared method:

```js
handleSessionCheck : function(beAdmin, args) {
    args = Ext.Array.slice(args);

    var me     = this,
        action = args[args.length - 1],
        app    = MyApp.app;

    if (app.appready) {
        if (MyApp.user) {
            if (!beAdmin || MyApp.user.user_type === 'admin') {
                action.resume();
            } else {
                action.stop();

                me.redirectTo('home');
            }
        } else {
            action.stop();

            me.redirectTo('login');
        }
    } else {
        app.on(
            'appready',
            Ext.Function.bind(me.handleSessionCheck, me, [beAdmin, args]),
            me,
            { single : true }
        );
    }
},

checkSession : function() {
    this.handleSessionCheck(false, arguments);
},

checkIsAdmin : function() {
    this.handleSessionCheck(true, arguments);
}
```

As you can see, `checkSession` and `checkIsAdmin` both simply execute the `handleSessionCheck` method but pass whether or not the user is required to be an admin and the arguments. `handleSessionCheck` looks very similar to the old `checkIsAdmin` method except for a couple different changes. First is the conditional check the user type, it first checks if `beAdmin` is falsey, if so then it will allow the route to be resumed other wise it'll check if the user is an admin. The other change is to the `Ext.Function.bind` in the `appready` event listener. I changed the function being bound and also the third argument is now an array of the `handleSessionCheck` arguments. This allows code reuse in a dynamic fashion which is good!

### Conclusion

Being able to handle user sessions with routes really isn't hard but there isn't a decent example that I've seen. The code snippets I provided are simplified but should show the techniques I employ in my Ext JS application.


Handling user session with routes


A common request I hear from many people is how to delay the application's `launch` method from being executed. First, let's investigate the problem. Say you have a normal `app/Application.js` that looks like:

```js
Ext.define('Fiddle.Application', {
    extend : 'Ext.app.Application',

    name : 'Fiddle',

    stores : [
        'Store1',
        'Store2',
        'Store3'
    ],

    launch : function() {
        var store1 = Ext.getStore('Store1'),
            store2 = Ext.getStore('Store2'),
            store3 = Ext.getStore('Store3');

        console.log('store1 isLoaded', store1.isLoaded());
        console.log('store2 isLoaded', store2.isLoaded());
        console.log('store3 isLoaded', store3.isLoaded());

        Ext.Msg.alert('Fiddle', 'All stores are loaded!');
    }
});
```

In the `launch` method you have some code that depends on the stores being loaded. Ok, this example just has some `console.log`s so use your imagination some. I could add logic to the launch method and execute some other method on this class sure but there may be a more elegant way. If you were to run this right now, your `Ext.Msg.alert` would happen but all the `console.log`s would show `false` for the `isLoaded` method calls because the load hasn't happened yet. So what we need to do is add `load` listeners to the stores and only execute the `launch` method when all stores have loaded.

What I like to do is keep `app/Application.js` looking like it is and create an override on the `Ext.app.Application` class. What this override will do is change the `launch` method so that we can check if the stores have loaded. When they have all loaded, then execute the original `launch` method.

Let's take a look at a [Sencha Fiddle](https://fiddle.sencha.com) as an example:

<iframe style="border:0;width:600px;height:600px;" src="https://fiddle.sencha.com/fiddle/pq4"></iframe>

Looking at the different files, we have the 3 stores defined. `Store1` and `Store3` have `autoLoad` set to `true` but `Store2` does not so we only need to wait for `Store1` and `Store3` to load.

If you want, you can take a peak at `overrides/app/Application.js` to see how I take control of the `launch` method. Here's a rundown. The `launch` method gets transformed in the cleverly named `transformLaunch` method into a function that checks if all stores are loaded. The other method that is important is the `isStoreLoaded` method, this is important because this tells the override if the store has loaded in order to add the `load` listener and to tell if all stores have loaded. You may need to add additional logic dependent on your application's situation. If you need to modify that logic, I like to keep the override like it is and add that logic into my `app/Application.js` class so the logic is upfront in the app.


Delaying launch for stores to load


&lt;rant&gt;

I for one, love updating an app and seeing a new major version released. It's like Christmas morning, what new goodies am I gonna get to enjoy?! In the case of some apps like Chrome and Firefox, a new major version may just be some bug fixes... (sadpanda)

Don't get me wrong, I love that Chrome and Firefox are being agile and releasing often on a schedule but why change the major version if nothing is big enough to dictate a new major version. To me, a new major version should have a few big new features or enough rewrite under the hood to deserve such a version. Why not use a dot release so instead of Chrome 43 it'd be something like Chrome 4.27 or something like that? So when Chrome 5 comes out, you know there was something major has happened.

If I created a browser extension that relies on some feature but that feature was added in... crap, what version again? Oh, Chrome 243. Ok cool... Knowing that Chrome 6 added the feature is a lot easier to remember.

Small potatoes huh? Yes and no. Yes, knowing something changed in version 6 versus 243 is just a different number but maybe version 6 brought many changes whereas version 174, 243 and 257 brought the changes so now you can only target 257+. What if version 6 replaced V8 with something new? That should definitely be a new major version that is distinguishable right? Nah, it's version whatever.

Man, I woke up on the nitpicking side of the bed today.

&lt;/rant&gt;


The death of major versions?


Since Ext JS 4 came out, Ext JS supported loading classes on demand during development. You do this using the [`requires`](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext.Class-cfg-requires) property in your [`Ext.define`](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext-method-define) statement or using [`Ext.require`](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext-method-require). Furthermore, ever since Sencha Cmd was released, it will check out these means of requiring classes and create a build of only those classes that are required.

### `requires` property

As mentioned, when using `Ext.define` you should use the `requires` property to require classes. Let's look at a sample class without the requires property:

```js
Ext.define('MyApp.view.user.Form', {
    extend : 'Ext.form.Panel',
    xtype  : 'myapp-user-form',

    items : [
        {
            xtype : 'fieldset',
            title : 'Details',
            items : [
                {
                    xtype      : 'textfield',
                    fieldLabel : 'Name',
                    name       : 'name'
                },
                {
                    xtype      : 'textfield',
                    fieldLabel : 'Email',
                    name       : 'email',
                    vtype      : 'email'
                }
            ]
        }
    ]
});
```

If we use this class in our application things may work depending on if the classes are required elsewhere. However, your application will be changing as time goes on so this may work now but may break a production build later. For this reason, I tend to make sure each class requires that classes it uses. The requires property would then look like this:

```js
Ext.define('MyApp.view.user.Form', {
    extend : 'Ext.form.Panel',
    xtype  : 'myapp-user-form',

    requires : [
        'Ext.form.field.Text',
        'Ext.form.FieldSet'
    ],

    items : [
        {
            xtype : 'fieldset',
            title : 'Details',
            items : [
                {
                    xtype      : 'textfield',
                    fieldLabel : 'Name',
                    name       : 'name'
                },
                {
                    xtype      : 'textfield',
                    fieldLabel : 'Email',
                    name       : 'email',
                    vtype      : 'email'
                }
            ]
        }
    ]
});
```

Now I know that no matter what else goes on in my application, this class will be safe as far as what it needs.

Remember, your `MyApp.Application` class can use the requires property also for any classes that need to be there for startup. For example, that's where I put my [utility singletons](https://sencha.guru/2015/03/23/use-of-a-base-url-in-a-utility-class/).

### `Ext.require`

If you're not using MVC/MVVM and therefore don't have an Application class, well, first shame on you! Ext JS doesn't require the MVC/MVVM pattern but I very much recommend it. Anyway, to require classes before `Ext.onReady` executes you can use `Ext.require` to require classes much the same way:

```js
Ext.require('Ext.form.FieldSet');
// or use an array:
Ext.require([
    'Ext.form.field.Text',
    'Ext.form.FieldSet'
]);
```

### `requires` vs `uses`

The `requires` property will ensure those classes are loaded and defined before the class being required is defined. Cmd will use the `requires` to build a dependency map and include the files in order based on the requires. However, in development the `requires` property may cause synchronous loading so that your code will work (this depends on if `Ext.onReady` or `Ext.application`'s [`launch`](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext.app.Application-method-launch) method has executed) which can slow things down. This is where the [`uses`](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext.Class-cfg-uses) property can be used. This is what the `uses` property looks like:

```js
Ext.define('MyApp.view.user.Form', {
    extend : 'Ext.form.Panel',
    xtype  : 'myapp-user-form',

    uses : [
        'Ext.form.field.Text',
        'Ext.form.FieldSet'
    ],

    items : [
        {
            xtype : 'fieldset',
            title : 'Details',
            items : [
                {
                    xtype      : 'textfield',
                    fieldLabel : 'Name',
                    name       : 'name'
                },
                {
                    xtype      : 'textfield',
                    fieldLabel : 'Email',
                    name       : 'email',
                    vtype      : 'email'
                }
            ]
        }
    ]
});
```

The difference between `uses` and `requires` is unlike how `requires` will load it's classes before the `MyApp.view.user.Form` is defined, `uses` will define `MyApp.view.user.Form` even if the classes are not loaded. `Ext.form.field.Text` and `Ext.form.FieldSet` may be loaded and defined after `MyApp.view.user.Form` is defined since `MyApp.view.user.Form` doesn't require them to be loaded before it is defined.

### Many requires

Requiring a class many times will not affect performance, if a class is already defined it will not be loaded again and will be skipped. Also, requiring classes on the fly like this is only for development. When you do a build with Sencha Cmd, Cmd will remove these automatically for you so in a production build this code will simply not be there. So I play it safe and add all the classes in the requires.

I will say that having knowledge of what classes are then requiring other classes helps. So if I require `Ext.form.field.Text`, I know that it already requires `Ext.form.field.VTypes`. Since I use the `vtype` config, I do need `Ext.form.field.VTypes` to be loaded but my code doesn't have to require it since `Ext.form.field.Text` is already requiring it. The [API docs](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext.form.field.Text) denote what it's requiring on the right.

### Other means of requiring

Ext JS also has other means of requiring classes for you. If you [extend](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext.Class-cfg-extend) a class, Ext JS will require that class for you as expected. If you define [`mixins`](http://docs.sencha.com/extjs/latest/apidocs/#!/api/Ext.Class-cfg-mixins), those too will also be required for you.


Requiring classes


Recruiters... more precisely tech recruiters... You are a necessary evil but there is a right way and a wrong way to go about recruiting. First off, my hat is off to you for doing your job, I could never do it. The few I've talked to in person have been actually great conversations. I'm not sure if it's because of your job or if you're really that way but that part of recruiting I enjoy even if I'm not interested I'm still involved in a great conversation.

### Email > Phone

There are many ways to get ahold of someone: email, phone call, LinkedIn, etc. Many people like me prefer email for many reasons. It's easy to ignore and it's easy not to be distracted. I hate getting a phone call because I am likely in the middle of something (probably my job which I don't want to spend company time talking to a recruiter) and I have now been conditioned to not answer unknown numbers. What if the phone call is an emergency now? Well, I hope if it's an emergency they will use a phone already in my contacts or else I won't answer it. Please leave a message and I'll get back to you as soon as I can.

### Story Time!

I wanna tell you of a recruiter that just tried contacting me in order to show how not to recruit. I didn't talk to the person because of how aggressive this person was at trying to get ahold of me. I received 3 emails (on different email addresses I have), LinkedIn message, Facebook message and 3 phone calls on the same number each call with an associated voicemail. Let's break each down:

**3 emails** - I have many different email addresses but they are all very similar enough so that you definitely know they are the same person. My last name isn't a common last name, it's me. Each email was the same thing just copied and pasted into a new email. The email was poorly formatted, spelling and grammar errors (which I make my fair share of also) and impersonal. If you really were interested in me, you'd have a professional looking email at least somewhat tailored to me. Oh, and you wouldn't go spamming every email address you can find.

**LinkedIn** - This is very much like an email. I get LinkedIn is a great place to find someone, in fact it's a great place. Except the amount of recruiters out there searching for keywords. I'm not sure if you actually read what I have up there or not but I get the feeling you search for a term and you message those who match.

**Facebook** - I have my Facebook profile private, I don't want the general public to know what's going on in my private life. So if I have my profile private, it means I'm not wanting to get spammed by people wanting to recruit me or anything. It's for my friends and family, this is not a great way to get ahold of me for an open position.

**Phone calls** - Like I said before, I hate recruiters calling me. The person trying to contact me tried calling me 3 times back-to-back as if the person was a teenage girlfriend I was ignoring. No joke, just got a fourth round. You have been blocked now with the voicemails deleted without listening to them. What do you think is going to happen? I'm magically going to answer one after your persistence? You think I'm in a happy mood that you keep calling me so much and it's going to be a good conversation now? STOP!

### Conclusion

Like I said before, recruiters are a necessary evil. We need recruiters, they are crucial. But there is a wrong way to recruit and I see the same mistakes over and over. I wonder what their success rate is with these practices.

My friend Arthur Kay also has an open letter I'd like to point you too: http://www.akawebdesign.com/2013/11/20/open-letter-tech-recruiters/

**P.S.** Oh, and if you do get to talk to me and I am not interested, I do not wan to do your job. If I know of someone looking for a job that I would recommend, I'm hiring. Even if I wasn't hiring, can I have your cut for finding someone since I was the one who found someone?


How Not To Recruit


For the last year, I've lived in Florida. In this year, my training has been quite different than it did in Missouri (where I lived prior). Why? Read on.

## Hot and humid

Of course I expected it to be hot but this has had an immense affect on my running. Missouri still got hot and humid during the summer but it wasn't for as long as in Florida. I live in the northern part of Florida so for 3 months it was in the 30s and 40s which is perfect weather for me, especially for running. The other 9 months it's hot and humid. In Missouri, it still got hot but was only for a couple months in the summer. So I have summer a half a year extra now.

So why does this matter? Do you get used to it? Current, I start running between 8am and 9am trying to get running before the heat of the day, except it's already hot and humid at that time. I have to take more breaks to rehydrate, within the first mile my hat is already soaked.

Today's run was 6 miles and I drank an entire gallon of water but I still achieved my goal. This is my Endomondo recording of today's running:

<iframe src="https://www.endomondo.com/embed/workouts?w=lDwfVxKp4N8&width=580&height=600" width="950" height="600" frameborder="0" scrolling="no"></iframe>

As you can see, I run in circles with each circle being just under a mile (for my training, I'm ok with rounding up). But each lap has a good sized hill and some smaller ones, this is the reason I do love running on a trail.

## Type of soil

The type of soil is quite different between Missouri and Florida. In Missouri you would find a more clay like soil; in Florida it's a sandy soil. Florida's soil is much harder to run on as it's often more loose. The looser the soil, the more effort it takes to push off on which makes the run harder.

That big hill I run up on each lap is of this loose soil, I'm actually amazed that I'm able to run up it over and over and keep a decent pace. Along with the sandy soil, we have a ton of roots on top of the soil. I'm not sure if this is because of the soil and such or if the soil got washed away but I always have to look down to watch out for these roots. It's not just a trip hazard, it's also how you land on them if you do. If the front of your foot lands on it and you're not expecting it, expect for your momentum to be halted and be very hard to have a natural foot movement which can cause injuries. I definitely learned to not only watch for the natural holes in the earth.

## Conclusion

So running in Florida has new challenges that I'm still trying to get used to. It is hard but luckily I've been able to have my determination to succeed motivate me.


I hate running in Florida


Software is and always will be buggy, let's be honest. While being honest, Ext JS certain isn't bug free. So if you're like me, you may come up on a bug or two while developing an application. Most of the time, the bugs I encounter I find a way to create a patch (an override) to fix the bug whether it's from my own debugging or since I have access to out git repo I can extrapolate the fix.

Before I go on, it's good practice to remove your overrides when you upgrade the Ext JS SDK. Test your app and then apply the ones that are still needed and remove the ones that are not. Your overrides should be well documented so that when you come back to them you know what's going on with the override and what bug(s) the override is fixing.

We're human, we make mistakes, we forget things, we rush things. Ext JS actually has a property that will control what maximum version an override should be applied to. Say a bug existed in 5.0.1 but is fixed in 5.1.0, you only want the override to be applied to 5.0.1 (and older) and not to 5.1.0. The property is called `compatibility` and it's usage is like so:

<iframe src="https://fiddle.sencha.com/fiddle/l8j" style="border: 0; width: 600px; height: 600px;"></iframe>

The fiddle is set to use the 5.0.1 and therefore you should be able to see the `Ext.Msg.alert` over the panel. If you open the fiddle in the [Fiddle](https://fiddle.sencha.com/#fiddle/l8j) app and change the framework version to a 5.1.0 release, you should not see the `Ext.Msg.alert` because the override is set to only apply to 5.0.1 and older.

So like I said before, you should always evaluate your overrides when you upgrade your Ext JS SDK. The `compatibility` property can help not apply overrides on versions after you know the bug was fixed but I even if I know I'm going to be diligent with my override evaluation, I still like to put it in there even just for documentation sake. Nothing wrong with extra documentation!


Override Compatibility


I had an idea the other day and I'm not sure why I hadn't thought of it sooner. For the longest time I've always advocated to have a singleton utility class that holds onto configs like a base url. Then in your store, you can get the base url and prepend it. Something like this:

```js
Ext.define('MyApp.Util', {
    singleton : true,

    config : {
        baseUrl : 'http://foo.com/'
    },

    constructor : function(config) {
        this.initConfig(config);
    }
});

Ext.define('MyApp.store.Foo', {
    extend : 'Ext.data.Store',
    alias  : 'store.myapp-foo',

    requires : [
        'MyApp.Util',
        'MyApp.model.Foo'
    ],

    model : 'MyApp.model.Foo',

    proxy : {
        type : 'ajax',
        url  : MyApp.Util.getBaseUrl() + 'foo.json'
    }
});
```

When the `MyApp.store.Foo` class is loaded by the browser, that `MyApp.Util.getBaseUrl()` is automatically evaluated and if you had `MyApp.Util` loaded prior to the store being loaded, it will concat the `http://foo.com/` and `foo.json` and everything is good. The biggest drawback to this was that you had to require the `MyApp.Uti` class in both the `Ext.application` and the store's `requires` array. (side note, Sencha Cmd may be able to detect `MyApp.Util` but I've seen where this falls down so I'm usually more explicit with my `requires` array) Also, in your code you have to spread the `MyApp.Util.getBaseUrl()` calls around everywhere.

Instead, I had a thought to make this workflow much easier! What if you were able to define your store like this?

```js
Ext.define('MyApp.store.Foo', {
    extend : 'Ext.data.Store',
    alias  : 'store.myapp-foo',

    requires : [
        'MyApp.model.Foo'
    ],

    model : 'MyApp.model.Foo',

    proxy : {
        type : 'ajax',
        url  : 'foo.json'
    }
});
```

No requiring `MyApp.Util`, no `MyApp.Util.getBaseUrl()` spread everywhere. Looks like I can solve both my caveats right? But how can I get the base url in there? Just by this code, there isn't anything that will prepend it. Where's the magic?

The magic is all in the `MyApp.Util` class with a small change. `Ext.data.Connection` (`Ext.Ajax` is an instance off) will fire a `beforerequest` event allowing you to cancel the request or you can also modify the request by changing the params but you can also change the url of the request. So why not have `MyApp.Util` automatically prepend the baseUrl for us? Like so:

```js
Ext.define('MyApp.Util', {
    singleton : true,

    config : {
        baseUrl : 'http://foo.com/'
    },

    constructor : function(config) {
        this.initConfig(config);

        Ext.Ajax.on('beforerequest', this.onBeforeRequest, this);
    },

    onBeforeRequest : function(connection, options) {
        options.url = this.getBaseUrl() + options.url;
    }
});
```

All I did was add the `beforerequest` event listener, and then changed the `options.url` and it will automatically prepend the base url. Here it is in action:

<iframe src="https://fiddle.sencha.com/fiddle/k2p" style="border: 0; width: 600px; height: 600px;"></iframe>

Notice this will of course work with `Ext.Ajax.request` calls, this is what `Ext.data.proxy.Ajax` does under the hood anyway.

There is always a better way to do things and always many different ways to do things. There are more performant ways to do this but I like this approach as it's very logical to me in how it works. I can come back to this code in 2 years and easily pick up what I was doing.


Use of a base url in a utility class


Last year, I decided to set some goals for myself ([read more](https://mitchellsimoens.com/tough-mudder-looking-ahead-for-2015/)). I decided to sign up for several Tough Mudders throughout the year in order to push my health, I need goals and deadlines and nothing matches signing up for something and paying cold, hard earned cash to motivate you.

This last weekend was the first Tough Mudder of the 2015 season and I was excited. I ran a Warrior Dash (5K OCR) a month ago and to be honest, I didn't do as well as I wish I would have. The reason, I didn't workout for nearly 2 months over the winter! But since mid-January I was in cardio mode getting my mileage back up. I found a nearby trail that is a mile loop and even has a very good sized hill. I average about 11 minute miles which I'm fine with. I don't need to be faster, I just need to make 8 mile trainings easier. Found another trail but I decided I don't like being within 20 feet of these [guys](https://scontent-dfw.xx.fbcdn.net/hphotos-xpf1/t31.0-8/1939590_575706843357_4309501008577952709_o.jpg). Yes, that's an actual picture taken from my phone, first ran by them and was 10 feet away and scared the crap out of me. You would have laughed at me jumping away at first sight. Not sure if I screamed like a teenage girl at a Bieber concert but I sure as hell did internally. :)

Tough Mudder announced some new obstacles and improvements to current ones. I'll tell you about my experience with some of the new ones in a minute. If you want to see their promo video:

<iframe width="560" height="315" src="https://www.youtube.com/embed/Jim-ksScOoc" frameborder="0" allowfullscreen></iframe>

**The Day**

Link to course map [here](https://toughmudder.cachefly.net/sites/default/files/Gulf%20Coast%20Spectator%20Map%20Front%20V2.pdf).

I booked a hotel that was just a mile away. To warm up, I almost just ran the mile but didn't want to get carried away with it. I got there at 9am and got signed in, registered for the legion (Tough Mudder thinks I've done 8 mudders, I corrected them) and dropped by bag off. Got to the start area where they had an MC I hadn't seen before but once he was done doing his warmup talk they told us to go to the warm up area. This is where you climb a wall to get into the real start line and lucky enough, the man himself, Sean Corvelle was the MC! Love that guy! HOORAH! (he doesn't actually say "OOH-RAH", he doesn't feel like he should as he isn't or has not served in the military).

First 3.5 miles were mostly running, [Kiss of Mud](https://toughmudder.com/content/kiss-mud-20%C2%AE) and [Birth Canal](https://toughmudder.com/content/birth-canal) were conquered without any issue. Birth Canal is new and the water on top of you was surprisingly heavy at the end but nothing bad.

The next obstacle was the improved [Funky Monkey 2.0](https://toughmudder.com/content/funky-monkey%E2%84%A0-20). The old Funky Monkey was just an inclined and declined ladder. The new Funky Money added a trapeze grab in the middle that swung so you can transfer to the declined pipe. Getting to the Funky Monkey obstacle was the biggest gripe I have about the Tough Mudder, I waited in line for over an hour, no joke! There are two issues with this obstacle: only have 5 stations (they need to double this) and people getting stuck on the trapeze and don't want to give up took up a bunch of time. I don't mind them not wanting to give up, I wouldn't. Females had a lot of trouble with this obstacle as it does require a lot of upper body strength (shoulders and gripe strength is what I felt). I was intimidated by the transition from the trapeze to the pipe but I handled it with ease luckily. Keep one hand on the ladder and the other on the trapeze and start swinging before letting go to get momentum to grab the bar with the loose hand. Besides the hour wait, this was lot of fun!

After finishing the Funky Monkey I was behind these two girls, one made it through, the other got the water. Oh, by the way, the water was freezing! She was complaining that it's cold until I reminder her that [Arctic Enema 2.0](https://toughmudder.com/content/arctic-enema%C2%AE-20) was next. This is the ice bath and the improvement was you slide down into the ice and wade through ice. You have to climb over a wall and then wade through more before you're out. This is always a complete system shock.

The next obstacle was [The Liberator](https://toughmudder.com/content/liberator) which is brand new for 2015. This is where you walk up an inclined wall using wooden pegs. I quickly deciphered what to do but seems people were having a hard time so I started barking orders. I know, probably not the best way to come off but it was to help. You get two wooden pegs and there are two stationary metal ones at the top. At the top there is a slot to put the wooden pegs and they fall to the bottom. So use the wooden ones till you can reach the metal ones. Take one wooden peg and drop it in the slot. The person behind you takes the peg you dropped and puts it so you can stand on it so that you can then deposit the other one and push off with your leg to get ahold of the top so you can lift yourself up.

Same thing with [Beached Whale](https://toughmudder.com/content/beached-whale) which was next obstacle and also new to 2015. One person puts hands down or their knee so someone can get a good jump to get on top of the inflatable. Once on top you spin around and throw a hand down to help the next person. Team work people!

Next few obstacles were [Skidmarked](https://toughmudder.com/content/skidmarked), Warrior Carry and Tube Hurdles. Nothing big but the Warrior Carry was through chest deep water which added a degree of difficultly since you can't see what you're stepping on or if it's a hole to China.

Next up was another new obstacle, [Balls Out](https://toughmudder.com/content/balls-out). This new one was an A frame (one side had plexiglass which was harder and the side I attempted) and you tried to grab ropes that were spaced out, thankfully I have long arms. The difficulty here was coordinating everything but the trick seemed to keep your feet as planted on the wall as possible so you have full gripe or else you'd just slide down. So pray your gripe strength in your hands hold up as you move back and forth reaching for the next rope. And like the Funky Monkey, this had a long line and was there for about 30-45 minutes, ugh!

Then it was a long run to [Everest 2.0](https://toughmudder.com/content/everest-20). Everest has always been intimidating to me so when I heard they improved it by getting rid of the edge in favor of a rounded edge so you can't grab it and pull yourself up and it was taller, I was worried, I won't even lie. I thought the rounded edge was just in sections as it shows in the video/pictures but no, it's the entire length. So I grabbed a quick breath and ran my ass up it. Luckily there were two hands thrown down to help me, team work! So I relieved one of them and threw my hand down to the next person. I did see some people run up without any help, good for them!

Little run to the next obstacle that my friend [Arthur Kay](http://www.akawebdesign.com/) has been vocal to not liking obstacles like this: [Cry Baby](https://toughmudder.com/content/cry-baby) (kind of ironic huh Art? :P). This obstacle is going through a tent filled with "tear gas". It's not tall so you have to bear crawl through and go over a little wall. When I heard tear gas, I instantly knew it wasn't going to be the same tear gas that police and military use, that'd kill the rest of the run. So I bear crawled through and about 2/3s the way through I started to choke on it because it was a bit thick. It tasted and smelled very menthol, it was like a very strong Vicks VapoRub. Benefit after this, my sinuses were extremely clear! Back to running!

Next obstacle was the [Mud Mile 2.0](https://toughmudder.com/content/mud-mile-20) and Rope Climb. So the Mud Mile did have deeper mud but that wasn't the hard part here. The hard part is the type of soil we have in Florida, it's very sandy. Through the whole course, the soil was very sandy and in spots it was loose sand which makes running quite difficult. Where the Mud Mile was, it was this giant what looked to be old strip mine. It was 1.5 miles of 10 (or so) loose sand hills in this giant hole in the ground. This is where my time dropped quite a bit and some good charlie horses came on.

Getting the hell out of there was [Pole Dancer](https://toughmudder.com/content/pole-dancer-0) and [King of the Swingers](https://toughmudder.com/content/king-swingers). Pole Dancer wasn't hard past times I've done it but my arms were shot and at the very end my arms gave out and down I went. I caught myself by it felt like I pulled a muscle in my shoulder. Then I get to King of the Swingers and you climb up (which it seemed much higher in person than in the video, not sure if it is higher up in person but it seemed like you were on the 3rd floor of a building), jump and catch a bar, it swings up and you try to hit a bell and then fall in some water. There used to be an obstacle where you just jump off a platform so this seems like an updated version with the swinging. Hitting the bell isn't easy either. You have to pull yourself up while you are swinging so you get some extra lateral momentum. I also saw people doing flips and such off this thing. It was hell of a lot of fun. I usually don't do the best with heights but I didn't hesitate and just went for it!

The last obstacle was [Electroshock Therapy 2.0](https://toughmudder.com/content/electroshock-therapy%C2%AE-20) but first I went through the Legionnaires Loop which for this one was [Dead Ringer](https://toughmudder.com/content/dead-ringer). I will admit, I fell many times. My arms were shot at this point! The Electroshock Therapy was last thing. There was a little line but was only like 10 people. With no clouds in the sky, I was ok with a few people going before me however, right before I went a guy got a charlie horse trying to go over the first hay bale wall and laid on top of it. It took a few seconds for the medic to get to the kill switch as the guy laid there getting shocked. You can hear the pop and see the guy jerk as he got shocked, poor dude! I ran through it with no real problems, got hit 4 times.

Then the finish line! I made it. Went to get my blue head band and did the [Fire in your Hole](https://toughmudder.com/obstacles/fire-your-hole) obstacle that was in the Mudder Village. This was a big water slide through some flames (flames never touch you) and it was just for fun and a good cleaning.

So all in all, I was worried about mylack of training but until that hold in the ground where the Mud Mile was I did very great, I impressed myself there. The sun got to me, my head has a hell of a sun burn but I also recorded my fastest Mudder at 2.5 hours for 11.41 miles ([link to Endomondo recording](https://www.endomondo.com/workouts/482071646/2469121)). And had to drive home for 4 hours right after which was not a good idea.

**Next**

Next up is the Chicago Mudder in May which is 2 months away and am doing it with Arthur Kay and Jay Garcia. I need to keep my running up but I can limit it to 8 miles but just want to make that 8 miles easier. I also need to work on gripe strength and shoulders. Will be a Mudder machine then! I think 2 hours flat is possible but that will be very tough and doing it with Art and Jay, I won't try to go my fastest. I'll do Chicago to complete it with my friends even if I feel it's slow I'd rather finish with them. There is a Mudder in Tennessee the week after that I can go for gold.


Tough Mudder 2015 - Gulf Coast


When I design an endpoint to return some JSON data for consumption in a grid, I always nest the data in the `data` property so that I can provide a total count in order to support pagination. So most of my server side scripts are setup to nest data. Something like this:

```json
{
    "success": true,
    "total": 4375,
    "data": [...]
}
```

I setup my store to read this via something like this:

```js
Ext.define('MyApp.view.Foo', {
    extend : 'Ext.data.Store',

    proxy : {
        type   : 'ajax',
        url    : '/foo',
        reader : {
            rootProperty : 'data'
        }
    }
});
```

However, when using `Ext.data.TreeStore`, it wants to use the same property to find the children of nodes. By default, it uses the `children` property and you can change this by using the `rootProperty` like we have above (there are a couple different ways really). So if you have your nodes nested within the `data` property but still use `children` to have your child nodes in, it won't find any child nodes because you have two different roots, `data` and `children`.

So how can we handle this use case? Well, first I'd say fix your server to not nest the data so that things will work great within Ext JS. But let's be real for a second, the people in charge of your server-side code are likely a bit reluctant to change. You can buy them a steak dinner and they may still not change, you just have to deal with it.

Don't worry, Ext JS actually has a way to handle this. If you look at the [documentation](http://docs.sencha.com/extjs/5.1/5.1.0-apidocs/#!/api/Ext.data.reader.Reader-cfg-rootProperty) for the `rootProperty` config it says that it accepts a string for a value. Well, that's not entirely true and the docs will get fixed to reflect this but the `rootProperty` can actually accept a function and you return child nodes from the data provided. Let's look at some sample data:

```json
{
    "data" : [
        {
            "text"     : "Foo",
            "expanded" : true,
            "children" : [
                {
                    "text" : "Bar",
                    "leaf" : true
                }
            ]
        }
    ]
}
```

So we have our child nodes nested within the `data` property but we also use `children` to denote our child nodes. We can define out `rootProperty` to work with this like:

```js
rootProperty : function(node) {
    return node.data || node.children;
}
```

With this it returns `node.data` if it's truthy or it will return `node.children`. So if `data` exists, return it, else return `children`. It's as easy as that! Here's a live [fiddle](https://fiddle.sencha.com/#fiddle/iga):

<iframe src="https://fiddle.sencha.com/fiddle/iga" style="border: 0; width: 600px; height: 600px;"></iframe>


rootProperty as a function!


I've been an [IntelliJ IDEA](https://www.jetbrains.com/idea/) user for 4 years now but I usually have most features turned off but it's a memory hog, the constant indexing and overall sluggish performance has been annoying me for quite some time. I was turned onto [Adobe Brackets](http://brackets.io/) a couple weeks ago by Seth Lemmons (fellow Senchan). Right out of the gate, I knew it wasn't going to be feature rich like IDEA which is good and bad. Overall, it does a pretty good job for me and after a couple existing extensions it's better. There are a couple feature gaps between the two and since Brackets is really just a web app I can build extensions using JavaScript (not Java or Ruby like other editors/IDEs) which is a nice appeal.

The first extension I'm building is [Sencha Cmd](http://www.sencha.com/products/sencha-cmd/) integration. I normally have my editor and [iTerm](http://iterm.sourceforge.net/) open at the same time. With iTerm I normally have a couple tabs open, one to start my node server and another to run builds with Cmd. So I wanted to be able to run a Cmd build within Brackets so that I don't have to switch back to iTerm to run a build.

Being my first extension, I had to look around at existing plugins that can execute commands such as [hdy.brackets-shell](https://github.com/johnhidey/hdy.brackets-shell) extension. I learned that I have to create a [NodeDomain](http://brackets.io/docs/current/modules/utils/NodeDomain.html) spec to be able to use Node.js' [child_process](http://nodejs.org/api/child_process.html) module. This made me learn a bit of how Brackets work. It turns out that Brackets has a Node.js server running behind the scenes which you can communicate with via NodeDomain which uses [NodeConnection](http://brackets.io/docs/current/modules/utils/NodeConnection.html) (you can also have NodeConnection create the NodeDomain so you can go at it either way). NodeConnection then uses websockets to communicate from the client web app that you interact with and the Node.js server. I got a basic setup working but I was beating my head against my desk wondering why when I make a change to my NodeDomain spec that I wasn't seeing it applied when I would reload Brackets with extensions (cmd + r keyboard shortcut on Mac). Turns out when you reload Brackets, you are only really reloading the client web app, not the Node.js server which needs to happen to make your NodeDomain spec changes take affect.

So the solution is to either quit Brackets and start it back up or you can restart Node via the Debug -> Restart Node menu item. I wish there was an option to reload Brackets and restart Node with a single menu item. Guess a new extension for this is on my list.


NodeDomain lesson with Adobe Brackets


Back when I was 19 I built my first house, well, paid someone else to build it of course. At the time, I thought I was hot shit being only 19 with a brand new house. I was the first house in this neighborhood and the only one to get the rebates they were offering to get people to build so I thought this was an investment. Any new house built should increase the value of my house since I would be the cheapest house on the block. However, the market dropped from under me and it took years to recover from the financial disaster I got myself into. I tried to grow up too fast, I didn't weigh the cons of maxing out my income to pay for this new house.

Fast-forward to today, I'm 31 and wiser. I've made my mistakes and have learned quite a lot from them. Today, I run some projects for my employer (Sencha Inc) and some of my project management skills have spilled over to my personal life such as my personal finances.

When I plan a project, I come up with 4 lists:

- **Requirements**
  - These are features or ideals that are required. Without all of these, I cannot say "I'm ready" for release or even internal testing.
- **Needs**
  - These are features or ideals that are still required for a GA release but they aren't show stoppers for internal testing. I usually like to have these before a beta release.
- **Wants**
  - These are completely optional features or ideals but would be great if they made the GA release.
- **Nevers**
  - These are usually ideals of what I don't want. For example, I don't want this user interaction to happen. I don't want bugs :)

If you look at these, they can fit very well in personal finances. **Requirements** are bills, I have to pay my electricity bill. I have to buy food. **Needs** are more optional but are still required, for me, I have to pay my TV/internet bill for my job (I work from home). I need to buy new clothes to replace worn out clothes. **Wants** can be a wide range of nice to haves. It would be nice to have a larger TV or new shoes. I want to take a vacation to a tropical island. **Nevers** are all those bad things, I never want anything to break. I never want to get sick.

Each month, I know exactly how much money I will make. I know exactly when bills are due. I can budget how much food and gas will cost. So I start cutting slices out for the requirements. I then cut out slices for the needs. Usually the requirements and needs don't take up the whole pie but things happen. Any left over pie, I start prioritizing the wants and cut out slices for them. Anything leftover, gets thrown into a savings as you should always have a savings for a rainy day.

Not everything needs a process but things as important as finances, a plan is needed. Your job is likely affected by your personal life experiences so why not the other way around?


Project Managing Personal Finances


In the article [Abstract vs Override](https://sencha.guru/2014/12/04/abstract-vs-override/), I talked about how to use overrides in an application to globally change [Ext JS](http://www.sencha.com/products/extjs) to work for your application. I was recently asked for the best way to override a method by a colleague and that made me think that talking about some techniques may help. It's not enough to know how to do it, but to know some real-world techniques is helpful.

### Introduction

There are a couple use cases for overriding, most popular is to globally change the behavior or to fix a bug. If you're not familiar with other programming languages that have a class structure with inheritance, the best way to think of a class structure is a tree struture or like a file system. A class (called a subclass) can extend another class (called a superclass) where the subclass will inherit all members (configs, properties and methods) from the superclass. Overriding allows you to hook into any of these classes to override that member.

### `Ext.define` vs `Ext.override`

First, let's look at the anatomy of how to override. In previous Ext JS versions you could use `Ext.override`:

```js
Ext.override(Ext.Component, {
    foo : 'bar'
});
```

Or the class has a static `override` method also:

```js
Ext.Component.override({
    foo : 'bar'
});
```

And while this still works, it's better to use `Ext.define`:

```js
Ext.define('Override.Component', {
    override : 'Ext.Component',

    foo : 'bar'
});
```

While this is more characters, it comes with two benefits:

- Similar API to using `Ext.define` to extend a class.
- Override can be dynamically loaded and required using Cmd or plain `Ext.Loader` and then can also be organized in a file system.

It's recommended to use `Ext.define` and defining one override per file. Cmd has the ability to auto-include overrides for you and include them when you build an application.

### Overriding Properties

One of the basic and simplest usages of an override is overriding properties. Looking at the previous code snippets, we actually see how to override properties. Of course in that snippet the override didn't actually override anything, it added a property onto `Ext.Component`. Looking at the API documentation for `Ext.Component` we can see many properties/configs such as the `hideMode` config which will control how the component is hidden. By default it's value is `display` which will hide the component but using the CSS `display:none` style which will cause the space taken up by the component not to be reserved. If we change `hideMode` to `visibility` then when the component is hidden the space is still reserved for the component it's just not visible due to now using the CSS `visibility:hidden` style. We can override this to affect any `Ext.Component` or subclass like so:

```js
Ext.define('Override.Component', {
    override : 'Ext.Component',

    hideMode : 'visibility'
});
```

Now when we hide a component, the space where the component was is still reserved for the component, you just cannot visually see the component anymore. Of course beware, this will override every single `Ext.Component` and subclass.

### Overriding Methods

Let's say we have a `Foo` class that has a `someMethod` method defined on it:

```js
Ext.define('Foo', {
    someMethod : function() {
        console.log('Foo', 'someMethod');
    }
});
```

If we instantiate `Foo` and execute the `someMethod`, we will get `Foo someMethod` logged out to the console.

We find that there is a bug in it but we don't have control over the `Foo` class, say it's in some third party code where we cannot edit the source so we need to override the `someMethod` method. We can do this just like how we overrode a property:

```js
Ext.define('Override.Foo', {
    override : 'Foo',

    someMethod : function() {
        console.log('Override.Foo', 'someMethod');
    }
});
```

Now if we instantiate `Foo` and execute `someMethod`, we will only get `Override.Foo someMethod` logged out to the console. We will **not** see the `Foo someMethod` logged because we overrode the method; it's like the `someMethod` defined in the `Foo` class never existed.

#### Using `callParent`

In the last override, we overrode the `someMethod` method on the `Foo` class to fix a bug. It's possible that the fix to the bug still needs to call the method that is being overridden, maybe we need to still have the `Foo someMethod` logged out. This is where the `callParent` method comes in, it tracks what method was overridden to make it still executable:

```js
Ext.define('Override.Foo', {
    override : 'Foo',

    someMethod : function() {
        console.log('Override.Foo', 'someMethod');

        this.callParent();
    }
});
```

So now if we instantiate `Foo` and execute `someMethod` we will get `Override.Foo someMethod` logged to the console but we will also get `Foo someMethod` logged out thanks to the `this.callParent();` call.

#### Using `callSuper`

Ext JS has a large class system where there are multiple levels of inheritance. There may be a time when one class extends another class and the subclass calls it's superclass' method. Say we need to override the subclass' method to fix a bug but instead of calling the overridden method using `callParent` we need to skip that method and call the superclass' method. This is where `callSuper` comes in handy. First, let's look at a `Bar` class that extends `Foo` and uses `callParent`:

```js
Ext.define('Bar', {
    extend : 'Foo',

    someMethod : function() {
        console.log('Bar', 'someMethod');

        this.callParent();
    }
});
```

If we instantiate `Bar` and execute `someMethod` we will get all `Bar someMethod`, `Override.Foo someMethod` and `Foo someMethod` logged out to the console. Remember, we still have `Override.Foo` override in place.

Let's see what `callSuper` does when we override the `someMethod` on `Bar` with this override:

```js
Ext.define('Override.Bar', {
    override : 'Bar',

    someMethod : function() {
        console.log('Override.Bar', 'someMethod');

        this.callSuper();
    }
});
```

Now if we instantiate `Bar` and execute `someMethod` we should **not** see the `Bar someMethod` logged to the console because `this.callSuper();` should skip that method. And sure enough, we see `Override.Bar someMethod`, `Override.Foo someMethod` and `Foo someMethod` logged to the console.

#### Difference of `callParent` vs `callSuper`

The difference between `callParent` and `callSuper` is what method ends up being executed. `callParent` will always call the method being overridden where `callSuper` will skip the method being overridden and call a superclass' method.

### Overriding Singletons

I'm a big fan of having a singleton class to manage certain things like application configs. Let's say we have something like this for a singleton (simplified than what I have):

```js
Ext.define('MyApp.Config', {
    singleton : true,

    config : {
        configs : null
    },

    constructor : function() {
        this.initConfig();
        this.callParent();
    },

    get : function(key) {
        return this.getConfigs()[key];
    }
});
```

Without our code we can do things like `MyApp.Config.get('foo')`. But there in an issue with the `get` method, what if `this.getConfigs()` returns a non-Object such as the `get` method was executed before an Xhr call finishes and therefore `this.getConfigs()` will return `null`. We need to handle this case.

For demonstration purposes, say we cannot edit the source for `MyApp.Config` and therefore we need to use an override. Of course, if you have control over the file, edit the source instead of creating an override.

```js
Ext.define('Override.Config', {
    override : 'MyApp.Config',

    get : function(key) {
        var configs = this.getConfigs();

        return configs ? configs[key] : null;
    }
});
```

Now when we use `MyApp.Config.get('foo')` we are protected from whether or not there are configs. `callParent` and `callSuper` work just like overrides on class definitions:

```js
Ext.define('Override.Config', {
    override : 'MyApp.Config',

    get : function(key) {
        return this.getConfigs() ?
            this.callParent([key]) :
            null;
    }
});
```

This override will execute `this.callParent([key])` if `this.getConfigs()` returns truthy else will return `null`.

### More Reading

I also split off some more reading about `callParent` and `callSuper` in another blog: [What is callParent and callSuper](https://sencha.guru/2015/01/20/what-is-callparent-callsuper/).


Overriding methods safely


One of the best things about Ext JS is it's class system. Even though JavaScript doesn't have a class system with inheritance, Ext JS utilizes different JavaScript methods to create inheritance. This enables classes to extend one another to give power, flexibility and code reuse in a simple api otherwise not present in native JavaScript.

### Introduction

First, let's setup a couple classes `Bar` which extends `Foo`:

```js
Ext.define('Foo', {
    someProp : 3,

    someMethod : function() {
        console.log('Foo', 'someMethod');
    }
});

Ext.define('Bar', {
    extend : 'Foo',

    anotherProp : 'test',
    someProp    : 4
});
```

If we look at this code, `Foo` is defined with `someProp` and `someMethod` members on that class. `Bar` is defined and extends `Foo`, adds an `anotherProp` member and overwrites `someProp` to have a different value than was defined on `Foo`. In this case, `Bar` will inherit the `someMethod` and therefore instances of `Bar` can execute the `someMethod` method. Let's look at instantiation and execution:

```js
var foo = new Foo();

foo.someProp === 3;
foo.someMethod(); // logs `Foo someMethod` to the console

var bar = new Bar();

bar.anotherProp === 'test';
bar.someProp === 4;
bar.someMethod(); // logs 'Foo someMethod' to the console
```

### Using `callParent`

We have a need to add logic to `Bar`'s `someMethod` method but we still need to execute the `someMethod` that was inherited from `Foo`. If we simply add `someMethod` to `Bar` like this:

```js
Ext.define('Bar', {
    extend : 'Foo',

    anotherProp : 'test',
    someProp    : 4,

    someMethod : function() {
        console.log('Bar', 'someMethod');
    }
});
```

When we execute `bar.someMethod();` it will now only log out `Bar someMethod` and will not execute the `someMethod` method on the `Foo` class because we overrode the method. We can still call `Foo`'s `someMethod` by using the `callParent` method:

```js
Ext.define('Bar', {
    extend : 'Foo',

    anotherProp : 'test',
    someProp    : 4,

    someMethod : function() {
        console.log('Bar', 'someMethod');

        this.callParent();
    }
});
```

Now when `bar.someMethod();` is executed, we will get `Bar someMethod` **and** `Foo someMethod` both logged to the console because `this.callParent();` calls the superclass' (`Foo`) `someMethod` method.

#### Function arguments

Thus far, the `someMethod` method did not accept any arguments and therefore we didn't need to deal with them and how to pass the arguments to the superclass' method. Let's modify `Foo` to handle a couple arguments:

```js
Ext.define('Foo', {
    someProp : 3,

    someMethod : function(callback, scope) {
        console.log('Foo', 'someMethod');

        if (callback) {
            callback.call(scope || this);
        }
    }
});
```

We changed the signature of the `someMethod` method to accept `callback` and `scope` arguments which are optional but we need to now handle passing the arguments in our `someMethod` method in the `Bar` class in order to keep the behavior of the `Foo` `someMethod` method.

We can do this two ways. The preferred way is to know what the arguments are and pass an array of the arguments to the `callParent` method call. This may take some educating yourself on what arguments are valid for that method by reading the source for the superclass and it's ancestors. The other way is to use the special `arguments` keyword which holds the arguments for the current function block. Here are the two methods in action:

```js
Ext.define('Bar', {
    extend : 'Foo',

    anotherProp : 'test',
    someProp    : 4,

    someMethod : function(callback, scope) {
        console.log('Bar', 'someMethod');

        this.callParent([callback, scope]);
    }
});
```

or with the `arguments` keyword:

```js
Ext.define('Bar', {
    extend : 'Foo',

    anotherProp : 'test',
    someProp    : 4,

    someMethod : function(callback, scope) {
        console.log('Bar', 'someMethod');

        this.callParent(arguments);
    }
});
```

I personally always try to know what arguments are possible and use the first method. Documentation can really help here or simply reading the source from that class' ancestors. If you know a method will never have any arguments, `initComponent` in `Ext.Component` for example, then you can simply execute `callParent` without passing any parameters: `this.callParent();`

### Using `callSuper`

Like `callParent`, `callSuper` allows you to call an ancestor method when overwriting one. There are two differences:

- `callSuper` is only usable within an override
- While `callParent` calls the inherited method, `callSuper` will skip the directly inherited method and call the next level's method.

Let's create an override to `Bar` to explore how to use the `callSuper` method:

```js
Ext.define('Override.Bar', {
    override : 'Bar',

    someMethod : function(callback, scope) {
        console.log('Override.Bar', 'someMethod');
    }
});
```

In this example, we are globally overwriting the `someMethod` method on `Bar`. When we execute `bar.someMethod();` we will only see the `Override.Bar someMethod`. Our need to is not call the `someMethod` method on the `Bar` class but skip it and call the method on the `Foo` class. We can do this with `callSuper`:

```js
Ext.define('Override.Bar', {
    override : 'Bar',

    someMethod : function(callback, scope) {
        console.log('Override.Bar', 'someMethod');

        this.callSuper([callback, scope]);
    }
});
```

Now when `bar.someMethod();` is executed, we will get both `Override.Bar someMethod` and `Foo someMethod` logged to the console. Also note that passing arguments works exactly like it did with `callParent`.

### Handling returning something

What if the `someMethod` in the `Foo` class returned something? How do we handle this with `callParent` and `callSuper`? Well, it's actually quite simple. First, let's look at the changes to `Foo`:

```js
Ext.define('Foo', {
    someProp : 3,

    someMethod : function(callback, scope) {
        console.log('Foo', 'someMethod');

        if (callback) {
            callback.call(scope || this);
        }

        return this;
    }
});
```

Now `someMethod` is chainable as it returns `this` which is likely the `Foo` class. Now we need to handle this in the `Bar` class where we use `callParent`:

```js
Ext.define('Bar', {
    extend : 'Foo',

    anotherProp : 'test',
    someProp    : 4,

    someMethod : function(callback, scope) {
        console.log('Bar', 'someMethod');

        return this.callParent([callback, scope]);
    }
});
```

All I did here was add `return`, `callParent` is just a placeholder for calling the superclass' method and therefore will return whatever that method returns. The same goes for when `callSuper` is used:

```js
Ext.define('Override.Bar', {
    override : 'Bar',

    someMethod : function(callback, scope) {
        console.log('Override.Bar', 'someMethod');

        return this.callSuper([callback, scope]);
    }
});
```

What if you need to do something with what is returned from `callParent` or `callSuper`? Just cache the execution to a local variable and return that variable. Once again this is exactly the same between `callParent` and `callSuper` so I will only show one:

```js
Ext.define('Override.Bar', {
    override : 'Bar',

    someMethod : function(callback, scope) {
        console.log('Override.Bar', 'someMethod');

        var ret = this.callSuper([callback, scope]);

        console.log('Override.Bar', ret.someProp);

        return ret;
    }
});
```

With all the classes and the override in place, when `bar.someMethod();` is executed it will return `this` (which will be the instance of Bar) but will now log these in this order: `Override.Bar someMethod`, `Foo someMethod` and `Override.Bar 4`. Couple things to note here, since we used `callSuper` in the override, the `someMethod` defined on the `Bar` class was not executed as it was skipped due to using `callSuper` and the scope is the instance that was created which is that of the `Bar` class (since we used `var bar = new Bar();` in the beginning) which is why `ret.someProp` returns `4` **not** `3`.


What is callParent and callSuper?


Let's face it fellow programmers, we don't document our code like we really should. Why should we? It doesn't add to the functionality of the application so why waste time? Also, it's not very exciting! It's not exciting to type something, run the application and nothing has changed; nothing is visually or functionally different. We just typed something for the hell of it. Wrong!

#### Why document?

There are many reasons to document. From IDE picking up the documentation for function signature help (such as [IntelliSense](http://en.wikipedia.org/wiki/Intelligent_code_completion)) to application maintenance. Three months down the road, are you going to remember what the code is doing let alone two years when you have to come back to the application? Someone else helping you with the project going to understand what your piece of code is doing? It's great when someone types code and types a period and the IDE tells him/her what members (properties, methods) are available.

We're humans. Reading sentences about what something is doing can go a long way to describe what's going on. Should you always have to dive into the code? No! You can use many different documentation systems that can read your documentation and create a web site. I personally use [JSDuck](https://github.com/senchalabs/jsduck) for my [Ext JS](http://www.sencha.com/products/extjs/) and [Sencha Touch](http://www.sencha.com/products/touch/) applications. Even when developing I check the Ext JS [api docs](http://docs.sencha.com/) for that method I know is there just can't remember what it's called or if it's plural or singular. Documentation can help you and your present and future team develop faster.

#### When to document

Technically, we should be documenting while we write the code. Comments mixed within the code or block comments to describe what arguments a function can accept. The code itself can provide documentation so that when someone is reading the code the variable names are descriptive. I'll be honest, I've developed applications and while programming think that I should write some documentation about it but don't do it. Then couple months later have to go through and document things and not remember what the heck I was thinking. Kind of just shot myself in the foot right?

#### Documentation Friday!

Throughout the week you kicked some code butt! What a great week we had! Did we write documentation? No, we kicked code butt! Just look at it! It's fantastic! And it is fantastic. Now we have to rely on #DocumentationFriday where we stop development to go back through and document everything. Not really an agile approach to documenting but it seems to work for me. Code throughout the week and go back through and document everything to close out the week. For me, it's a great way to wind down from the manic development throughout the week and ease into the weekend. Come Monday, game on!


Documentation Friday!


You just got contracted or assigned a new app! Wow, that's exciting! All you want to do is just jump in and start coding right? Well, you need to slow down and think about the application first. Don't skip the pre-planning stage of the programming. This is separate from pre-planning the application where you come up with all the features the app will have, as developers (the implementors) we need to think of how to develop the app before we actually develop the app.

#### Classes

In an Ext JS or Sencha Touch application, you will no doubt be creating a lot of classes. Before we start programming, we need to think of how we are going to organize the code. You will likely be refactoring as you develop but thinking a bit up front will help quite a bit.

First, you have a list of features. You need to take that list and come up with a logical class structure. For example, maybe you have a user management part of the application. You'll likely need a grid to display a list of users, maybe a detail view of the user and maybe a form to edit and create a user. So right there we know we need 3 classes that belong to a user "feature":

- user
  - Detail
  - Form
  - Grid

To add to that, say your application is an email program so you'll need a form to send an email and of couse a view to display the email so now you have an email and user "features":

- email
  - Detail
  - Form
- user
  - Detail
  - Form
  - Grid

As you can see, we are already starting to think of what classes our application is likely to have and even a structure.

#### Naming our classes

Since we have a structure of classes, the naming of the classes should follow that structure. Say our application name is `Email`, therefore our classes should be named:

- `Email.view.email.Detail`
- `Email.view.email.Form`
- `Email.view.user.Detail`
- `Email.view.user.Form`
- `Email.view.user.Grid`

You can logically see the class names describe the same structure that we planned out. With Ext JS 5, you're likely to have some `ViewController`s for your forms and grids:

- `Email.view.email.Detail`
- `Email.view.email.Form`
- `Email.view.email.FormController`
- `Email.view.user.Detail`
- `Email.view.user.Form`
- `Email.view.user.FormController`
- `Email.view.user.Grid`
- `Email.view.user.GridController`

#### Aliases

Another part of developing an Ext JS and Sencha Touch application is providing aliases (or xtypes for components). These are string representations of our classes that can be used for lazy instantiation. I've seen many naming schemes for naming their aliases to save on space. I see xtypes being like `usergrid` and `emailform` which are pretty descriptive in a simple application but the issue with this is down the road in development the more complex an application gets and not having a naming standard may not be the easiest to remember what class is for an alias when you or someone new to the project comes across the alias somewhere in the application. I keep my alias names closely associated to my class names so when I come across an alias, I know exactly what class that alias is associated with. Here is a mapping of what I'd give my views:

- `email-email-detail`
  - class: `Email.view.email.Detail`
- `email-email-form`
  - class: `Email.view.email.Form`
- `email-user-detail`
  - class: `Email.view.user.Detail`
- `email-user-form`
  - class: `Email.view.user.Form`
- `email-user-grid`
  - class: `Email.view.user.Grid`

You can see the alias for my views is very close to the class name. In fact, all I did was removed the `.view` portion, lowercased it and replaced periods with dashes. But that's exactly what I want. Now when I come across an xtype of `email-user-form` I know that it correlates to the `Email.view.user.Form` and I know exactly where to go to look at the source of that view. I'm even fine with the duplication of `email-email-detail` as it needs to conform to my naming standard. The standard needs to be adhered to regardless of duplication.

For the `ViewController`s, I alias them like so:

- `controller.email-email-form`
  - class: `Email.view.email.FormController`
- `controller.email-user-form`
  - class: `Email.view.user.FormController`
- `controller.email-user-grid`
  - class: `Email.view.user.GridController`

Here I did pretty much the same thing as the views' xtype. I removed the `.view` portion, lowercased the name, replaced periods with dashes only with a `ViewController` I moved the controller part to the beginning of the alias as you have to use the `alias` property and therefor need to give it the `controller` prefix. This gets confusing without seeing the actual code so here is the few lines for the user grid view and controller:

```js
Ext.define('Email.view.user.Grid', {
    extend : 'Ext.grid.Panel',
    xtype  : 'email-user-grid',

    requires : [
        'Email.view.user.GridController
    ],

    controller : 'email-user-grid',

    //...
});

Ext.define('Email.view.user.GridController', {
    extend : 'Ext.app.ViewController',
    alias  : 'controller.email-user-grid',

    //...
});
```

Hopefully the code makes a bit more sense about what I mean. If you look at the `Email.view.user.Grid` source and you see the `controller` property, you should be able to immediately know where to look at for the `ViewController`. The reason why I remove the controller from the end of the `controller.email-user-grid` alias is because it's redundant, the prefix is telling you what the alias is so `controller.email-user-gridcontroller` is redundant but if you want it on your alias there is nothing wrong with it.

You may be wondering why I have my aliases prefixed with the `email` part that is the application name lowercased. I use Sencha Cmd and often times have packages and each package has it's own name and the classes are named with that package name. Having the aliases prefixed with that application or package name tells me what class that is. I may have a `MyPackage.view.user.Grid` class so I need to have an xtype of `mypackage-user-grid`. If I just had it as `user-grid` then does that tell me its for `MyPackage.view.user.Grid` or is it for `Email.view.user.Grid`? Do I need to now name my package classes dependent on what I have in my applications that the package may added to? No. Prefix the aliases to allow for present and future-proofing.

#### Reasons

The main reason I structure my class names and aliases is for maintenance. Six months down the road, I may not remember what I did but since I have a naming standard I don't rely on my memory. Six months down the road, I may hire someone to work on my project and with a naming standard they could more easily hit the ground running instead of searching through the source trying to find what class some alias belongs too. Yes, `Ext.ClassManager` holds a mapping of aliases to classes but IMO you shouldn't have to run the application in order to understand the code especially when it's so easy to structure your names.

#### Conclusions

I'm a big believer in self-deprecation programming. I know many like to program in their own way which can easily give them job security. I want to develop the project so that if something happens to me, like I change jobs and let's face it, this happens often in our programming field, that someone else can pick up where I left off and the project remains successful. One way to do this, is proper class name structuring; you can read the source and understand the structure very easily.


A Naming Strategy


A common method when developing an application is to be event driven. This allows your code to be very flexible. Not being event driven can lead to code that is very intimate to the current state of your application. Change or add something later on and you must go through your application and change the different parts where as being event driven allows an event to be fired and forgotten about. Anything listening to that event can then take action on that event but not be dependant on what fired the event.

A simple example is an email application.  Say a user sends an email, when the email has been sent and the server returns success, the callback may fire an event to tell anything in the application that the user sent an email. The Sent folder list may listen to this event in order to reload the list. This email may have been sent from different forms, a create email form may be different than a quick reply form but that doesn't matter, either form may fire the same event and the Sent folder list doesn't care where it came from. This is flexibility and in my eyes, creates much safer code.

## Adding listeners in Ext JS

Ext JS allows many different ways to add listeners but today I want to speak about `mon` and `on` and the differences. First, let's start with `on`.

### `on`

The simplest of the two is the `on` method which can simply add an event listener:

```js
component.on('foo', someFunc, component);
```

You can also pass an object for a convenient way to add multiple listeners:

```js
component.on({
    scope : component,
    foo   : someFunc,
    bar   : someOtherFunc
});
```

This will add listeners for the `foo` and `bar` events and scope them to the `component` variable. In Ext JS 4 and newer, listeners defined this way will automatically get removed when the component is destroyed thanks to the `clearListeners` method being executed in the `destroy` method of `Ext.Component`.

### `mon`

`mon` works just like `on` when defining a listener only the first argument must be a class to add the listeners too. That's a bit confusing of a statement right? Let's look at an example:

```js
component.mon(subClass, 'foo', someFunc, component);
```

What this is doing, is adding a listener for the `foo` event that will be fired on the `subClass` variable. Once fired, it will execute the `someFunc` function scoped to the `component` variable but the listener is added to the `component` but the event will be fired on the `subClass`.

The benefit here is the component can listen to an event on something else but when the component is destroyed, this listener is removed. The component may be destroyed but the `subClass` variable may still live on; the component is managing the `foo` event listener.

Like the `on` method, you can also pass an object:

```js
component.mon(subClass, {
    scope : component,
    foo   : someFunc,
    bar   : someOtherFunc
});
```

### Difference

Let's think of an `Ext.Component` instance that wants to listen to a `store` load. You can use `on` like this:

```js
store.on('load', this.onStoreLoad, this);
```

However, when the `Ext.Component` is destroyed, the listener will not be removed because the event listener is on the `store` not the `Ext.Component`. This causes a memory leak and the next `store` load after the component is destroyed will likely throw an error, both bad things. This is where `mon` would be a better use:

```js
this.mon(store, 'load', this.onStoreLoad, this);
```

This adds a `load` listener on the store but is being managed by the `Ext.Component`. When the `Ext.Component` is destroyed, the listener is removed. The `store` is then free to live on and fire it's `load` event without errors being thrown and no memory leaks are present.



No doubt, you likely have a store or two in your Ext JS/Touch application. Have you had to add a listener to the store to do something? Maybe update a component when the store loads? Or take any action based on it? Like anything, there's a good way to do it but there may be a better way. Let's discuss some of these ways.

*Disclaimer: Some of these techniques use private methods and therefore need to use at your own risk. I have used them and feel confident they will not change but it always could.*

#### Listening to a store load in a component

One of the most popular components in Ext JS is the grid (`Ext.grid.Panel`) and it so happens to use a store which likely loads data remotely. A configuration I have in my abstract grid class for my projects (for more on abstracts, please see my blog on [Abstract vs Override](https://sencha.guru/2014/12/04/abstract-vs-override/)) is to automatically setup a paging toolbar. With it, I like to hide the paging toolbar when there is only one page of data. So with that requirement, I need to take action on when the store loads to then show or hide the paging toolbar.

First, let's look at an example abstract grid that will setup the paging toolbar:

```js
Ext.define('Abstracts.grid.Panel', {
    extend : 'Ext.grid.Panel',
    xtype  : 'abstracts-gridpanel',

    config : {
        autoHidePaging : true,
        pageable       : true
    },

    initComponent : function() {
        var me = this,
            dockedItems = me.dockedItems || [],
            pageable = me.getPageable();

        me.initStore();

        if (pageable) {
            dockedItems.push(pageable);
        }

        me.dockedItems = dockedItems;

        me.callParent();
    },

    applyPageable : function(pageable, oldPageable) {
        if (pageable) {
            if (!Ext.isObject(pageable)) {
                pageable = {};
            }

            Ext.applyIf(pageable, {
                dock  : 'bottom',
                store : this.initStore()
            });
        }

        return Ext.factory(pageable, Ext.toolbar.Paging, oldPageable);
    },

    initStore : function() {
        var me = this,
            store = me.store;

        if (store && !store.isStore) {
            store = me.store = Ext.data.StoreManager.lookup(store);

            //overwrite this method to simply return the store
            me.initStore = me.getStore;
        }

        return store;
    }
});
```

This is just a snippet but will add a paging toolbar to the grid with the benefit of automatically setting the grid's store on the toolbar. If we use it now, the grid will work and display the paging toolbar and allow users to navigate within the pages.

Now we need to work with our requirement to show/hide the toolbar dependant on number of pages available. I'm sure most would add a load listener to the store like this:

```js
store.on('load', me.handleStoreLoad);
```

and then in the handleStoreLoad method take action which would work but there is a better way. We know the grid already takes action on store loading right? Otherwise how could it display the data? So isn't there already a load listener somewhere? Yes there is! `Ext.grid.Panel` extends `Ext.panel.Table` which sets a load listener to execute a `onStoreLoad` method. Instead of adding our own listener, why not just take advantage of this function? First, we need to understand the method. On `Ext.panel.Table`, it's defined as such:

```js
// template method meant to be overriden
onStoreLoad: Ext.emptyFn,
```

So it's just a template method not doing anything. Checking `Ext.grid.Panel` it doesn't override it so there is no ancestor that does anything with the method and therefore we now know that we don't need to execute `this.callParent` when we override it. So we can add our `onStoreLoad` method to show and hide the paging toolbar as such:

```js
onStoreLoad : function(store) {
    if (this.getAutoHidePaging()) {
        var toolbar = this.getPageable();

        if (toolbar) {
            if (store.getTotalCount() / store.pageSize <= 1) {
                //only one page of data available
                toolbar.hide();
            } else {
                //more than one page is available
                toolbar.show();
            }
        }
    }
}
```

We just acted on a store load without setting our own store load listener and taking advantage of the class system.

#### Listening within a store

What if we wanted to do something within a subclass of `Ext.data.Store` when the store loads? We could do this:

```js
Ext.define('MyApp.store.Users', {
    extend : 'Ext.data.Store',
    alias  : 'myapp-users',

    proxy : {
        type : 'ajax',
        url  : 'foo.json'
    },

    constructor : function(config) {
        this.callParent([config]);

        this.on('load', this.doSomething);
    },

    doSomething : function() {}
});
```

Where we set a listener but like what we did with the grid, we can do some research to see if we can do something without setting an event listener. Without going into details on the process a store and proxy go through to load, the proxy is what does the actual request and the store is just a holder of records. But the store has to take action when the proxy finishes it's loading so it can add the records to it's internal collection. The method on the store is cleverly named `onProxyLoad` which is also where the load event is actually fired. So we can then hook into this method like such:

```js
Ext.define('MyApp.store.Users', {
    extend : 'Ext.data.Store',
    alias  : 'myapp-users',

    proxy : {
        type : 'ajax',
        url  : 'foo.json'
    },

    onProxyLoad : function(operation) {
        this.callParent([operation]);

        this.doSomething();
    },

    doSomething : function() {}
});
```

And now `doSomething` will execute whenever the proxy returns it's loading without setting any listener.

#### Conclusion

I hope this method of reacting to store loads can be thought of for other functions not just store loading. Overriding methods can perform better than listening to events but do have some drawbacks. When overriding methods, you always need to make sure to research that method so you will not break anything.


Store Listeners


Over the years of working with Ext JS and Sencha Touch, I've gotten to see lots of code both from projects I've worked on and for the many code reviews I've done. One common thing I always see, and I'm not exaggerating when I say always, is something that can degrade performance quickly both on the DOM and JavaScript execution level. It's called "overnesting" and it's an epidemic.

#### What is "overnesting"?

Ext JS and Sencha Touch work with Component and Layout systems where you layout your UI by instantiating Components and position/size them using a layout. Overnesting is when you nest a component within a container when that component does not need to be nested. When I say "component", I mean any component not just `Ext.Component`; likewise, "container" doesn't just mean `Ext.container.Container` it also means for any subclass like `Ext.form.Panel` or `Ext.grid.Panel`.

#### Affect of "overnesting"

The side affects of overnesting can include:

- Extra DOM nodes
- Extra JavaScript execution
- Extra layout runs by the browser and/or the framework
- Layout issues, components not laid out properly on all platforms
 	- IE may display differently than Chrome

Any of these are bad and will happen if you have overnesting in your application.

#### Example

Let's look at a sample of overnesting:

```js
Ext.create('Ext.tab.Panel', {
    items : [
        {
            xtype  : 'panel',
            title  : 'Users',
            layout : 'fit',
            tbar   : [
                { text : 'Create User' }
            ],
            items  : [
                {
                    xtype   : 'gridpanel',
                    store   : 'Users',
                    columns : [
                        {
                            text      : 'Name',
                            dataIndex : 'name',
                            flex      : 1
                        }
                    ]
                }
            ]
        }
    ]
});
```

In this example, we create a tab panel with a single tab that is a panel. The panel has a top docked toolbar with a Create User button and also a grid that is laid out using fit layout. While this will work and look as you would expect, it's overnesting. The panel is a layer that is not needed just to have a top docked toolbar, the grid can have a top docked toolbar and will look exactly the same:

```js
Ext.create('Ext.tab.Panel', {
    items : [
        {
            xtype   : 'gridpanel',
            store   : 'Users',
            tbar    : [
                { text : 'Create User' }
            ],
            columns : [
                {
                    text      : 'Name',
                    dataIndex : 'name',
                    flex      : 1
                }
            ]
        }
    ]
});
```

#### Spotting "overnesting"

That was a very simple example, applications are going to be much more complex. The first tip I could give is you need to be aware of what your code is doing. A browser does a very good job at showing the DOM structure, it's a tree of nodes. Your application's UI is also a tree. The overnesting example could look like this in a tree format:

    --Ext.tab.Panel
    ----Ext.panel.Panel
    ------Ext.grid.Panel

If you start to visualize your layout as a tree, you'll start to realize how things are laid out and can then spot possible overnesting.

Another tip would be to use tools or scripts. For example, [Sencha AppInspector](https://chrome.google.com/webstore/detail/app-inspector-for-sencha/pbeapidedgdpniokbedbfbaacglkceae) can display your components in an actual `Ext.tree.Panel` and give you a bit more information on each component that will help you debug your application. I personally prefer having intimate knowledge over the projects I work on but AppInspector can aid your understanding.

#### Conclusion

Overnesting can cause poor performance and all sorts of issues in your application. Even if overnesting isn't a cause of a bug in an application I'm looking at, it's still something that has to be addressed. To me, it's not optional; overnesting must be solved.


A cause in poor performance


The de facto standard of blog software is Wordpress, I'm sure everyone has heard of it. You can do quite a bit with it: install themes, plugins, updates all from the admin GUI. Heck, you can even run whole websites (not just blogs) with it. When the [Healthcare.gov](http://healthcare.gov) site was failing, I can remember reading stories wondering why they didn't use Wordpress.

So I started to wonder, is Wordpress not the right tool for my small little blog? This last year, I was having trouble with my server staying up with Wordpress. First I thought the [DigitalOcean](https://www.digitalocean.com/?refcode=24dc06aa008c) instances I was running were too small so I kept bumping it up. Soon I was running a server with 4GB memory and 2 CPUs thinking maybe I was getting lots of traffic. Admittedly, I don't expect lots of traffic to this blog so that just felt odd to me.

So I setup some free website monitoring from [Monitor.US](http://www.monitor.us) to check performance and to alert me when my server goes down. It was great, I'd get an email when my server went down, I'd go and restart the server. However, some days it was happening several times a day. Another thing I didn't like is the response times reported by the monitoring. I was getting 300-500ms response from US and more than that from Germany to load the page.

I also checked [Google Analytics](http://www.google.com/analytics/) to see my visitor count and it was no where near what I would need to run the server I had running it. It's like having a Lamborghini as your grocery getter, you have the engine to go fast but you are really never going to. So something was up with my Wordpress install. Disabling plugins and such didn't help the stability either. So I could either fix my Wordpress install or go with something else and since I didn't feel like Wordpress was the right tool for my needs, I looked elsewhere and found a new blogging platform that was just starting and getting lots of buzz, [Ghost](https://ghost.org/).

I decided to spin up a new server, install Ghost and work on migrating Wordpress to Ghost. The migration wasn't the best but I eventually got my existing posts migrated over. The one thing that I regret didn't transfer was my Wordpress comments, Disqus just failed to ever want to do that. Once I got the server up and running, I transferred my DNS over to the new server. My response times are normally 100ms in the US and 150ms from Germany now and the server instance is much smaller.

Ghost wasn't around when I first installed Wordpress. There were others but I played it safe with Wordpress. I'm much happier with the simple Ghost blog that promises never to be complex like Wordpress and that's exactly what I want. Before Ghost, I even had thought about creating my own blog software to suit only what I wanted, it wouldn't be too hard to make. So for me and my simple needs, Ghost is perfect! Simple, fast, good :)


Wordpress is slow, Ghost is better?


This last weekend my wife and I were eating at a Panera Bread Company store for lunch. My wife noticed the gift tree they had next to the front door and she started talking about when they had a gift tree when she used to work at Whole Foods Market. She had told me these stories before but we went on to tell me how it was her favorite time of the year because she got to see so many people bring in so many gifts for people that had their card on the gift tree. Some people would fill up their trunk of their car and require help bringing in all the gifts. It was truly amazing.

So as we looked at this gift tree, I proposed one little thing, "Do you want to grab a couple cards and we'd go shopping?" I had her go pick a card for a girl and boy. She came back with a card for a two year old girl and one for a six years old boy and the card has what they wish for. Reading the cards a bit more, these cards weren't just for any kids; they were for kids suffering from a cancer or blood disease. This broke my heart. The girl, at a young age of two, only wanted a tricycle. And the boy, just wanted a Scooby Doo game. I don't know what they have or if it's life threatening but it's very humbling that they have such a sserious disease but want so little.

So off to Toys 'R Us we went, which I'll admit was also for me too; I'm a big kid still. We found two Scooby Doo games, snatched them both for the boy. They both saids for ages 5+, they look fun to me and I'm 5+, wish I could play with it. Went to the tricycles and found one that had buttons for lights and sounds and the seat moved so the little girl could enjoy it as she grows a little bit (I'd like to think she will fight and win whatever she has).

I can imagine their smiles when they get these gifts. And that's the powerful thing here. They may not understand the disease they have, but they do understand happiness and you never know, that may be the key to winning the fight. I will likely never meet them, you do not put your name or anything on the gift when you give it. It's a purely selfless concept, I wish I could meet them. To see the smiles not just in my imagination but in person. I'm sure it would cause me to cry when I left knowing that I was able to make them happy even if just for the couple minutes I was there. I hope these gifts remind them to keep their head up strong, remember to be happy. Know that even strangers love them.

So to whomever you two are, I love you.


Holiday Spirit


Developing large single-page applications can be a daunting task.  I've seen web applications approach a million lines of code.  That's quite a lot of code and performance is a real issue there (luckily it was a B2B application not a consumer facing application).  A golden rule in software development, well most things in life really, is that there is always a better way to do something.  You may think you have the perfect way to make a pizza but there's likely a better way to make it.  The same goes for software development.

### Abstracting code

One way to minimize code is to create an abstract class.  Ext JS has a great class system that allows simple inheritance.  Taking advantage of this class system by creating an abstract class can minimize the code required because you're not having to have the same code spread among several classes.

A simple example I could provide is in my grids I tend to want a couple different things:

- A top docked toolbar with:
  - A search field
  - Button to add a record
- A paging toolbar
- A refresh tool in the title bar

Normally I would extend `Ext.grid.Panel` for all my grids but for those common UI features I'd have to implement them in each grid which is not optimal.  There's an better way to do it, create an abstract grid class that extends `Ext.grid.Panel` and has configs to turn on/off the UI features. Here is an example abstract grid class (please don't get overwhelmed by the amount of code):

```js
Ext.define('MyApp.view.abstracts.Grid', {
    extend : 'Ext.grid.Panel',
    xtype  : 'myapp-abstracts-grid',

    requires : [
        'Ext.button.Button',
        'Ext.form.field.Text',
        'Ext.grid.feature.Grouping',
        'Ext.toolbar.Paging'
    ],

    config : {
        /**
            * @cfg {Boolean/Object} [createNew=true] `true` to add a {@link Ext.button.Button} to create a new record.
            *
            * Can also be a config object for the button.
            */
        createNew   : true,
        /**
            * @cfg {Boolean/Object} [grouped=false] `true` to add the {@link Ext.grid.feature.Grouping} feature to the grid.
            *
            * Can be a config object that will be passed or a boolean.
            */
        grouped     : false,
        /**
            * @cfg {Boolean/Object} [pageable=true] `true` to add a {@link Ext.toolbar.Paging}. Will set the grid's
            * store on the toolbar automatically.
            *
            * Can be a config object for the paging toolbar.
            */
        pageable    : true,
        /**
            * @cfg {Boolean/Object} [refreshable=true] `true` to add a refresh {@link Ext.panel.Tool} to the title bar.
            *
            * Can be a config object for the tool.
            */
        refreshable : true,
        /**
            * @cfg {Boolean/Object} [searchable=true] `true` to add a search {@link Ext.form.field.Text}.
            *
            * Can also be a config object for the text field.
            */
        searchable  : true
    },

    initComponent : function() {
        var me          = this,
            store       = me.store = Ext.data.StoreManager.lookup(me.store),
            dockedItems = me.dockedItems || [],
            features    = me.features    || [],
            tbar        = me.tbar        || [],
            tools       = me.tools       || [],
            createNew   = me.getCreateNew(),
            grouped     = me.getGrouped(),
            pageable    = me.getPageable(),
            refreshable = me.getRefreshable(),
            searchable  = me.getSearchable();

        if (createNew) {
            tbar.unshift(Ext.apply({
                text    : 'Create',
                iconCls : 'fa fa-plus',
                handler : 'onCreateClick'
            }, createNew));
        }

        if (searchable) {
            //add it first
            tbar.unshift(Ext.apply({
                xtype           : 'textfield',
                enableKeyEvents : true,
                emptyText       : 'search...',
                width           : 300,
                triggers        : {
                    search : {
                        cls     : 'fa fa-search',
                        handler : 'doSearch'
                    }
                },
                listeners       : {
                    keydown : 'onSearchKeyDown'
                }
            }, searchable));
        }

        if (grouped) {
            features.push(Ext.apply({
                ftype : 'grouping'
            }, grouped));
        }

        if (pageable) {
            dockedItems.push(Ext.apply({
                xtype       : 'pagingtoolbar',
                dock        : 'bottom',
                displayInfo : true,
                store       : store
            }, pageable));
        }

        if (refreshable) {
            tools.push(Ext.apply({
                type    : 'refresh',
                tooltip : 'Refresh Grid',
                scope   : me,
                handler : 'refreshStore'
            }, refreshable));
        }

        if (tbar.length) {
            docks.push({
                xtype : 'toolbar',
                dock  : 'top',
                items : tbar
            });
        }

        me.dockedItems = docks;
        me.features    = features;
        me.tools       = tools;
        me.tbar        = null;

        me.callParent();
    }
});
```

We now have an abstract grid class that has 5 configs to add certain UI features that are common among grids.  Within the `initComponent` method, we go through these configs and add the classes to the grid.  The configs can be a simple `Boolean` or can be config `Object`s for the different components associated with that config.

##### Abstract Benefits

The issue with this is it will cause a little bit of performance as any extra code will.  Not only do you have an extra `initComponent` call for each class instance, you also have the configs that get the getter/setter methods created, the conditionals in the `initComponent`, and the `Ext.apply` calls.  That's narrow vision thinking though.  If you look at it from an entire application perspective, you will save on performance as it should lead to smaller code; likely not smaller code to be executed as the code has to be executed somewhere but smaller code for the browser to download and evaluate.

I haven't sold you on the idea yet?  Let's look at it from a maintenance perspective.  No doubt, somewhere down the line of development someone will make the decision to add a UI feature.  Would you rather go through each grid and add that in there or make a new config in an abstract class that all grid's will inherit?  Change one class or many?  Still not sold?  You're a hard sale.  Let's look at it from a QA perspective.  Would you rather test one class for these features or many classes duplicating the tests?  Still not sold?  Guess you aren't in charge of QA then.  Maybe you're a project lead or in management.  How about time of development?  Would you rather pay someone to make one change or many?  Abstracts allow you to work faster, implement application features quicker when you have the abstracts setup upfront.

I do this for many different classes that are used frequently: form panel, window, tree but also view controllers (before action in a route maybe?) and stores.

### Using overrides

Abstracts are incredibly useful.  However, abstracts cannot solve everything.  I'm currently working on a new support portal for Sencha, employees (admins) should see different items than customers (users).  I could hook into `initComponent` and build the items array there but I wanted to use simple configs and stay away from overriding methods so I have `adminItems` and `userItems` configs I implement like this:

```js
Ext.define('MyApp.view.Foo', {
    extend : 'Ext.container.Container',
    xtype  : 'myapp-foo',

    adminItems : [
        //...
    ],

    userItems : [
        //...
    ]
});
```

If I were to handle this in an abstract, I'd have to spread the code around to `Ext.container.Container`, `Ext.panel.Panel`, `Ext.grid.Panel`, etc abstract classes so that all components would handle the different admin/user configs.  With the abstract approach, I'd have to spread the logic which is not what I want to do.  I could create a singleton utility class and in the abstracts execute a common method on that utility class but there is a better way to do it.  Let's keep taking advantage of the class system and override certain Ext JS classes.  An example to pick certain items based on if the user is an admin or user we need to determine where the class that handles the items is, which is `Ext.container.Container`, and override it like so:

```js
Ext.define('Override.container.Container', {
    override : 'Ext.container.Container',

    adminItems : null,
    userItems  : null,

    buildItems      : null,
    buildAdminItems : null,
    buildUserItems  : null,

    initComponent : function() {
        var me      = this,
            user    = Portal.user,
            isAdmin = user && user.isAdmin();

        if (me.buildItems) {
            me.items = me.buildItems();
        } else if (me.buildAdminItems && isAdmin) {
            me.items = me.buildAdminItems();
        } else if (me.buildUserItems && user) {
            me.items = me.buildUserItems();
        } else if (me.adminItems && isAdmin) {
            me.items = me.adminItems;
        } else if (me.userItems && user) {
            me.items = me.userItems;
        }

        me.callParent();
    }
});
```

I also go a bit further and allow for `buildItems`, `buildAdminItems` and `buildUserItems` to be methods that I can execute and return items making this override a bit more flexible.

The same process can be put into place for docked items but we need to override `Ext.panel.Panel`:

```js
Ext.define('Override.panel.Panel', {
    override : 'Ext.panel.Panel',

    adminDockedItems : null,
    userDockedItems  : null,

    buildDockedItems      : null,
    buildAdminDockedItems : null,
    buildUserDockedItems  : null,

    initComponent : function() {
        var me      = this,
            user    = Portal.user,
            isAdmin = user && user.isAdmin();

        if (me.buildDockedItems) {
            me.dockedItems = me.buildDockedItems();
        } else if (me.buildAdminDockedItems && isAdmin) {
            me.dockedItems = me.buildAdminDockedItems();
        } else if (me.buildUserDockedItems && user) {
            me.dockedItems = me.buildUserDockedItems();
        } else if (me.adminDockedItems && isAdmin) {
            me.dockedItems = me.adminDockedItems;
        } else if (me.userDockedItems && user) {
            me.dockedItems = me.userDockedItems;
        }

        me.callParent();
    }
});
```

I now have reusable logic for any class. Before, if I wanted to use adminDockedItems in a grid, I'd have to implement the code in `Ext.panel.Panel` and `Ext.grid.Panel` abstracts but with override I only have to impelemnt the code in the `Ext.panel.Panel` override as `Ext.grid.Panel` eventually extends `Ext.panel.Panel`.

The same benefits for abstracts is the same for overrides.  Testability, reusability and time are more optimized.

### Conclusion

The title of the blog is a bit misleading, it's not one versus the other; I use both methods in my applications.  I find doing things like this allows me to be more flexible and quicker and have great success.  That million line app I worked on a few years could have been optimized using abstracts and overrides.  It was but only to an extent, there were many teams working on the one application and I was only to work on my section.


Abstract vs Override


First, I want to provide a disclaimer.  I work for Sencha so admittibly I'm a bit biased.  Believe be or not when I say I attempt to have an open mind, I know Ext JS isn't the right tool for every job.  However, for the applications I've had to build, it's been the perfect tool.

I also want to say I'm writing this blog on the tails of reading the blog [The State of JavaScript in 2015](http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/) by Jimmy Breck-McKye.

#### Jimmy's tl;dr

Directly from his blog post, his tl;dr is:

> - The churn rate of front end JavaScript technologies is problematic
> - People are starting to feel burned out and alienated by the pace of change
> - The answer might be to eschew monolithic frameworks in favour of microlibraries
>
>Of course, we’ll see how much of this actually happens in 2015. It’s entirely possible that Angular’s dominance will remain stable despite the wailing and gnashing of teeth – it is, after all, popular for a very good reason. If so, Angular’s position could be secured in an industry looking for standards and stability amongst the turbulence of the last two years. It’s also possible that another monolith might take Angular’s place. An informal combination of React, Flux and Browserify seems the obvious candidate.

So what he is saying in his blog is that the rate of new JS tech is overwhelming developers and you should pick proven microlibs to piece together an application.

#### Churn Rate

I 100% agree that the number of new libraries and such coming out every day (it seems) is overwhelming.  If I was just starting out, I'd be walking out onto an 8 lane interstate with bumper-to-bumper traffic not knowing what to do.  There is a "hot flavor of the month" where one is touted to be the best thing ever but soon dies because no one actually uses it or turns out it's not all that great.

So should people calm down and go with one?  Thinking as a developer, I'm never going to settle for one; I'm never going to stop creating.  In this field, if you stop creating you are irrelevant or soon to be.  You should always challenge and push yourself, that's how you get better.

Read about all the new stuff but take it with a grain of salt.  For actual projects you get paid for; yes, pick a proven library/framework but for hobby or pet-projects have some fun!  I've created countless things that have never seen the light of day but it's all part of me teaching myself something.  Practice makes perfect right?

#### Why Ext JS?

In Jimmy Breck-McKye's blog, he recommends to go with microlibraries to piece together your applications instead of a monolithic framework.  A microlib usually does one thing really good but a monolithic framework does a ton of stuff well.  The problem I have with the piece meal of microlibs is that there is no one code style and the piecing together of things can be fragile and difficult and can often lead to poor performance.

"You just said monolithic frameworks only do stuff well but microlibs do things really good. Why would I settle with well when I can have really good?"  That's a good question and assuming the glue of all the microlibs is optimal and solid, I'd still stay away from it for the projects I've had to work on.

Ext JS does a lot of things really well. Look at it's data and grid packages, I haven't seen anything that compares.  The charting package used to be the best, it'd do the basic things just fine but failed quickly. Have you seen the progression the charts of had in recent releases? Leaps and bounds better, catching up extremely quick.  Notice I am using the term "packages", Ext JS together with Sencha Cmd, Ext JS is really a collection of packages (would be a stretch to call them microlibs) and the core of Ext JS (called sencha-core) is the glue to hold these packages together.  If your application won't be using grids, Cmd will not build it in for you (including the CSS!).  So if you agree with the piecing the microlib mentality, Ext JS is setup for it!  If you want to use a chart library instead of Ext JS' charting package, you can very well do that and with Sencha Cmd your application will not contain Ext JS' charting source and styles.  It's really not that hard to create an Ext JS component to wrap it and translate data from an Ext JS store to a format readable for that chart.

Ext JS has been around since 2006 and it's not going anywhere.  Development is incredibly active, documentation is being written actively, new guides are being authored, the forums are as busy as ever.  I love Ext JS, for what I do, it's exactly the right tool.  Well, in my eyes it's the only tool.  In the face of things coming and going, Ext JS has been going strong.

#### Conclusion

Don't get overwhelmed with all the new fancy, shiney stuff.  For paid gigs, use what's proven.  For fun, use the new stuff or better yet, create the new stuff. Piecing together microlibs to create a stable application may not be a good idea and Ext JS still has a place in this microlib infested world.  You really have to determine what the right tool for the project is.  Ext JS can be overkill but it can be the savior, just depends on your project.

Also, one pet-peeve I have is when a blog doesn't allow comments.  Jimmy's does not.  I personally love hearing people's opinions even when they conflict with mine.  I respect people's opinions, I know I'm not always right.  Let me know what you think, let's discuss!


Why Ext JS in the face of many (micro)libraries


![Tough Mudder](https://toughmudder.cachefly.net/sites/all/themes/tough_mudder/logo.png)

**Prior**

First of 2013, my now wife and I started working out to prepare for our wedding in the summer. I used to be that tall, skinny guy but since working at a computer I swelled to 240 pounds. Ouch! I saw some pictures of myself and realized I wasn't happy. We both caught the workout bug and started working out all the time with personal trainers. I lost about 40 pounds and have been hovering at 200 pounds for quite some time now.

Around the same time, Jay Garcia was getting into working out and ran a Tough Mudder. Knowing I wasn't at that point, I did a few smaller mud runs that were 5k-7k distances and loved it! They were so much fun! Finally, I signed up for my first Tough Mudder in Chicago in May 2014 along with Jay Garcia and Arthur Kay. Art was running quite a bit, Jay was lifting (not body building lifting) and I was in the middle where I could run 10 miles and was lifting quite often. Well, the three of us kicked ass in the Chicago Mudder.

Since moving to Florida, the heat and gyms being crowded has killed my old workout regimine but I have run 18 miles in one go but have backed down to only running 10 miles as for Tough Mudder I don't need to run more. I also bought a few gym equipment (squat rack, gym mats, etc) and so I can now also target the muscles I need to work on whenever I want instead of pot luck at a gym.

In 2 weeks (November 8, 2014) I will be running my second Tough Mudder in Orlando solo. I'm hoping to do it in 2.5 hours or less but some recent ankle injuries and not working out while on vacation last week may play a big role in that goal. We shall see! I hope sunny Florida doesn't charge the electric shock obstacle(s) too much.

**2015**

So my running and workouts are now back on track and I'm looking to push myself very hard in 2015. So far, I'm signed up for the Chicago Mudder on May 9, 2015 but I'm gonna turn it into a season pass as there are 6 Mudders I want to do and one or two up where Jay lives.

Here is my 2015 Mudder schedule:

- **March 7** Gulf Coast *(near Pensacola, Florida)*
- **May 2** Atlanta, Georgia
- **May 9** Chicago, Illinois
- **May 16** Tennessee *(about an hour south of Nashville, Tennessee)*
- **October 10** Missouri *(about 1.5 hours west of Saint Louis, Missouri)*
- **Fall 2015** Central Florida *(Orlando, Florida; date TBA)*

These are the 6 I plan to do, still waiting to talk to Jay about which one(s) he plans on doing near him to add to it.

Due to trying to save money for a house, I'm trying to stay in driving distance of where I live so that's why over the summer I don't plan on doing any but you never know. Also, Danielle may accompany me as a spectator on some which would be great to have some great pictures/videos of me. Last Mudder the photographer didn't get any of me except at the end.

**Challenges**

First challenge is the May Mudders. Doing 3 Mudders back-to-back for 3 weeks straight will challenge my conditioning and health. I have a few months to get a great meal plan and exercises to get ready for this.

Going solo. Except for Chicago, I'm likely going to be doing these by myself. There are a couple obstacles that require teamwork so I'm hoping to find a group or someone to team up with when running. Normally people are great about helping each other out so this shouldn't a huge issue.

Gripe strength is very important for many of the obstacles. I'd say this was my biggest negative before and over the winter I hope to improve this in prep for the 2015 season. I finally have plywood and gym mats installed so dead lifts and cleans are now possible.

Along with gripe strength, my shoulders need some improving. Trying to get over the walls was a bit tough for my 200 pound frame. I will be including exercises to help in this area.

**Goals**

I like to set high goals for myself to really push myself. After each goal achieved, I set the next goal higher. My motto is, "If I'm gonna hit a wall, I'm gonna run as hard as I can into it."

First goal is obviously to complete each Mudder, hopefully injury free.

Second goal, the Chicago Mudder that I already ran we finished in 3 hours. I'm hoping to beat this. I'll be doing it with Art (hopefully Jay will make it out) and at the end we got some back charlie horses. I'm hoping my health will be much better.

Third goal, I'm very much looking forward to the Missouri Mudder. I used to live in Saint Louis but with work and other things schedules haven't allowed me to run it. Next year, I have a trip that will be in October/November time so hopefully that doesn't screw it up. But since it's in the later part of the year and the first after my long summer break, I'm looking to really kick ass. I'm going for time! I may even ruck it (backpack of weight)!

**Conclusion**

2015 is going to be a hell of a lot of fun for me. Tough Mudders are tough but I feel that over the winter and the summer break I can really do well in preparing my body for these to make my challenges into strengths and achieving my goals. I'm looking forward to Danielle seeing me in action finally and going back to Chicago to run with Art and Jay (in Chicago and/or D.C. area) will be good fun.


Tough Mudder - Looking ahead for 2015


There are use cases where a model's fields need to be loaded from the server so your application can be dynamic and even automatically maintained via the database design changing or some server side update. I recently read a blog post that talked about the same thing but I felt the solution provided was too simplistic and didn't make use of functionality already in Ext JS. So I wanted to create an example of how I would do it.

## Requirements

Before we start coding, lets map out our requirements:

- A store needs to load the model data from the server.
- We need to reuse the model when it is created from server side data so we don't keep creating model definitions.

Pretty simple requirements. The issue with the solution I saw was the second requirement. In that blog post, the store was sending an `Ext.Ajax.request` to load the fields every time a store instance was created. This is unnecessary as once you have the fields for the model and the model has been defined, you no longer need to do another ajax request to load the fields again. Also, the solution used `Ext.Ajax.request` which means you are locked into using it. One last issue with that solution: what if the store auto-loaded and it took less time than the request loading the model fields? You have a racing condition that you can never 100% say will work; network latency, server issues, etc all play a part.

## Ext JS Native Functionality

I mentioned before about the other solution not using functionality that Ext JS already has. When the reader (the `Ext.data.reader.*`) is asked to read the data (readRecords method), it checks to see if there is a `metaData` field in the raw response and if so will execute it's `onMetaChange` method which will then define a new model with the fields returned among other things. Here is the `onMetaChange` method, the code speaks for itself:

```js
onMetaChange : function(meta) {
    var me = this,
        fields = meta.fields || me.getFields(),
        model,
        newModel,
        clientIdProperty,
        proxy;

    // save off the raw meta data
    me.metaData = meta;

    // set any reader-specific configs from meta if available
    if (meta.root) {
        me.setRootProperty(meta.root);
    }

    if (meta.totalProperty) {
        me.setTotalProperty(meta.totalProperty);
    }

    if (meta.successProperty) {
        me.setSuccessProperty(meta.successProperty);
    }

    if (meta.messageProperty) {
        me.setMessageProperty(meta.messageProperty);
    }

    clientIdProperty = meta.clientIdProperty;

    newModel = Ext.define(null, {
        extend: 'Ext.data.Model',
        fields: fields,
        clientIdProperty: clientIdProperty
    });
    me.setModel(newModel);
    proxy = me.getProxy();
    if (proxy) {
        proxy.setModel(newModel);
    }
    me.buildExtractors(true);
}
```

As you can see, the `metaData` allows you to set the root, total, success and message properties but also is going to define a model. Here is an example JSON response that will make the reader execute this method:

```json
{
    "metaData" : {
        fields : [...]
    },
    ...
}
```

## Caching

So now we know that Ext JS can accept metaData to create a new model as we want but the second requirement is we only want to load it once so we need some sort of way to selectively tell the server to return the meta and we also need to cache the model definition for subsequent store instances. Since I may have multiple store definitions that need to use this and I don't want too much logic in my stores; I like to use a singleton class as a utility class. In this example app, I have a singleton class called `MyApp.util.StoreModelCache` located at `app/util/StoreModelCache.js`. What this class does is holds an object mapping store class names to model definition. If a model is not cached yet, it adds a `beforeload` event listener so that it can add a parameter (`needsModel` for this example) to the request to tell the server to return the meta data for the model. It will also add a `load` event listener to then cache the model definitionx the reader created. To kick off the use of the `MyApp.util.StoreModelCache` class, in the `constructor` method of the `MyApp.store.Cached` store, I execute the get method on the `MyApp.util.StoreModelCache` class which returns the model definition from the cache and if one doesn't exist it will add the event listeners.

Do note, I don't use `MyApp.store.Cached` in my grid, I use `MyApp.store.Users` and have that store extend `MyApp.store.Cached` to give a good example as to how you can then have multiple stores reuse the logic.

To summarize it, the `MyApp.util.StoreModelCache` holds model definitions in a cache. If one doesn't exist, it tells the server to return the model meta data and caches the model definition when it's created.

## Example

The example consists of an Ext JS 5 application that has a grid, the stores and the singleton. The example also comes with a PHP script that will load the data and such from a MySQL database. I provide a `data.sql` file that I used for my testing.

Once you get the SQL file imported into a MySQL and you setup the MySQL connection details at the top of `data.php`, you can then run the Ext JS 5 app. The `MyApp.store.Users` store will automatically load so wait a couple seconds for it to load and you should see 2 rows in the grid. If you look at the network tab in the dev tools, you will see a request to `data.php` that has the `needsModel` parameter and therefore the response contains the `metaData` data which then the reader created the model definition.

The grid has 2 tools:

- **refresh** This will reload the store which shouldn't send the `needsModel` parameter as the model should have been cached.
- **recreate** This will destroy the current grid and recreate the grid. I have this so the grid will get a new store instance to show that the model definition created in the first instance was cached.

The example is hosted on GitHub: <a href="https://github.com/mitchellsimoens/ModelOnDemand" target="_blank">here</a>


Loading Model Data on Demand


There has been a conversation going on in a private forum on the Sencha Forums where it discusses what to use and what to recommend in regards to how to create an instance of a class in Ext JS (which spills over to Sencha Touch as well). You can use `Ext.create`, `Ext.widget` or the `new` keyword and the end result is the same. So which should you use? If you ask me, it depends on the situation but the more important thing to me is knowing what happens under the hood with each method. The more you understand about the framework the better off you will be (so long as you don't get overwhelmed which I will try not to do :) ). I'm not trying to sway you to use one method, I want you to know what happens under the hood and some drawbacks I see from each method.

## The `new` keyword

The simplest, most performant form of creating an instance is using the `new` keyword:

```js
new Ext.Component({
    html : 'Hello there'
});
```

This is the most performant means of creating an instance so why not always use it? Why have the other means? The first drawback of using the `new` keyword is that the class must always be loaded. In production this isn't an issue as all classes should be loaded in a single (minified/obfuscated) file but in development the class may not be loaded. If the class isn't loaded, a syntax error will be thrown. I would argue that you should setup your requires properly and this problem is now moot.

I personally always use the new keyword even when saving a couple CPU cycles doesn't matter. To me it's simpler and cleaner, the others are just a waste of extra code in a production build where performance really matters.

## `Ext.create`

The most common (and the officially recommended means by Sencha) to create an instance is using `Ext.create`:

```js
Ext.create('Ext.Component', {
    html : 'Hello there'
});
```

Not too different of a syntax from using the `new` keyword but there is more going on under the hood than just instantiating. The big drawback by using the `new` keyword is the class must already be loaded, `Ext.create` can be used even if the class has not been loaded, this is the reason why you pass in a string so it can look up if the class is loaded. If the class is not loaded, then `Ext.create` leans on `Ext.Loader` to synchronously load the class and then instantiate it.

Couple things here that are not optimal. First is the check to see if the class has been loaded. This is a simple object lookup but one that is not needed in production. The second thing is synchronously loading the class meaning no other javascript will execute while that class is loading meaning your application is frozen. This may not mean much locally as the Xhr completes very fast but I've seen projects where they deploy the development version of an app to a remote server that mimics the production server which may be slow to load the class. Also, when loading a class, `Ext.Loader` has to inspect the class to see if it has any dependencies to load which it will have to synchronously load them as well and the browser will only load 4 things at any given time so you may be waiting for the class and dependencies to load. In production, the loading shouldn't happen as you should have everything compiled into a single file so you are left with the minimal object lookup to get the class from the string which isn't the worst thing in the world.

I do use `Ext.create` when I have a string that I need to instantiate from. Imagine having a tree panel and clicking on a node you have the class name to instantiate. That class name is a string which `Ext.create` can handle.

## `Ext.widget`

The last way to instantiate is using `Ext.widget` (do note this is only for components) which can be used like `Ext.create` (where you pass a string and an optional config object):

```js
Ext.widget('component', {
    html : 'Hello there'
});
```

Or you can just use a config object which requires the `xtype` config:

```js
Ext.widget({
    xtype : 'component',
    html  : 'Hello there'
});
```

This has the same drawbacks and benefits of `Ext.create`. The added drawback is that Ext needs to know about the xtype you are using in some way. This can be from loading the class or from using Sencha Cmd that creates the bootstrap information that tells Ext about the xtypes it finds. Ext keeps an object mapping xtypes to their class so it's a simple object lookup but you also have added code to check if the first argument is a string or an object which isn't that bad of a performance hit at all.

## Summary

Even though I personally use the `new` keyword, I do some times have to use `Ext.create` when I only have a string like I mentioned before. I always make sure the classes I am using are already loaded, I stay away from sync loading at all costs.

I meant this blog not to sway you in any direction but to educate what happens under the hood for better clarification.


Ext.create or Ext.widget or new... what the heck?


Something that I've been seeing a lot lately is people reporting lots of layout issues when they use the browser zoom feature and unfortunately Ext JS does not support browser zoom. The sad part is it's not 100% preventable for what I can see. I found I can prevent the zooming if you use the hotkeys (ctrl + -) but the browser will still allow zooming via the menu. Trying to disable the zooming via the menu I could not find a way cross browser (all IEs), would be elated if anyone knew a way for this cross browser. The following article was just out of curiosity if you could prevent the zooming at all.

## Prevent via hotkeys

In Chrome, Safari, Firefox and IE you can hit ctrl and - or + to zoom out and in. Luckily you can listen for these keys and prevent the browser's handling of these keys. First, we need add a keydown listener to the document body which is quite simple:

```js
Ext.onReady(function() {
    Ext.getBody().on('keydown', function(e) {
        console.log('You pressed a key!');
    });
});
```

Run that in a browser like Chrome and press any key and you should see the log in the javascript console. Next we need to find out what the key codes are when you press the - and + keys which is quite simple:

```js
Ext.onReady(function() {
    Ext.getBody().on('keydown', function(e) {
        console.log('You pressed a key!', e.getKey());
    });
});
```

Now, when you press a button it will also log out what key code is associated with that button. In Chrome, if you pressed - then the key code is 187 and + is 189. This is the same for Safari and IE but Firefox (shortened to Fx, that's for you Jay) the keys are 61 and 173. The next step is to detect if the ctrl (and cmd on Mac) was held down when a key was pressed:

```js
Ext.onReady(function() {
    Ext.getBody().on('keydown', function(e) {
        if (e.ctrlKey) {
            console.log('You pressed a key!', e.getKey());
        }
    });
});
```

Now, if you press ctrl and + it will log that you pressed a key but if you didn't hold down the ctrl key then it will not log it. Let's modify the conditional so that we can check out the key codes in a verbose way since Firefox is different than the others:

```js
Ext.onReady(function() {
    Ext.getBody().on('keydown', function(e) {
        var key = e.getKey();

        if (e.ctrlKey &amp;&amp; (
            (key == e.NUM_MINUS || key == e.NUM_PLUS)                   //Num Pad keys
                ||
            (Ext.isGecko &amp;&amp; (key == 61 || key == 173))                  //Firefox
                ||
            ((Ext.isWebKit || Ext.isIE) &amp;&amp; (key == 187 || key == 189))) // Chrome, Safari or IE
        ) {
            e.preventDefault();
        }
    });
});
```

Notice, I also added in the - and + from the num pad also. Also notice the `e.preventDefault(); call, this is what will prevent the browser from handling those keys. If you run this snippet and try to zoom using the hotkeys the browser will not zoom. Sweet!

## Other Notes

Firefox has the <a href="https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent" title="KeyboardEvent" target="_blank">KeyboardEvent</a> API which would be a great way to normalize the key differences if all browsers worked the same (KeyboardEvent.DOM_VK_EQUALS is 61 on Firefox, undefined on Chrome).

You don't really need all the `Ext.is*` checks, the keys could be combined but I wanted to be verbose in the differences. This could be made better and there are libs that attempt to normalize the keys.


Prevent browser zoom in Ext JS


If you're like me, you probably try to squeeze every bit of performance out of your code and likely end up on a never ending search for performance, there are always little nooks and crannies to find more performance. Some times smaller code isn't more optimized code and the thought of fewer function calls the better holds up quite a bit but still not always. A small tip I want to discuss is along the lines of fewer function calls within an Ext JS and Sencha Touch data Model. In this case, you may find a tiny performance boost but also knowing what is happening behind the scenes is always welcomed.

In an application, most of the time you will have data models in your application with something like:

```js
Ext.define('MyApp.model.User', {
    extend : 'Ext.data.Model',

    fields : [
        { name : 'firstName', type : 'string'                     },
        { name : 'lastName',  type : 'string'                     },
        { name : 'email',     type : 'string'                     },
        { name : 'phone',     type : 'string'                     },
        { name : 'age',       type : 'int'                        },
        { name : 'dob',       type : 'date', dateFormat : 'Y-m-d' }
    ]
});
```

Ok, likely you have many more fields but you get the point. I'm sure your application may still perform very well but you may not actually know what's going on behind the scenes. When you define the type config within your field, you are telling the Model to convert the data coming in to that format. But couldn't you expect firstName and lastName to always be a string so why convert it? If you do not specify a type, it will not do any conversion at all. If you specify your model like the next code snippet, functionality may be exactly the same but perform a little better:

```js
Ext.define('MyApp.model.User', {
    extend : 'Ext.data.Model',

    fields : [
        { name : 'firstName'                                },
        { name : 'lastName'                                 },
        { name : 'email'                                    },
        { name : 'phone'                                    },
        { name : 'age', type : 'int'                        },
        { name : 'dob', type : 'date', dateFormat : 'Y-m-d' }
    ]
});
```

In fact you can shorten that code down even more:

```js
Ext.define('MyApp.model.User', {
    extend : 'Ext.data.Model',

    fields : [
        'firstName',
        'lastName',
        'email',
        'phone',
        { name : 'age', type : 'int'                        },
        { name : 'dob', type : 'date', dateFormat : 'Y-m-d' }
    ]
});
```

Here, we care about the age and dob fields be a certain type, an Integer and Date. Now when the model instances are created, firstName, lastName, email and phone fields will not try to convert the value and will simple apply the value on the data object within your model. Ext.data.Field will turn your string into an Object for you.

Ok, run a perf test on it and you will likely see that performance didn't improve significantly but I think it's also very important to know what's going on behind the scenes. If you set the type config, you are opting into a conversion. You need to evaluate if you actually need to opt for that conversion; some cases you may, some you may not.


Tiny Performance Boost in Data Drive Ext JS/Sencha Touch apps


Talking to a lot of people, I get the sense that there are quite a lot of people who don't actually understand what JsonP is and how it works. In this blog post, I hope to provide some explanation behind JsonP as it's truly a very simple concept.

## Why would someone want to use JsonP?

JsonP is a means of transporting data from a client to a server across origins (different domains or ports). You can accomplish the same with an Xhr request and some headers from your server (I enjoy this site for help with CORS: <a href="http://enable-cors.org/" target="_blank">enable-cors.org</a>) but I've talked to many system admins and they don't like adding the headers. With JsonP, you do not need to have any additional server setup, you can handle it in your endpoint (using PHP, Java or whatever language you are using). I personally like enabling CORS on my server as you can specify what origins to accept cross origin requests from where JsonP doesn't have this security. Well, that's not entirely true, your server side language can check where the request came from. And to be 100% honest, you don't need a server admin to add a header to the server as a server side language can usually return a header (like the header() function in PHP) but I find that a bit awkward.

## In a nut shell, what is JsonP?

Like I said in the second sentence of this blog, JsonP is truly a very simple concept. It has 2 parts, a Javascript function used as a callback that you define on the client and a &#60;script&#60; element you have in your HTML page. The &#60;script&#62; element will handle the transport of data and the callback function handles the data when it has been loaded. That's it. In fact here is an example:

```html
<html>
    <head>
        <script type="text/javascript">
            window.MyCallback = function(data) {
                //handle the data returned here
            };
        </script>
        <script type="text/javascript" src="http://mydomain.com:8080/data.php?callback=MyCallback"></script>
    </head>
    <body></body>
</html>
```

Like I said, we have a Javascript function that is used as a callback, I've named mine MyCallback and you have a &#60;script&#62; element that does the actual loading. Pretty simple right? There is no smoke and mirrors, there is no Xhr request going on that you need to set up.

## So this is how Ext JS' Ext.data.JsonP works?

It's exactly how Ext.data.JsonP works. If you execute this code in Ext JS:

```js
Ext.data.JsonP.request({
    url : 'http://mydomain.com:8080/data.php'
});
```

All it's doing is creating the callback function (which it will append to the url you provided so no need to worry about that) and inserting that &#60;script&#62; into the &#60;head&#62; of your HTML document. It does other things like enables a timeout, keeps track of the requests, executes a success/failure function you can provide to the request method and cleans up the &#60;script&#62; after loading.

## How do I handle this on the server?

Like I said, this request no server setup, it's all handled in your server side language of choice. The request will have a callback request parameter and it's value should wrap your "Json" data which actually will execute the Javascript callback function that is supposed to be created in the client app. Let's use my first code that we used when describing JsonP in a nutshell. It's sending the callback parameter with a value of MyCallback so our "Json" needs to be wrapped in MyCallback so that we execute the MyCallback function. Here is an example of the response:

```js
MyCallback({
    "foo": "bar"
});
```

Looks exactly like Javascript doesn't it? That's because it is Javascript. Remember, the &#60;script&#62; does the loading which will expect Javascript. It's just like if you were loading a somefile.js with a &#60;script&#62; only it's Javascript returned from a server side language instead of some file on your server.

My server side language of choice is PHP. Here is a sample PHP script that would support JsonP:

```php
<?php

$isJsonP = isset($_REQUEST['callback']);
$data    = array('foo' => 'bar');

if ($isJsonP) {
    echo $_REQUEST['callback'] . '(';
}

echo json_encode($data);

if ($isJsonP) {
    echo ');';
}
?>
```

In this code, if there is a callback parameter the $isJsonP variable will be true which will wrap the json that is echoed out with the callback function and the needed parentheses. This will echo out the example JsonP response from above.

## Let's summarize this up

JsonP is a means of transporting data across different origins. All JsonP is is a Javascript function and a &#60;script&#62; element which makes JsonP compliant with any browser that can load Javascript files with absolutely zero setup.


JsonP Explanation

Client side associations


Recently I saw a <a href="http://training.figleaf.com/tutorials/senchacomplete/chapter2/lesson10/5.cfm" title="blog post" target="_blank">blog post</a> about creating a component to play YouTube videos in Sencha Touch 2. Of course the code worked but I could help but think there should be a better way then to use the `Ext.String.format` method, of course I am not sure of the previous lessons as this is Chapter 2. This week I also have been running into people not understanding the `config` object and the getters/setters created for it so I felt like this YouTube component could be a great example to use. Also, last week someone asked me what the equivalent to the renderTpl property in Ext JS 4 was in Sencha Touch 2 so I decided to wrap the `getElementConfig` method in to this blog post as well. Hopefully this isn't too much in one post, will take it as slow as I can.

## Code Discovery

Let's first look at how the blog post accomplished the YouTube video viewing. They create an extension of Ext.Component and create a string of an `&#60;iframe&#62;` to view the video. Couple things I didn't like about this. First, I think using `Ext.String.format` isn't the most ideal and flexible solution. Also the string generates a `&#60;div&#62;` wrapping the `&#60;iframe&#62;` so it can horizontally center the `&#60;iframe&#62;` but shouldn't the parent container's layout take care of this centering? The component also uses two width (`vWidth`) and height (`vHeight`) configs to set the size of the `&#60;iframe&#62;` but just like the centering, shouldn't the parent container's layout take care of the sizing? I think the `&#60;iframe&#62;` should have 100% height and width to take up the full size of the `Ext.Component`. Also, no need for the `styleHtmlContent` for this. So basically I just said they are doing it all wrong in my opinion, it works just there is a better way to do it. One thing I've learned, there is always going to be a better way to do things and many opinions of how it should be done.

## New Code

I'm gonna throw out my code and then walk through why I did it and also learn how the `config` object and `getElementConfig` work.

```js
Ext.define('Ux.YouTubePlayer', {
    extend : 'Ext.Component',
    xtype  : 'youtubeplayer',

    config : {
        cls     : 'youtube-player',
        /**
            * @cfg {String} url The base URL of the YouTube video.
            */
        url     : 'http://www.youtube.com/embed/',
        /**
            * @cfg {String} videoId The ID of the video.
            */
        videoId : null
    },

    getElementConfig : function() {
        var tpl = this.callParent();

        //The src will come from the updateVideoId method
        tpl.children.push({
            tag       : 'iframe',
            //this is the property that will be used on the component
            reference : 'videoIframe',
            //would rather this be in CSS
            style     : 'width:100%;height:100%;border:0;'
        });

        return tpl;
    },

    /**
        * This method will update the src attribute of the &lt;iframe&gt; when
        * you execute setVideoId method.
        */
    updateVideoId : function(videoId) {
        if (videoId) {
            this.videoIframe.set({
                src : this.getUrl() + videoId
            });
        }
    }
});
```

Few things I did here, instead of using the `alias` property I used the `xtype` property, this doesn't do anything differently, just saves some code. I also got rid of the three configs (`vWidth<span>, `vHeight` and `styleHtmlContent`) for reasons discussed before and only kept the two important ones. Then I used the `getElementConfig` method and `updateVideoId` method to do the the logic instead of the `Ext.String.format`. But, we need to slow down and talk a little bit.

## getElementConfig

In Ext JS 4, you would use the `renderTpl` property which uses `Ext.XTemplate` to setup the DOM elements for that component. In Sencha Touch 2 you cannot use the `renderTpl` property but of course we still need a way to setup the DOM elements. For this Sencha Touch 2 uses the `getElementConfig` method that returns a single or an array of element configs for `Ext.DomHelper`. At first glance people get scared away but it's really simple. Let's look at the `getElementConfig` for `Ext.Component`:

```js
getElementConfig: function() {
    return {
        reference: 'element',
        classList: ['x-unsized'],
        children: this.getTemplate()
    };
}
```

This simple will return a single DOM element as that's all `Ext.Component` needs. First property is the `reference` property which is just a string. This is the property on the component that this element will be cached as so this element can be accessed from `component.element`. The `classList` takes an array or string of the CSS classes to be applied to that element. The `children` property is an array of child elements which each of will look like above. The `getTemplate` method returns `this.template` so you could use the `template` property but you can get things off the class scope which can be very powerful and you can see the inheritance work if you extend a component that uses `this.template` without you breaking things. One thing that is not used here is what tag the element will be (div, span, etc) and the reason that is is the `tag` property defaults to 'div' so this will return a `&#60;div&#62;` element.

So back to my YouTube component if we look at the `getElementConfig` method. First thing I do is get the object from the superclass (Ext.Component) which is the code snippet above. Then I added an iframe element to the children of what was returned from the superclass. This `&#60;iframe&#62;` will be cached to the `videoIframe` property on the component as specified in the `reference` property. We also give it some inline styles however I hate seeing inline styles. I much prefer using SASS (CSS) to specify styles like this but serving as an example and to not have an additional file for this blog post I just did an inline style. Since we have `cls` set to 'youtube-player' on this component we could use that to specify the styles.

Ok, while writing this I think I can make it a little better and more elegant. Instead of pushing an element onto the children array in `getElementConfig` method after calling the superclass, let's remove the `getElementConfig` method from the `Ux.YouTubePlayer` component and let's use the `getTemplate` method. This is what the new code would look like:

```js
Ext.define('Ux.YouTubePlayer', {
    extend : 'Ext.Component',
    xtype  : 'youtubeplayer',

    config : {
        cls     : 'youtube-player',
        /**
            * @cfg {String} url The base URL of the YouTube video.
            */
        url     : 'http://www.youtube.com/embed/',
        /**
            * @cfg {String} videoId The ID of the video.
            */
        videoId : null
    },

    getTemplate : function() {
        return [
            {
                tag       : 'iframe',
                //this is the property that will be used on the component
                reference : 'videoIframe',
                //would rather this be in CSS
                style     : 'width:100%;height:100%;border:0;'
            }
        ];
    },

    /**
        * This method will update the src attribute of the &lt;iframe&gt; when
        * you execute setVideoId method.
        */
    updateVideoId : function(videoId) {
        if (videoId) {
            this.videoIframe.set({
                src : this.getUrl() + videoId
            });
        }
    }
});
```

I like that better. This goes to show that there are always better ways and talking through something can help quite a bit.

## config Object

So we saw how we can create DOM elements but the other half of what I wanted to discuss is what the `config` object is and how it works. At first I thought I would hate this but I feel like I can't live without it now, it's magical! The `config` object is what holds all the configs, go figure! When you create a class and pass in a config object to that instantiation it gets applied on the `config` object you specify in the `Ext.define` call, the config object in `Ext.define` are like the default values for the configs. So instead of this:

```js
Ext.define('MyClass', {
    foo : null
});
```

You would have

```js
Ext.define('MyClass', {
    config : {
        foo : null
    }
});
```

So it nests the configs within an object now, what gives? Well, there is more to that `config` object. First, it generates a getter method. It takes the config, in this case 'foo', uppercases the first letter and prefixes 'get' so you get 'getFoo'. This method simply returns the private `this._foo` property value. The other part is it generates a setter method which name is like the 'getFoo' but it's 'setFoo'. You probably think it just sets the value passed to the setFoo method to the `this._foo` private property, it does but it adds more flexibility. What I mean is it can look for and use applyFoo and updateFoo that you can (optional) specify in your `Ext.define` statement. The applyFoo, called an applier, can be used to transform the value passed into something else. For example, you can pass in a config object of a class and the applier method can take that config object and turn it into a class. The updateFoo method, called the updater, can be used to take action on the new value like adding listeners. So the workflow (in code) is like this:

```js
setFoo : function(value) {
    var applier         = 'applyFoo',
        updater         = 'updateFoo',
        getter          = 'getFoo',
        privateProperty = '_foo',
        oldValue        = this[getter]();

    if (this[applier]) {
        value = this[applier].call(this, value, oldValue);
    }

    if (typeof value != 'undefined') {
        this.[privateProperty] = value;

        if (this[updater]) {
            this[updater].call(this, value, oldValue);
        }
    }
}
```

This is very similar to the `generateSetter` method in `Ext.Class`. You can notice the workflow and that the applier and updater get both the value and the oldValue passed to it. So now the `MyClass` class can look like this:

```js
Ext.define('MyClass', {
    config : {
        foo : null
    },

    applyFoo : function(newValue, oldValue) {
        return Ext.factory(newValue, Ext.data.Store, oldValue);
    },

    updateFoo : function(newValue, oldValue) {
        if (oldValue) {
            oldValue.un('load', this.someFunction, this);
        }

        if (newValue) {
            newValue.on('load', this.someFunction, this);
        }
    }
});
```

So in the applyFoo we use the `Ext.factory` method to create an `Ext.data.Store` instance and return it, make sure you return something here. In the updateFoo, we removed a listener on the old value and added a listener on the new value. Can you see how awesome the config object is? You will see this pattern all over Sencha Touch 2 framework classes, it really does add quite a bit of power and flexibility.

So back to the `Ux.YouTubePlayer` class that we are using for a real world example. We want to take advantage of any setVideoId execution to update the `&#60;iframe&#62;` with a new URL of the actual video. We expect the ID of the video so no need to specify an applier method as we don't need to transform the value. However, we do need to take action on a new ID so we specify the updateVideoId method to change the src attribute on the `&#60;iframe&#62;` element.

## Summary

I hope I didn't cover too much in one blog post. You can see how to use the `getElementConfig` (and later the `getTemplate`) method works and also what the `config` object is and how it works with the getter/setter/applier/updater methods. Can you see how awesome this stuff is?!


Lesson in the getElementConfig method and config object


I came across a thread that actually got me a little riled up. A quick disclaimer, I absolutely have OCD tendencies (have a light switch story for that). I take great pride in how my code looks, not just how it is parsed by the browser. For those who know me and have seen my code, you probably know I'm anal about lining colons and equal signs up:

```js
var foo    = {
        uno    : 'one',
        dos    : 'two',
        tres   : 'three',
        cuatro : 'four'
    },
    fooBar = 'Who?';
```

As you can see things are lined up and easily readable versus this:

```js
var foo = {
        uno: 'one',
        dos: 'two',
        tres: 'three',
        cuatro: 'four'
    },
    fooBar = 'Who?';
```

Not that big of a deal with that little code but bigger your code gets the more your code looks like a mess. Either case, Javascript will parse both code and all will be the same. Yes, my "beautified" code does take up more disk space; my reply would be that would be that you likely won't be deploying it like either one of these as you will be minifying etc so both pieces of code will look the same in the end. During development, it's easier to read the first snippet than the second. Some agree, some don't... this is purely my coding style.

Now the real thing that irked me... trailing commas. What is a trailing comma? It's a comma that is on the last value in an object:

```js
var foo = {
    bar : 'whoa',
};
```

The comma after 'whoa' is a trailing comma. Run this code in different browsers and you will get two different results. In Chrome, Safari and Firefox this code will be parsed with the trailing comma disregarded; however, run this code in Internet Explorer and it will throw an error. Why since it works in other browsers? I believe the EMCAScript 5 spec says it's fine to have trailing commas but in EMCAScript 3 it is actually invalid Javascript. Testing that code in IE6-9 will result in an error. IE10 is supporting the 5 spec so it's technically valid but the argument for messy code is still there. Sure, when you minify your code trailing commas will likely be taken out.

I have been in corporate and government environments both within Sencha and outside of Sencha and a requirement that I always have is code must run in IE6+. All builds have to pass: dev, testing, prod and others which means that trailing commas will not pass.

Whether or not it technically parses, does that mean you should allow it? Not sure if you all have had to pass JSLint/JSHint tests, good luck with trailing commas. Not sure if you have ever had to pass a code test for a job but code quality will likely be judged and trailing commas raises red flags.

It's your choice whether you want to use trailing commas, I strongly discourage it.


Coding style vs valid Javascript


Over the last few months helping people on the forums I have come across people who really aren't debugging for themselves. They come on an issue and jump pretty quickly to ask for help. Don't get me wrong, I love to help, this is the reason why I have stayed in my position but you kind of need to be able to debug for yourself. I believe the reason for this is very like how I started in web development:

When I got first started out, I debugged via alert. Meaning I did things like this:

```js
alert(foo.bar[2]);
```

And then realized that I got the mapping wrong and had to change the alert to something else and try again. This was a pain as often to get to where this alert was I'd have to do some user interactions and such. Then I learned of Firebug and loved using the console to log things out. That was so much better as I could then just log out an object or array and inspect it. This helped so much more than the alert did especially since I didn't have to worry about only working with string and numbers, I could now inspect objects and arrays so I could replace that alert with

```js
console.log(foo);
```

and deal with getting into the bar property and inspect that array. Thought that was as good as it got until I found out about breakpoints. Holy cow, that was a game changer for me!

So what is a breakpoint? First we need to look at Javascript. Javascript is a synchronous language meaning things are executed in order. So we can rely that line 3 is going to always execute before line 5:

```js
var foo = {};

someFn();

someFn2();
```

So no matter what in someFn is executed, someFn2 will not be executed until someFn executes. But say we have an error somewhere that the foo object is incorrect but we don't know if the issue is in someFn or someFn2. We can log things to the console and spread them around to see when something is changed. Technically yes, you could do that and find the issue but it's inefficient and messy to spread console statements around and you run the possibility that you may leave them in there which is now a waste of space and IE won't like you anymore.

What do we do then? This is where a breakpoint can save your life. A breakpoint tells the browser to halt everything at the line you set a breakpoint on. The browser will literally stop, interactions with your page will stop, Javascript will stop; nothing will happen. Then you can start to Step Into or Step Over to navigate through the code as it is being executed meanwhile you can keep an eye on the different variables as you are going through. Since our foo object is being changed incorrectly somewhere, this is exactly what we need: walk through the code and watch the foo object change.

Wait, what is Step Into and Step Over? Picture yourself hiking and you come up on a huge rock that is in your way. You have two choices you can either climb over it or you can walk around it bypassing the rock. If you choose to climb over it you are going over the rock little by little with each foot hold, this is like Step Into where you are going to go into more code and go little by little. If you choose to walk around it you are bypassing the rock, this is like Step Over where you can skip a function call so you don't have to deal with the code within that function. So if you set a break point on line 1 where we defined the foo object and you get to line 3 where someFn is going to be executed, you can Step Into or Step Over... either go into the someFn as it is executing and see what is happening within that function (Step Into) or bypass the code that is within the function (Step Over). What happens when you are climbing up the rock but you realize this isn't where you need to be and need to get off the rock right now and bypass it? You can Step Out. So if you stepped into someFn but you realize that the code within it isn't where the issue is, you can Step Out of the function and go on to someFn2. Of course at any point you want to give up you can always Play which lets your browser execute the rest of the code until all code has been executed or it comes across another breakpoint. Often times when I am sending an ajax call and I stepped into code where the ajax call is going to send, I need to set another breakpoint in the callback and press Play so that when the ajax call returns the browser will once again halt it's executing so I can continue debugging.

Now you can see that you can walk your way through code without needing to debug via alert or console.log which is a much much better way of debugging code. But, how do you set a breakpoint? Two ways. You can type a debugger statement which tells your browser to stop there like:

```js
var foo = {};

debugger;
someFn();

someFn2();
```

And the browser will stop at line 2 and wait for your decision to continue. However, like the issues with console.log, debugger statements are messy and IE won't like you. I often create hooks to not allow version control to commit changes if it finds any. Or you can open the dev tools of your browser and go into the file you need to set a breakpoint and click on the row number to set a breakpoint. That's it! Now you can set breakpoints and walk through your code to find any issues.

Don't forget to remove your breakpoints as your browser will remember them (for file names that are the same, Ext JS and ST add _dc param not allowing the breakpoints to stick). To do this either click on the line number to remove the breakpoint or there is a section for breakpoints on the right-hand side of the dev tools. YOu can disable breakpoints in the breakpoints section as well to keep them but the browser won't stop.


Breakpoint a lost art?


Today, I spoke with someone about our extensions we have made and it made me realize something... I love making something, the challenge of not knowing how to do it and learning how to do it and the thrill of that moment of success! I'm the kind of person that if I don't know something, I want to challenge myself to figure it out; probably one of the reasons I am where I am today and where I will be in the future. But, it's nice to get a pat on the back for a good job once in a while.

Right now, I have about 70 private and public repositories of extensions, plugins and other code on <a href="https://github.com/mitchellsimoens" target="_blank">GitHub</a>. The public ones are of course free to use, private ones are either Sencha code or stuff I'm not ready to release. I also have lots of code on my local computer that I love tinkering with, plus seems I don't like putting server-side code up for some reason... JavaScript ftw!

Anyway, lots of people use code I have put up and a couple have even sent Pull Requests which is fantastic! Some people reach out to me to thank me which is also fantastic! But then you have those who use it and some who just complain because it doesn't work for their situation. You have to understand, most of the time people create extensions for their personal projects but there are many times where things are created just to create something and give back. For instance, my grid component for Sencha Touch 1 and 2 I created for no reason. To be honest, I have yet to use it in an actual application but it's my mostly used extension. I have spent many hours working on it and changing things for some people and I don't have a whole lot of free time these days so an hour is quite valuable to me. There really has only been a handful of people who have given back or thanked me for my work.

On the flip side, my repositories kind of make up my resume as I treat my name as a brand so I shouldn't expect anything back but if I look at something someone created or even use it I will tweet about it and/or post on the Sencha forums thanking the person or giving suggestions. It really wouldn't be a first time I have forked a project to pitch in development. I do my best to at least give back by thanking if nothing else. Sort of like my work on the Sencha forums, I answer a lot of questions but thanks is few and far in-between. That is my job really so that doesn't bother me much but creating things for the sake of creating things for people isn't my job, I do it to provide solutions for people and to teach myself.

Do note, this blog post is also therapeutic to get something off my chest. The reason this is categorized as Personal so take it all with a grain of salt.


Grateful for extensions


## About me

I have owned many iPod Touches, an iPhone, all 3 iPads and Android phones/tablets ever since the good ole G1 (most notably the more recent Gingerbread, Honeycomb and ICS devices) so I have quite a good history with both platforms (funny to see Danielle get pissed when all my devices start making noise when I get a mention on Twitter, have been forced to silence most of them). I used to be an Android nut but battery life and the crap browser made me switch my primary phone from Android to my iPhone 4S I currently hold. The phone that broke the camels back was my HTC Evo that on a good day would have 6-7 hours of battery life versus my iPhone 4S can last 2 working days both with normal (for me) use. So I abandoned Android as my primary device but still held my other devices for testing.

## Google IO 2012

Like many I watched many live broadcasts on YouTube very interested in the rumored (and leaked just before Google IO start) Google tablet and Android 4.1 "Jelly Bean". Watching the videos of what was possible in Jelly Bean got me excited. Then they showed off the Nexus 7 which lived up to much of the rumors. So I pre-ordered the Nexus 7 which came preloaded with Jelly Bean and the most important piece to a web developer, it came with Chrome as the native browser. I received it last Tuesday (July 17) and decided to live with it as my daily tablet and not my beloved iPad 3 (new iPad, suck a crappy name Apple).

## My Tests

First off, I want to believe I am a very honest person but as a human, I am biased with past experiences and my current Mac/iOS/Apple fanboy status. Instead of testing for performance or HTML5 features I decided to just focus on real life experience. Numbers are great but they are just numbers. When I ask someone about performance and they reply with saying it's 11% faster, well, it was only 500 ms in the first place; will someone really notice 55 ms difference? (yes, 1 is not much but the sum of a hundred 1s is greater so numbers are still important... saved myself!)

## Time for thoughts!

The iPads have been 10.1 inch screens which IMO is a great size for a tablet so getting something about 1/3 smaller (at 7 inches) I was skeptic. The best thing about that smaller form factor, my hand can grasp it from side-to-side so I can walk with it very comfortably but sitting on the couch (yeah, I have body by <a href="http://www.la-z-boy.com/" title="La-Z-boy" target="_blank"></a>) I would still want a larger screen but if I'm on the move then it would be a great device. But I was surprised that sitting on the couch I didn't actually mind the 7 inch size, just in some of my Sencha Touch 2 tests I was begging for some more screen real estate.

iOS with mobile Safari has been a great browser to develop on, I have had little to no complaints. The native browser on Android was not good for a web app with my G1 and wasn't good for my Asus Transformer Prime (updated to 4.0.3). Chrome on the 4.0.3 device was better but it was in beta and had CSS inconsistencies but it was better and a great start to something that could be great. My Nexus 7 had Chrome installed as the native browser and long story short it is leaps and bounds better than the native browser of late but isn't as good as mobile Safari. Still, very happy with where Chrome currently is and hoping Google will remain serious about it's browser on mobile devices like it has on the desktop.

Scrolling was so-so. First I tested on normal web sites but I could also see the same performance in native apps like Gmail. When I would go to scroll it would be a little laggy and the momentum wasn't high enough for my liking and I couldn't find a setting to mess with this. Only like 10% of the time it would take half a second (an hour in the tech world) for the scrolling to start scrolling... something that with iOS I never actually experienced.

Since I am a Sencha Touch nut, of course I'm going to run it against some of my and Sencha's apps/examples. The biggest thing I wanted to see is accuracy and animation performance, first dove into the navigationview example that comes with Sencha Touch 2 and was amazed at the animation performance! It performed marginally as well as any of my iOS devices. Yeah, I just said that. Shock aside, tested some scrolling as I had already experienced shaky results with scrolling but Sencha Touch 2 doesn't use native scrolling so I was curious. I know I work for Sencha and this may come off biased and marketing talk but in my opinion (not abbreviated for importance) it performed as well if not better and in most of my tests it's the latter of that statement. With many images it would get a little jumpy but that's gonna be expected on Android really and as a user wasn't going to turn me off from using an app. Switching to the KitchenSink where there is going to be a lot of CSS transitions and many things being rendered it performed far better than any other Android device I have used. There is a slight delay on the tab panels and NestedList but that is due to needing to render the DOM elements and we aren't talking 5 seconds, more like half to a full second depending how much was being rendered and when animation started. Using some other apps I have built including the TouchForums app (status: on the back burner's back burner if not dead) which uses a lot of CSS transitions and rendering lots of HTML it performed almost as good as mobile Safari. Same result for some other apps and overall I am very happy with the performance. It's not as good or as polished as mobile Safari but so much better than any Android release thus far. This performance I would assume is due to both Chrome and the quad-core with 1GB of RAM. I would also assume that Android has many performance improvements that would contribute. Fix the scrolling and this is a fantastic device.

## Battery life

I mentioned above that I dumped my HTC Evo due to the battery life. The marketing of the Nexus 7 says 8 hours of active use which is less than the 10 hours my iPad is suppose to give. Of normal use I charged the Nexus 7 2 times in the last week. I used it for some of my Twitter and Facebook updates when I wasn't in front of my MacBook Pro as I would with my iPad, looked up recipes (I'm the household cook) and read my Google Reader. This is less battery life than my iPad but is extremely bearable and the Nexus 7 is smaller so I would expect less life from the Nexus 7.

## Biggest con IMO

The Apple devices feel very solid and have a great weight to them that makes me feel like their construction is of high quality. The Nexus 7... well, feels more on the cheap side. It does feel plasticy but for 2/5 the price of an entry level iPad ($199 vs $499) I guess I can't be too picky and you pay for what you get. In my opinion, Android hasn't touched the iPad in the tablet arena and Google could have thrown some cash to buy it's way in maybe. The rubberized back is nice to grab on too but would have loved something more modern looking and leave the rubber stuff for a case if I want it but for that beauty is in the eye of the beholder so can't really fault the device for someone's design, just don't like the polish of the device when put up against the iPad. It's rumored to cost $154 (among other estimates) to build the Nexus 7 so there isn't a lot of profit to the device but I now wouldn't classify the Nexus 7 as a true high-end device like the iPads are.

## Back camera

Those who care about this really shouldn't have a tablet. Stop taking pictures with a tablet! It's annoying to see someone hold up something like a tablet to take a picture, use your phone or an actual camera.

## Disclaimer

I do work for Sencha but I want to say my views here are my own and do not reflect what Sencha thinks about Nexus 7, Android, iOS or anything else mentioned here. These are my honest experiences of my week with my Nexus 7. My view is Nexus 7 is a fine product and Android 4.1 with Chrome has given some love back to the platform. Going further I'm sure I will stick with iOS but will keep my Nexus 7 around for usage where the form factor fits it.


My week with my Nexus 7


With the introduction of Sencha Touch 2.0.0 GA we got the use of Sencha Command which allows developers to create an app and build an app. Well, not as simple as that as there is more to it than simply creating and building but that's for another blog post maybe. One thing that I try to emphasize is that you not edit `index.html`. The only exception to my rule is to edit the CSS and HTML for the loading screen but nothing else! No adding `&#60;link&#62;` elements, `&#60;script&#62;` elements, nothing! Of course your application may require it but try not to do it.

## `app.json`

`app.json` is the configuration file that the builder and microloader uses to know really how to work and what to load. What to load, like CSS and JavaScript files? Exactly! There are both `js` and `css` properties that tell the builder to copy over to the `build` folder and setup the microloader to load and possibly save to `localStorage`. However, there is a flaw with this and is noted in the comment above the `js` and `css` properties that the path must be relative to the `app.json` file. Many apps require the loading of remote sources and one of the more popular ones is the Google Maps API. To load a Google Map you must have a `&#60;script&#62;` element to load the API but you shouldn't edit `index.html` and `app.json`'s js property only loads relative files which both mean that there is no way to handle remote files.

## Hack

The URL that you need to load for the Google Maps API is likely <a href="http://maps.google.com/maps/api/js?sensor=true" target="_blank">http://maps.google.com/maps/api/js?sensor=true</a> and if you look at this file you can plainly see that it bootstraps their API and creates a `&#60;script&#62;` element to load the actual API. You could, in theory (I haven't tested it) create a local file that has this source and it would work but it's a hack and I wouldn't recommend it. Yeah, I have see someone do this and the reason was because they really didn't have any other way to load the Google Maps API before their app was launched which I couldn't blame them for trying it.

## Savior

I haven't dug into the source for Sencha Command and the microloader (`Ext.blink`) so I took it upon myself to jump head first to implement a way to load remote files using a simple config in `app.json`. I wanted to add a simple and descriptive config to the config objects you can put into the `js` array and the `"remote"` config was born. This config would mark that resource as being a remote file and accepts `true` or `false` (defaults to `false`, well, `undefined` really but it's falsey so the same in this instance).

## Sencha Touch 2.0.2

First thing I notice while digging into Sencha Command was that it copies the files to the `build` folder in a couple places. A few `if` statements and solved that issue. Tested and things were working great! I didn't do enough testing admittedly and this was released for Sencha Touch 2.0.2. <a href="http://twitter.com/themightychris" target="_blank">@themightychris</a> (Chris Alfano from Jarv.us Innovations) tweeted about how to load remote files in Sencha Touch 2 and as a proud father of what I thought worked I told him about the `"remote"` config. He replied with errors... oh boy. I should have known it was too easy to throw a couple `if` statements at a problem and expect it to work fully. The next day I didn't do any work on the Forums until I fixed it, my fault, my problem, my fix.

What it does now is when Sencha Command builds the `index.html` it will create `&#60;script&#62;` elements for your remote JavaScript files and `&#60;link&#62;` elements for your remote CSS files. The microloader, the system responsible for actually loading the resources, submits Ajax calls to load the assets and once all the assets have been loaded it then kicks off your application's `launch` method. So why create `&#60;script&#62;` files in the builder and not let the microloader do the loading? The issue I came across is I couldn't accurately determine when the Google Maps API was loaded due to it creating it's own `&#60;script&#62;` tag as mentioned before (see why I explained that now?). I could determine when the `&#60;script&#62;` element that I created would load but not the `&#60;script&#62;` element the Google Map bootstrap element I created would create so the `launch` method would fire before the Google Maps API was actually loaded causing issues with my `Ext.Map` test. So not knowing what people will use I felt creating `&#60;script&#62;` elements in the `index.html` the safest solution. So once you do a production build, you can see the `&#60;script&#62;` elements in `index.html` that Sencha Command created. Not the prettiest solution but sometimes you just don't have the control you want. This fix will be part of the next release (2.0.3 I believe it will be) but for you premium users it should be in SVN and part of the nightly builds you can get from <a href="http://support.sencha.com/" target="_blank">http://support.sencha.com/</a>

## Example

Enough backstory, I know you are craving some code! Diving into the Sencha Touch 2.0.3 directory I created a simple app:

```sh
cd ~/Sites/sencha-touch-2.0.3
sencha app create MyApp ../MyApp
```

Simple to create an app isn't it? Hell yeah it is (I was a doubter but now I'm a promoter)! I then edited the `MyApp.view.Main` class to add an `Ext.Map` item as the 2nd item so I opened the `~/Sites/MyApp/view/Main.js` in my editor (IntelliJ IDEA if you were wondering) and added this code as index 1:

```js
{
    xtype   : 'map',
    title   : 'Map',
    iconCls : 'maps'
},
```

and of course added `Ext.Map` to the `requires` array at the top of the file. So now we have our view using `Ext.Map` which will use the Google Maps API so we need to add the JavaScript file in `app.json` so I opened `app.json` and made 2 edits. First I added this code after the `sencha-touch.js` asset in the `js` property array:

```json
{
    "path": "http://maps.google.com/maps/api/js?sensor=true",
    "remote": true
},
```

and then at the bottom to get around a current error I changed the `logger` config to `false`:

```json
"buildOptions": {
    "product": "touch",
    "minVersion": 3,
    "debug": false,
    "logger": false
},
```

So now `app.json` is going to tell Sencha Command to include the Google Maps' remote JavaScript file and the display the map in my `MyApp.view.Main` tab panel. First I need to test to make sure everything is working so I do a testing build:

```sh
cd ~/Sites/MyApp
sencha app build testing
```

Launched <a href="http://localhost/MyApp/build/testing/" target="_blank">http://localhost/MyApp/build/testing/</a> in Chrome (my browser of choice) and everything displayed just fine, my map shows correctly (centered South-East of San Jose California because I didn't tell it to center anywhere and that's default). More importantly I checked out the console and there were not errors! Great, so from everything I know thus far my app is working perfectly so now I can deploy with a production build:

```sh
sencha app build production
```

Launched <a href="http://localhost/MyApp/build/production/" target="_blank">http://localhost/MyApp/build/production/</a> in Chrome (yup, still my favorite browser) and everything works perfectly!

## Summary

So we learned some backstory on the issue at hand and the little bumpy road to the fix that is the `"remote"` config for your JavaScript and CSS assets in `app.json`. We then looked at building a simple example all using Sencha Command.

Happy coding!


Going Remote with Sencha Command


Once in a while the topic of using the `var me = this;` convention is brought up. Some people love it, some people hate it and some people don't understand it. Usually the people who love it or hate it understand the convention (or may not fully understand it) but there seems to be quite a few people who do not understand it. I use the variable me as an example but you could name it anything and it won't change it, even to the beloved `var that = this;` and what I will say will still hold true. The decision on whether to use `var me = this;` is purely for minification and therefore saving bytes. However, it could also cost you bytes if you don't realize what you are doing or maybe think you will need to use it when you start coding and don't go back to clean your code up. Let's start experimenting!

## Control

Let's look at a control method that you may have somewhere in your code:

```js
saveSomething : function(foo, status, scope) {
    this.foo = foo;

    this.myObj = {
        mitch : status
    };

    this.onSave.call(scope);
}
```

If we look at this, we use `this` 4 times. All looks great so far! We have a method that saves the first two arguments and then calls a method.

## New Feature!

So our control `saveSomething` method has been working quite well but we realize that we should do some error checking, we can make the `scope` argument optional and we decide we need to pass a method in the `onSave` method call. Let's look at an example of how we can do it and then circle back to see if we can do a little better:

```js
saveSomething : function(foo, status, scope) {
    var myObj = this.myObj;

    scope = scope || this;

    if (!myObj) {
        myObj = this.myObj = {};
    }

    this.foo = foo;

    myObj.mitch = status;

    this.onSave.call(scope, this.saveSomethingCallback);
}
```

So here we created a variable `myObj` to equate to `this.myObj`. However, `this.myObj` may be undefined so we added an `if` statement to check and if it is undefined (or falsey) set the `myObj` variable and `this.myObj` property to an Object. Also, we made `scope` default to `this` with the `scope = scope || this;` so if the `scope` argument is undefined (or falsey) it will then equate to `this` making it an optional argument (IMO a little more robust). Lastly we pass the `saveSomethingCallback` method in the `onSave` call as an argument to be executed later in our code.

## Minification

So now we have a little better of a method but it can get better! When we deploy our code we should always minify our code so it's as small as can be reducing what the client has to download but still maintain code functionality. This does many things but what I want to talk about is how it minifies variables. This small example:

```js
var foo = 'bar';
```

can get minified to

```js
var a='bar';
```

which saves 4 bytes as `foo` got renamed to `a` and the spaces before and after the equal sign got trimmed. Thinking back to our `saveSomething` method we can think that `this` will get minified to something like `a` just like the foo variable got renamed. Unfortunately, `this` (and other JavaScript keywords like `delete` or `new`) will not get minified. To combat this, we can create a variable to cache this and that variable can then get minified. This is where the `var me = this;` convention comes into play as we are going to cache `this` to the `me` variable and `me` will get minified:

```js
saveSomething : function (foo, status, scope) {
    var me    = this,
        myObj = me.myObj;

    scope = scope || me;

    if (!myObj) {
        myObj = me.myObj = {};
    }

    me.foo = foo;

    myObj.mitch = status;

    me.onSave.call(scope, me.saveSomethingCallback);
}
```

We put the `me = this` in the variable block at the beginning of the method and replaced all `this` instances with `me`. We can now minify it and save 3 bytes per `this` instance for a total of 18 bytes (`this` was used 6 times in the `saveSomething` method before we applied the `me = this` convention and 6 x 3 = 18). However `me = this` also costs us some bytes, in fact in this example it cost us 8 bytes not including the spaces between `me` and `this` as they will get trimmed when it's minified. So in total we saved 10 bytes after the `var me = this` convention which doesn't account for much but if you have a sizable app it can add up and if you ask me, every bit saved counts.

## Trouble!

This convention doesn't come without a dark side. Applying this convention without counting the bytes that the `me = this` takes up and what you will save after minification will cost you bytes. If we go way back to the first `saveSomething` method and applied the `var me = this;` convention we will have costed some bytes:

```js
saveSomething : function(foo, status, scope) {
    var me = this;

    me.foo = foo;

    me.myObj = {
        mitch : status
    };

    me.onSave.call(scope);
}
```

The `var me = this;` would cost us 11 bytes (it would be `var a=this;` after minification). For every instance of `this` we replaced we save 3 bytes and we had 3 instances so we save 9 bytes but the `me` variable line cost us 11 so we saved -2 bytes which is bad. We are trying to save bytes not add them.

## Two Types

In these examples you saw the `me` variable get created by itself and in a variable block. If you have `me = this` in a variable block where there are other variables it costs less as we don't have to add the `var` keyword. Let's look at the byte cost:

```js
var me = this;
var a=this; //minified
```

The minified version costs 11 bytes so you would have to use this 4 or more times to save bytes in the long run.

```js
var me  = this,
    foo = 'bar';
var a=this,b='bar'; //minified
```

`a=this`, costs 7 bytes so you would have to use this 3 or more times to save bytes in the long run.

## Review

Using the `var me = this;` convention is purely to save some byte because `this` cannot be minified but `me` can. The savings won't be drastic but every little bit helps but you have to be cautious as it could cost you bytes. If you ask me, this is a code style issue also and code style (quality) should be just as high of a priority as what your code is doing. I take my code style very seriously so lining colons and equal signs up and also applying `me = this` wherever it will save a byte is very important to me.

A downside to this, which is just a visual annoyance, is in your IDE you probably have syntax highlighting and keywords usually get a blue (or other color depending ont he IDE) highlight but `me` will not so you can't easily visually see the scope. My eyes simply have been trained to see me easily but I do miss seeing `this` highlighted. The syntax highlighting in the above examples show this.

Results may vary.


var me = this; convention


Many times when developing a Sencha Touch 2 app I often have to call remote data with a `Store` to fill `List`s. Simple thing to build a `Store` with a `Proxy` pointing to some server side script or `JSON` file. Simple stuff. Lately I have been using <a href="http://nodejs.org/" title="Node.js" target="_blank">Node.js</a> for many of my servers but this can still be used if you are using <a href="http://www.apache.org/" title="Apache" target="_blank">Apache</a> + <a href="http://www.php.net/" title="PHP" target="_blank">PHP</a> or <a href="http://www.silkjs.org/" title="SilkJS" target="_blank">SilkJS</a> or whatever. I test the server code locally but of course when I deploy I will have the remote server setup and want to use the remote server for production and local server for development as I'm sure many are also doing. Before starting, this is assumed you have a fresh app created using Sencha Command via:

```sh
cd /path/to/sencha-touch-2.0.1.1/
sencha app create Test ../Test
```

Since I have different environments with different a different base url for each environment I create a `Config` utility class to easily change the base url for when I deploy. This utility class looks like this in a simple form:

```js
Ext.define('Test.util.Config', {
    singleton : true,

    config : {
        baseUrl : 'http://www.mitchellsimoens.com/'
    },

    constructor : function(config) {
        this.initConfig(config);

        this.callParent([config]);
    }
});
```

So this will create a `Test.util.Config` singleton class which we can execute the `Test.util.Config.getBaseUrl()` in your `Store`s like so:

```js
Ext.define('Test.store.Users', {
    extend : 'Ext.data.Store',

    requires : [
        'Test.model.User'
    ],

    config : {
        autoLoad : true,
        model    : 'Test.model.User',
        proxy    : {
            type  : 'ajax',
            url   : Test.util.Config.getBaseUrl() + 'get/users'
        }
    }
});
```

When the `Users.js` file is evalutaed by the browser it will execute the `Test.util.Config.getBaseUrl()` and so the url that is on the prototype is actually `'http://www.mitchellsimoens.com/get/users'` which is fantastic. To make this work your `app.js` file should look like (removed some code):

```js
Ext.Loader.setPath('Test', 'app');

Ext.require([
    'Test.util.Config'
]);

Ext.application({
    //..

    stores : [
        'Users'
    ]
});
```

So we have an application with a `Users Store` and a `Config` utility class and the Users store is autoLoading from `http://www.mitchellsimoens.com/get/users` but we are still in development so we want to hit `localhost` not `www.mitchellsimoens.com`. We could just change the `baseUrl` config in `Test.util.Config` but that's manual and there is an automatic way for when you do a build and that is using `//&#60;debug&#62;` and `//&#60;/debug&#62;`. When you do any build:

```sh
cd /path/to/Test
sencha app build [testing|production|package|native]
```

Anything between the `//&#60;debug&#62;` and `//&#60;/debug&#62;` will automatically get removed. Get where I am going? So instead of manually changing the `baseUrl`, just do something like:

```js
Ext.define('Test.util.Config', {
    singleton : true,

    config : {
        baseUrl : 'http://www.mitchellsimoens.com/'
    },

    constructor : function (config) {
        this.initConfig(config);

        this.callParent([config]);
    }
//<debug>
},
function () {
    this.setConfig({
        baseUrl : 'http://localhost/'
    });
//</debug>
});
```

What this will do is when the `Ext.define` is finished creating the class definition and creating the singleton class it will execute the callback function which we are using to set the `baseUrl` config to `'http://localhost/'` which is overriding the `'http://www.mitchellsimoens.com/'`. And since we wrapped the new code in `//&#60;debug&#62;` and `//&#60;/debug&#62;` it will remove this override when we do any of the builds automatically switching the `baseUrl` for us not manually.

Further more, when you use `requires` and `uses` properties when creating class definitions you can remove those lines saving some space as they should all be within the built `app.js` file. So our `Users Store` we have above could be:

```js
Ext.define('Test.store.Users', {
    extend : 'Ext.data.Store',

    //<debug>
    requires : [
        'Test.model.User'
    ],
    //</debug>

    config : {
        autoLoad : true,
        model    : 'Test.model.User',
        proxy    : {
            type  : 'ajax',
            url   : Test.util.Config.getBaseUrl() + 'get/users'
        }
    }
});
```

And that will remove the `requires` property when you do a build saving 3 lines (plus the two for the debug comments) as it's not needed in a production build.

This is a trick of the trade that I found when developing Sencha Touch 2 apps using Sencha Command and one trick that I am really loving!


Build configs using Sencha Command


I'm a very open and honest person; I don't try to be something I'm not. I will always admit I don't know everything which is actually one of the values of myself that I hold dear, it helps me always push myself.

Some of you may have noticed that I got engaged recently and am trying to plan a wedding which looks to be end of April 2013 so Danielle and I have plenty of time to plan. First up is location and picking guest list and the wedding party. All this planning is both fun and overwhelming, I knew there would be a lot of things but dealing with a woman who has been thinking about ideas for last 25 or so years quite a lot to keep up with.

Back when I was a teenager I was a very sensitive person which I allowed for things to hurt me. So as I matured I tried to grow away from that and have successfully been able to control my emotions a lot more. Hell, controlling what I think about has become pretty easy minus the big life things. So as I am planning the wedding and picking my wedding party I realized something that, to be honest, bothers me... friends.

When I was young, talking before I was 16, I had friends that I would hang out with. Once I started working I lost those friends and gained new ones which is fine. I've gone through a couple evolutions in my life and in each evolution I lost all my friends as they weren't able or willing to be ok with my changes. They were friends but not good friends. There is one friend that has stuck with me for last 10 years and no doubt will be (and has accepted) to be my best man but I can't have a wedding party of one. In my current evolution, my "geek" evolution I have made many new friends and am very happy with where I am with these friends but it still bothers me that I don't have more friends from back when I was a kid or a teenager. I have pretty much chosen who is in my wedding party (haven't asked everyone yet) and couldn't be more thrilled for the group of guys I will be having don't get me wrong, I have been in a couple wedding recently and see them having friends that have been around for a long time.

I guess the moral of this is growing up sucks. You want to hold on to what was but still move towards what will be. It's a struggle, it's a personal struggle. I have told Danielle that you can't live in the past, all you can do is learn and move on. But your past is what made you, what sculpted you.

Disclaimer - I know this is personal and not really tech related but it is therapeutic to write things.


Fullscreen Madness!


Being full-time on the <a href="http://www.sencha.com/forums/" title="Sencha forums" target="_blank">Sencha forums</a> gives me direct access to the community which gives me an idea of some frequently asked questions that I hope to blog more to answer.

## Mission

Building applications with Ext JS 4 is very easy with the MVC architecture but sometimes it's not always easy to know how to use MVC with certain widgets or features of Ext JS 4. Today I would like to discuss how I went about using ActionColumns and MVC specifically how to control when you click on an ActionColumn item within a controller.

## Setting the Stage

Let's set the stage! I'm going to use the Array Grid example that comes with every Ext JS release but turn it from an ordinary example into a more MVC example. Here are the controller, model, view and application code that we can start with:

```js
Ext.define('Mitch.controller.Main', {
    extend : 'Ext.app.Controller',

    init : function() {
        //this.control will go here
    }
});

Ext.define('Mitch.model.Company', {
    extend : 'Ext.data.Model',

    idProperty : 'company',
    fields     : [
        { name : 'company'                                            },
        { name : 'price',      type : 'float'                         },
        { name : 'change',     type : 'float'                         },
        { name : 'pctChange',  type : 'float'                         },
        { name : 'lastChange', type : 'date', dateFormat : 'n/j h:ia' }
    ]
});

Ext.define('Mitch.view.Viewport', {
    extend : 'Ext.grid.Panel',
    xtype  : 'mitch-viewport',

    multiSelect : true,
    height      : 350,
    width       : 600,
    title       : 'Array Grid',

    initComponent : function() {
        var me = this;

        me.columns    = me.buildColumns();
        me.store      = me.buildStore();
        me.viewConfig = {
            stripeRows          : true,
            enableTextSelection : true
        };

        Mitch.view.Viewport.superclass.initComponent.call(me);
    },

    buildStore : function() {
        return new Ext.data.Store({
            model : 'Mitch.model.Company',
            data  : [
                ['3m Co',                               71.72, 0.02,  0.03,  '9/1 12:00am'],
                ['Alcoa Inc',                           29.01, 0.42,  1.47,  '9/1 12:00am'],
                ['Altria Group Inc',                    83.81, 0.28,  0.34,  '9/1 12:00am'],
                ['American Express Company',            52.55, 0.01,  0.02,  '9/1 12:00am'],
                ['American International Group, Inc.',  64.13, 0.31,  0.49,  '9/1 12:00am'],
                ['AT&amp;T Inc.',                           31.61, -0.48, -1.54, '9/1 12:00am'],
                ['Boeing Co.',                          75.43, 0.53,  0.71,  '9/1 12:00am'],
                ['Caterpillar Inc.',                    67.27, 0.92,  1.39,  '9/1 12:00am'],
                ['Citigroup, Inc.',                     49.37, 0.02,  0.04,  '9/1 12:00am'],
                ['E.I. du Pont de Nemours and Company', 40.48, 0.51,  1.28,  '9/1 12:00am'],
                ['Exxon Mobil Corp',                    68.1,  -0.43, -0.64, '9/1 12:00am'],
                ['General Electric Company',            34.14, -0.08, -0.23, '9/1 12:00am'],
                ['General Motors Corporation',          30.27, 1.09,  3.74,  '9/1 12:00am'],
                ['Hewlett-Packard Co.',                 36.53, -0.03, -0.08, '9/1 12:00am'],
                ['Honeywell Intl Inc',                  38.77, 0.05,  0.13,  '9/1 12:00am'],
                ['Intel Corporation',                   19.88, 0.31,  1.58,  '9/1 12:00am'],
                ['International Business Machines',     81.41, 0.44,  0.54,  '9/1 12:00am'],
                ['Johnson &amp; Johnson',                   64.72, 0.06,  0.09,  '9/1 12:00am'],
                ['JP Morgan &amp; Chase &amp; Co',              45.73, 0.07,  0.15,  '9/1 12:00am'],
                ['McDonald\'s Corporation',             36.76, 0.86,  2.40,  '9/1 12:00am'],
                ['Merck &amp; Co., Inc.',                   40.96, 0.41,  1.01,  '9/1 12:00am'],
                ['Microsoft Corporation',               25.84, 0.14,  0.54,  '9/1 12:00am'],
                ['Pfizer Inc',                          27.96, 0.4,   1.45,  '9/1 12:00am'],
                ['The Coca-Cola Company',               45.07, 0.26,  0.58,  '9/1 12:00am'],
                ['The Home Depot, Inc.',                34.64, 0.35,  1.02,  '9/1 12:00am'],
                ['The Procter &amp; Gamble Company',        61.91, 0.01,  0.02,  '9/1 12:00am'],
                ['United Technologies Corporation',     63.26, 0.55,  0.88,  '9/1 12:00am'],
                ['Verizon Communications',              35.57, 0.39,  1.11,  '9/1 12:00am'],
                ['Wal-Mart Stores, Inc.',               45.45, 0.73,  1.63,  '9/1 12:00am']
            ]
        });
    },

    buildColumns : function() {
        return [
            {
                text      : 'Company',
                flex      : 1,
                sortable  : false,
                dataIndex : 'company'
            },
            {
                text      : 'Price',
                width     : 75,
                sortable  : true,
                renderer  : 'usMoney',
                dataIndex : 'price'
            },
            {
                text      : 'Change',
                width     : 75,
                sortable  : true,
                renderer  : 'usMoney',
                dataIndex : 'change'
            },
            {
                text      : '% Change',
                width     : 75,
                sortable  : true,
                renderer  : function(v) { return v + '%'; },
                dataIndex : 'pctChange'
            },
            {
                text      : 'Last Updated',
                width     : 85,
                sortable  : true,
                renderer  : Ext.util.Format.dateRenderer('m/d/Y'),
                dataIndex : 'lastChange'
            },
            {
                xtype        : 'actioncolumn',
                menuDisabled : true,
                sortable     : false,
                width        : 50,
                items        : [
                    {
                        icon    : '../SDK/extjs/examples/shared/icons/fam/delete.gif',
                        tooltip : 'Sell stock',
                        handler : function(grid, rowIndex, colIndex) {
                            var rec = store.getAt(rowIndex);
                            alert('Sell ' + rec.get('company'));
                        }
                    },
                    {
                        getClass : function(v, meta, rec) {
                            if (rec.get('change') < 0) {
                                this.items[1].tooltip = 'Hold stock';
                                return 'alert-col';
                            } else {
                                this.items[1].tooltip = 'Buy stock';
                                return 'buy-col';
                            }
                        },
                        handler  : function(grid, rowIndex, colIndex) {
                            var rec = grid.getStore().getAt(rowIndex);
                            alert((rec.get('change') < 0 ? 'Hold ' : 'Buy ') + rec.get('company'));
                        }
                    }
                ]
            }
        ];
    }
});

Ext.application({
    name        : 'Mitch',
    controllers : [ 'Main' ],

    launch : function() {
        new Mitch.view.Viewport({
            renderTo : document.body
        });
    }
});
```

Bunch of code but very easy to follow. Currently the Main controller doesn't do anything and you can see we have two items under the ActionColumn but it's not very MVCish. I know you can use the ComponentQuery 'mitch-viewport actioncolumn' to resolve the ActionColumn so in the Main controller I just decided to test if I can listen to the a click event on the ActionColumn in a controller and it actually worked! Here is how to capture the click event:

```js
Ext.define('Mitch.controller.Main', {
    extend : 'Ext.app.Controller',

    init : function() {
        this.control({
            'mitch-viewport actioncolumn' : {
                click : this.handleActionColumn
            }
        });
    },

    handleActionColumn : function(gridview, el, rowIndex, colIndex, e, rec, rowEl) {
        console.log(arguments);
    }
});
```

So if you click on an item in the ActionColumn the controller will console.log the arguments out so you can inspect them. You could actually stop here and use this as is but upon inspecting the different arguments (there are quite a few) I saw a problem... there isn't an easy way to distinguish which icon in the ActionColumn was actually clicked on. You could add some logic in to look look at the actual target to see which icon was clicked on but there is an easier and less expensive way than parsing the DOM.

## Custom Events

I would hope we all know that you don't have to stick with the default events that are fired within the framework, we can actually fire custom events using fireEvent but I know I didn't have that thought when I first started off. So why not use fireEvent within the handler of each item in the ActionColumn so that we don't have to dig into the DOM? Why have a catch-all click event that is on the column? We can have a general event that is fired but easily distinguishable from one another and name it 'itemclick'!

## Fire `itemclick`

So we chose to fire a custom event call 'itemclick', first we need to decide what kind of arguments we want to fire this event with. The scope of the handler is that of the ActionColumn which is where we are going to fire the event on. We would maybe want the ActionColumn, grid, rowIndex, colIndex, record, eventObject, the node clicked on and since we are firing the event, we can make it easy on ourselves and put a custom argument to tell the action we should take. Let's look at the code:

```js
{
    xtype        : 'actioncolumn',
    menuDisabled : true,
    sortable     : false,
    width        : 50,
    items        : [
        {
            icon    : '../SDK/extjs/examples/shared/icons/fam/delete.gif',
            tooltip : 'Sell stock',
            handler : function(grid, rowIndex, colIndex, node, e, record, rowNode) {
                this.fireEvent('itemclick', this, 'sell', grid, rowIndex, colIndex, record, node);
            }
        },
        {
            getClass : function(v, meta, rec) { /* */
            },
            handler  : function(grid, rowIndex, colIndex, node, e, record, rowNode) {
                var action = record.get('change') &lt; 0 ? 'hold' : 'buy';
                this.fireEvent('itemclick', this, action, grid, rowIndex, colIndex, record, node);
            }
        }
    ]
}
```

So you can see how we can use the fireEvent and fired the 'itemclick' event onto this which is the ActionColumn. Now we can update the Main controller like this:

```js
Ext.define('Mitch.controller.Main', {
    extend : 'Ext.app.Controller',

    init : function() {
        this.control({
            'mitch-viewport actioncolumn' : {
                itemclick : this.handleActionColumn
            }
        });
    },

    handleActionColumn : function(column, action, grid, rowIndex, colIndex, record, node) {
        console.log(action);
    }
});
```

If you update the view and the controller now and click on an icon in the ActionColumn, you would see the action console.log into the developer tools console being one of these options: 'sell', 'hold' or 'buy'. Now based on that action we can then do whatever application and business logic that is required. Since we have the power of firing our own event you could actually fire the event on the grid itself so that your control method in your controller is easily managable and not have too many different ComponentQuery selectors but I would prefix the 'itemclick' event with 'action' so that the event name means something and doesn't collide with any existing events.

## Recap

First we took the Array Grid example and turned it into a simple MVC application. We then tested to see what events fire on the ActionColumn that we could use and found the click event was fired on the ActionColumn even though that particular event is documented in the API docs (I looked at the source for the ActionColumn and saw the possibility, don't be afraid to look at the source!). We inspected the arguments that are fired with the click event and saw that we could use it but would have to query the DOM to see which item in the ActionColumn was actually clicked on. We decided that there could be a less expensive way to accomplish what we wanted to do than to play with the DOM as doing anything with the DOM (read/write) has a high performance hit. We found out we can fire our own events which should be faster than the DOM and so we modified our code to do this and found out it was very simple to do! Now we can go forth and do actual actions with our custom 'itemclick' event!


ActionColumn and MVC


**Note** As of Ext JS 5 this blog is not true. We have made changes to Ext JS to handle the listeners as a property. In face, for MVVM, this is now the recommended practice. In Ext JS 6, a subclass cannot override the superclass' listeners property.

Recently I have noticed a lot of people on the forums using the `listeners`, in my opinion, the wrong way. Being event driven is a great tactic in application development, one that I often use. Template methods are great and have their uses but for things that are reacting to user interactions, events are going to be your best friend.

Let's look at a quick piece of code. Grids are used a lot and I often create an abstract class to handle all my grids as most of the stuff in grids can be abstracted out instead of having tons of duplicate code.

```js
Ext.define('MyApp.view.grid.Abstract', {
    extend : 'Ext.grid.Panel',
    alias  : 'widget.myapp-grid-abstract',

    initComponent : function() {
        Ext.apply(this, {
            dockedItems : this.buildDocks(),
            selModel    : this.buildSelModel()
        });

        this.callParent(arguments);
    },

    buildDocks : function() {
        var docks = Ext.Array.from(this.dockedItems);

        docks.push({
            xtype : 'toolbar',
            dock  : 'top',
            items : [
                {
                    text     : 'Delete',
                    disabled : true,
                    action   : 'delete'
                }
            ]
        });

        return docks;
    },

    buildSelModel : function() {
        return {
            type : 'rowmodel',
            mode : 'SIMPLE'
        };
    }
});
```

So you can see from this code (which usually isn't the entire abstract class) that we are adding a top docked `Ext.Toolbar` with a disabled delete button and defining a selection model with `mode` set to 'SIMPLE'. The delete button should enable and disable based on the number of rows selected, disabled if the number of rows selected is zero, otherwise enable it. Usually you would extend an abstract class but for this blog we will just instantiate the abstract class like this:

```js
new MyApp.view.grid.Abstract({
    renderTo : Ext.getBody(),
    width    : 400,
    height   : 400,
    title    : 'Test Grid',
    columns  : [
        {
            header    : 'Row',
            flex      : 1,
            dataIndex : 'row'
        }
    ],
    store    : new Ext.data.Store({
        fields : ['row'],
        data   : [
            { row : 'One'   },
            { row : 'Two'   },
            { row : 'Three' },
            { row : 'Four'  },
            { row : 'Five'  }
        ]
    })
});
```

So now we have a grid rendering as expected, time to handle the user interaction using the `selectionchange` event on the grid panel. This is where the problem lies. I have seen many developers add `listeners` like this:

```js
Ext.define('MyApp.view.grid.Abstract', {
    extend : 'Ext.grid.Panel',
    alias  : 'widget.grid-abstract',

    listeners : {
        selectionchange : function(selModel, selected) {
            var view = selModel.view,
                grid = view.up('gridpanel'),
                btn  = grid.down('button[action=delete]');

            btn.setDisabled(selected.length === 0);
        }
    },

    initComponent : function() {
        /**/
    },

    buildDocks : function() {
        /**/
    },

    buildSelModel : function() {
        /**/
    }
});
```

Notice the `listeners` property we just set on the class' prototype. And this works but I have always been told just because it works doesn't mean it's right; to me, this is an invalid use of `listeners`. `listeners` is listed as a config option so what happens when you instantiate the class like so:

```js
new MyApp.view.grid.Abstract({
    /**/
    listeners : {
        afterrender : function() {
            console.log('my grid has rendered!');
        }
    }
});
```

Now, try to enable that delete button by selecting a row. Did it work? The problem here is anything you pass in the config object will overwrite anything you set on the prototype in `Ext.define` so the `listeners` you set to listen for the `selectionchange` event is now overwritten by the `listeners` config object listening for the `afterrender` when we instantiated. You now easily broke your abstract class. This is why you should never use `listeners` when using `Ext.define`.

So how do we go about to rectify this situation so that we can have our config listeners not overwrite our class listeners? The simple usage of `on()` will allow this, the only cavet is that we have to clean up the listener but that's simple. Let's delete the `listeners` from the `Ext.define` and put the `on()` usage into `initComponent` and use `un()` in `beforeDestroy`:

```js
Ext.define('MyApp.view.grid.Abstract', {
    extend : 'Ext.grid.Panel',
    alias  : 'widget.grid-abstract',

    initComponent : function() {
        var me = this;

        Ext.apply(me, {
            dockedItems : me.buildDocks(),
            selModel    : me.buildSelModel()
        });

        me.callParent();

        me.on('selectionchange', me.handleSelectionChange, me);
    },

    beforeDestroy: function() {
        var me = this;

        me.un('selectionchange', me.handleSelectionChange, me);

        me.callParent(arguments);
    },

    buildDocks : function() {
        /**/
    },

    buildSelModel : function() {
        /**/
    },

    handleSelectionChange : function(selModel, selected) {
        var view = selModel.view,
            grid = view.up('gridpanel'),
            btn  = grid.down('button[action=delete]');

        btn.setDisabled(selected.length === 0);
    }
});
```

Can you see where I used `on()` and `un()`? Now, when you render the grid, the listeners you placed in the config object that has an `afterrender` listener gets executed and if you select a row, the delete button will now enable.

Awesome! Now we have a full functional abstract class that has event listeners that cannot be affected when instantiating a class.


Ext.define and listeners as a property... bad!


I thought I would start this blog off by introducing myself. Many have talked to me but probably don't know how I became the man I am today. It was a rough road but here it is, I won't spend years talking about it, I promise.

## Early Years

Born in Iowa City, Iowa USA on February 2, 1984 (on a farm), I moved down to Saint Louis, Missouri USA in 1988 where I have called home ever since. I was a shy, quiet yet adventurous child. I never had lots of friends but kept a small group close. I was into sport, soccer being my favorite and devoted lots of my time practicing which didn't leave me much time to spend inside playing video games.

## Teen Years

Like I said, I was an adventurous child I would go places where I shouldn't go. I lived in the suburbs of Saint Louis so it's not like I could get into much trouble. There used to be lots of trails and creeks where I used to ride my bike doing tricks... trying to at least. I stopped playing soccer and decided to tear appart my parent's $4,000 Compaq. My mother came home with everything spread around the room. Little later I got everything put back together and told her I wasn't too sure I'd get that back together; this is what started my whole nerdness. I started learning by dissecting so when I got a truck when I turned 16, installing a head unit was a fun experiment. Using the Compaq, I started playing online games and joined an online group. This is where I fell into web design as they needed someone to help and I took on that challenge. Of course it was using Frontpage and Geocities but had to use existing Perl scripts but ditched that for PHP. For the next couple years I would spend 100% of my time within PHP. When I turned 16, I also started working at QuikTrip (convenient store chain around the USA) and thought that was what I was going to do for the rest of my life. It took priority over everything, school included. Growing up the way I did, my work ethic was top notch. Working 15 hours wouldn't be a problem to me.

In the middle of the teen years, I tried escaping a problem I had. My father and I were close; hunting, fishing, sports were things that we did together a lot. The problem I felt is that we would never express our feelings toward each other. He would just push me to be better and if I didn't live up to what he expected me to be, I felt he was disappointed in me. My family has a history of depression and I look back and I wish I would have seen this and prevented myself going down that road. I tried to work more and keep myself active but I would have terrible mood swings. The smallest thing would set me off. Alcohol would also play a large roll in all of this. This would go on for the better part of a decade.

## Adult Years

After high school, I tried going to Maryville University here in Saint Louis going for a degree in eCommerce. I didn't mind going to school but QuikTrip always trumped it so I bailed out after half a semester. I would then focus on my career at QuikTrip keeping my hobby of web developing on the side. My father also works at QuikTrip and has been very successful and for the first time I felt like he was proud of my accomplishments at following him in his footsteps. I started moving up and taking on projects but keeping him in the dark about my drinking and depression. Going to work drunk was fine as long as I had cologne to mask the smell and energy drinks to keep me awake as I wouldn't sleep. I stayed away from pills or marijuana and have never tried that; I take pride in this actually.

I haven't talked much about females in my life as they weren't really my priority. Yes, I dated and lost my virginity at age 16 but I just didn't really care about them. After high school they played more of a role. I always seemed to get good looking girls but they would use me because working at QuikTrip I made great money. I built a house, had a truck, car (1994 Ford Mustang 5.0), and a motorcycle (Kawasaki Ninja 600R) all before I could legally drink. Started building my house when I was 19. I would do anything for the girl in my life but looking back, it seems they took advantage of me. Maybe not their fault as I let them. This would not help my depression and confidence. This eventually would teach me about myself and help me later on.

When I was 22, one night waking up in my own vomit, I decided to stop drinking. After that decision, I would only drink socially. I still got drunk once in a while but wouldn't even be close to drinking like I used to. I went from drinking almost every waking minute to only having a couple here and there. This self control really made myself start taking a long look at what kind of man I was growing up to be. I started taking more action to improve myself and I would have to hit rock bottom and rebuild myself. I quit QuikTrip, foreclosed on my house, moved back in with my parents. Was out of work for 2 months before I started working at Sam's Club. I was seasonal but after 2 weeks turned full-time. When I start a new job, I work very hard to make myself a crucial asset to my employer. Started making my way up but saw some questionable things being done by management (TVs went missing, favoritism, etc) so I stepped down and kind of was just living day by day. I turned to my hobby of web developing and started contracting. This was just a side job and never really took off.

## Love of my life :)

Early 2008 my mother went to visit one of her long time friends. They used to work next door to each other for many many years at the U.S. Department of Veterans Affairs but in 2007 my mother's friend got a divorce and moved to Florida to pursue a different job within the U.S. Department of Veterans Affairs and her daughter moved down a couple months later. As my mother was down there, her daughter (Danielle Collins) started texting me and we hit it off right away. 2 months later on May 3rd, over the phone and hundreds of miles away, I asked Danielle if she would be my girlfriend. About every other month, one of us would fly to the other to actually see each other, when we were away from each other, Skype had to do. Long distance isn't easy but I do believe it allowed us to really connect and become each other's best friend. Fast forward to August 2011, after over 3 years of dating we finally decided to make the hard decision of having her quit her job and move in with me. This was a huge and scary step in our relationship but enough was enough with long distance. We have been living together for a few months now and things couldn't be going better. Sure we have our little arguments ehre and there but the transition from being a thousand miles away from each other to seeing each other each day hasn't been as hard as I was afraid. I would do anything for her and hope to get engaged this next year as soon as I find a ring that I am proud to give her.

## Ext JS/Sencha Years

Around 2004/2005 I started pushing myself to learn more about web developing. I was using Prototype, Scriptaculous and whatever else I could get my hands on. My thirst for knowledge was driving me in a million directions. It wasn't till late in 2007 till I heard of this Ext JS and dropped everything and started trying to wrap my head around this. Early 2008 I jumped on the forums asking for help... I was very green. Next couple years my thirst for knowledge really pushed me to learn a lot about Ext JS and people like Jay Garcia, Nige "Animal" White, Shea "VinylFox" Fredricks, Condor really helped me out. It wasn't till 2010 until I started getting some traction after helping with the book Ext JS in Action authored by Jay Garcia and some projects. People started coming to me for work so things were looking up. October 2010 I had a full-time opportunity as a web developer so I quit Sam's Club to pursue web developing as a career. The guy I was working for didn't like my coding style so he made me code like him. After 3 months of working for him and not liking it, I had another opportunity and took it. I like the guy I was working for, I can work from home, and the pay was great compared to what I was making. In a matter of about 4 months, my pay quadrupled! I thought I would work there for a long time but then I got an email from Ed Spencer at Sencha. At first, I was reluctant because I felt quite loyal to my current boss but I decided to give it a shot so I was flown out to Redwood City, CA USA for my interview. I then talked to Jeff Hartley who seemed very happy to speak with me and decided to offer me a job. I went back home and struggled to make a decision. After talking to family and friends, I decided that it was in my best interest to accept Sencha's offer and handed in a one month notice to my current boss so that I could finish up things and he could find my replacement.

Joining Sencha in March of 2011 as part of the Professional Services team, I quickly became a bit of a star (self proclaimed). Not being cocky but I could now show my talents off on a larger scale and for many peers who actually understand what is coded. My first assignment in Sencha was working at a certain client (cannot be named) working with Doug Hendricks and Jack Ratcliff who also work at Sencha on the Professional Services team. Doug was traveling a lot but Jack worked locally with me so I became close to working with him... enjoyed bouncing ideas off him and just talking with him on a daily basis. Jack moved on to another project so it was just Doug and I so I was by myself onsite. As of October 21st, I moved on to be the Senior Forum Manager (I got to pick my own title :) ).

That brings us up to today! You probably have started seeing me spam the forums! My mission is to help people learn, not just give answers. I want to guide people to the answer so I'm sorry if you expect example code but that's not really going to help you grow as a Sencha developer.

Sorry if it was a long post but I appreciate you reading it and getting to know me. I hope to talk to you via Twitter or on the Forums but my true wish is to be able to attend meetups and conferences to meet you in person.


About me


We are only in the developer preview stages of **Sencha Touch 2** but we are already seeing so many great things. Performance in Android is superb. Scrolling is so native feeling that users won't really be able to tell it's really just a web page. Orientation changing is faster than the actual browser. The list goes on and on but I just stumbled on something that will help you clean up after your defined components.

Lots of times, we as developers set references onto components to keep track of things. We now can use the config Object with the getters and setters which is very useful I have to admit. But sometimes that's just a bit much for what we need. We just want to set a reference and refer to it whenever we want but the problem with this is it can leak memory. So what we would do is either listen for the destroy event or use one of the destroy methods and call the superclass. But what if **Sencha Touch** as a framework can take care of it? Enter the referenceList.

Every subclass of `Ext.AbstractComponent` gets an Array placed as `referenceList`. All this is is an Array of Strings which are references on the component. You will see that the referenceList Array will have 'element' and sometimes 'innerElement' (depending on if it is an `Ext.Container` or subclass). When the component is destroyed, the destroy method will iterate over the referenceList Array, execute the destroy method on that reference and then delete it:

```js
// Destroy all element references
for (i = 0,ln = referenceList.length; i &amp;lt; ln; i++) {
    reference = referenceList[i];
    this[reference].destroy();
    delete this[reference];
}
```

Now you can see the comment says that it will destroy all element references but technically you can put anything in there that has a destroy method. Very simple to clean up your references. Let's look at an example...

Say you want a fullscreened `Ext.Container` but you need to detect when that `Ext.Container`'s size changes. By default, `Ext.Container` doesn't monitor it's own size so you have to initialize your own `Ext.util.SizeMonitor` in order to do this. I will caution you, `Ext.util.SizeMonitor` adds in overhead so don't go crazy adding it to everything. This is an example of a subclass that does just this:

```js
Ext.define('MyContainer', {
    extend : 'Ext.Container',

    config : {
        fullscreen : true
    },

    initialize: function() {
        var me      = this,
            refList = me.referenceList;

        me.sizeMonitor = Ext.create('Ext.util.SizeMonitor', {
            element  : me.element,
            callback : me.onSizeChange,
            scope    : me
        });

        me.on('painted', 'onPainted', me, { single : true });

        me.callParent();
    },

    onPainted: function(cmp) {
        cmp.sizeMonitor.refresh();
    },

    onSizeChange: function() {
        this.fireEvent('sizechanged', this);
    }
});
```

Couple things I want to point out here. First, you can see we are placing a reference to the `Ext.util.SizeMonitor` instance to `this.sizeMonitor`. Second, you have to execute the refresh method on the `Ext.util.SizeMonitor` instance when the component has been painted, this is what will make the size change be picked up. This may be better suited for the config Object to get the getter and setter but it's just an example for this blog post. So right now we have a fully working example with a reference that could be a memory leak, we could listen for the 'destroy' event and clean it up ourselves but there is a built in way to do it as mentioned before, the referenceList Array. So after you set the reference, we just need to push a String to the referenceList Array and it will automatically be cleaned up for us:

```js
Ext.define('MyContainer', {
    //..

    initialize: function() {
        var me      = this,
            refList = me.referenceList;

        me.sizeMonitor = Ext.create('Ext.util.SizeMonitor', {
            element  : me.element,
            callback : me.onSizeChange,
            scope    : me
        });
        refList.push('sizeMonitor');

        me.on('painted', 'onPainted', me, { single : true });

        me.callParent();
    },

    //...
});
```

That simple! But remember, it must have that destroy method or else you will get a JavaScript error as there is no check if a destroy method is present. Kind of wish there was for other references but it's not really what this was meant for.

Enjoy all the **Sencha Touch 2** goodness!


Lists: