React-ing to the need for a modern MapGuide viewer (Part 13): My first* pull request

Previously, I switched our testing stack for mapguide-react-layout over to Jest, which had some positive flow-on effects, like being able to finally upgrade to Webpack 2 and being able to try out the new OpenLayers npm package, resulting in a nice reduction in production bundle size due to only pulling the bits of OpenLayers that we are actually using. Jest also has code coverage built in, and by piping its coverage output to node-coveralls, TravisCI will automatically upload said coverage reports to coveralls.io resulting in yet another shiny badge to show on our project page.

These badges are becoming like Pokemon: I just want to catch 'em all.

So the next badge for me to collect was greenkeeper. Greenkeeper is a free service that monitors your GitHub repository and keeps your node package dependencies up to date. So last night I enabled greenkeeper integration for mapguide-react-layout.

Today I got a GitHub notification for a new pull request on mapguide-react-layout. Great! I love pull requests. Except, this pull request is not from a human, it's from the greenkeeper bot (*my first non-human pull request). Looking at the pull request in detail was most amusing.

A bot (coveralls) commenting on a pull request opened by another bot (greenkeeper)!

I wonder how many pull requests out there are nothing but full of bot-on-bot comments? How deep does this bot rabbit hole go?

When bots can start writing their own code, I think that's when we can pack it in as the human race and submit to our bot overlords.

React-ing to the need for a modern MapGuide viewer (Part 12): A positive cascading effect

The move to Jest for our testing/coverage needs has opened up some opportunities that were previously roadblocks.

Mainly, we can finally upgrade to Webpack 2. Previously, we were roadblocked because the karma runner just wouldn't work with webpack 2 configurations. Also unlike earlier attempts with Webpack 2 beta releases, this upgrade to Webpack 2 was less painful and more importantly, the bundle size remained the same.

Also OpenLayers recently released 4.0.0, which also includes experimental ES2015 modules, the ES2015 module facilitates a "pay for only what you use" model which is great for us as we don't necessarily want to use the kitchen sink, only the parts of the library we actually use. It turns out based on their webpack example that it requires Webpack 2 to work as Webpack 1 will include said modules verbatim causing most browsers to blow up on the various ES2015 language constructs (like imports).

Well, how convenient that we just upgraded to Webpack 2! Switching over to the new ol package and its ES2015 modules, and making the required fixes in our codebase to use this new package, and checking the final production bundle size shows promise.

That is 150kb smaller than our current production bundle! Once other libraries we're using adopt ES2015 modules, we can expect even more weight loss.

React-ing to the need for a modern MapGuide viewer (Part 11): I don't say this in jest

... but seriously, Jest completes my holy trinity of web front-end development nirvana.

• React, because of its high performance and revolutionary component-based way of building frontend UIs. I could never go back to jQuery, data-binding, string templating and those other primitive ways of building frontends.
• TypeScript, because it is in my opinion, the only sane programming language for frontend development. Just like jQuery was the glue that held together inconsistent browser APIs for many years, TypeScript the the glue that lets us play with future JS technologies in the present. TypeScript is JavaScript with C#-quality static typing. I love that a whole class of errors are eliminated through a simple compile step. I can't fathom having to maintain large code bases in a dynamically-typed language. TypeScript brings order and sanity in that regard. And with TypeScript 2.0, I don't have to deal with billion dollar mistakes.
• And finally, Jest which I believe to be the total package for JavaScript unit testing that is sooooooo easy to set up! Code coverage is also included.

Before I tried Jest, the current unit test suite for mapguide-react-layout was a convoluted stack of:

• karma
• mocha
• chai for assertions
• PhantomJS to drive the karma runner

I also tried to get code coverage working. But this required a tool called istanbul and because my code was TypeScript, it needed some TypeScript source map plugin for istanbul to recognise it, which resulted in some rube-goldberg-esque contraption that formed the foundation of my unit test suite, that didn't even get the coverage right! So I scrapped the code coverage part and just coasted along with karma/mocha/chai combo until now.

With the introduction of Jest, it does the job of karma/mocha/chai/istanbul in a single, easy to install package. Only some small changes to my unit test suite was required (porting chai assertions to their jest equivalents) and the whole test suite was passing. With a simple addition of a --coverage flag to jest, it then automagically generates code coverage results and reports.

Since I am now getting code coverage reports, the obvious next step was to upload this to the coveralls.io service. It turns out TravisCI already supports automatic upload of code coverage reports to coveralls. It just needed installing node-coveralls and piping the jest coverage output to it.

And with that, I get another shiny badge to brandish on the project home page

This is almost too easy. Results like this easily incentivize you to write good quality code.

One last thing before I close out this post. The 63% coverage is a bit of a misnomer. It turns out that it is actually the percentage of code in modules that your unit tests are currently testing, which makes sense. The moment I start bringing in other components and classes under test, I expect this percentage to plummet, which is merely incentive to write more tests to bump it back up.

Announcing: mapguide-react-layout 0.8

Here's a new release of mapguide-react-layout

Here's what's new in this release

Multiple Map Support

If you load an Application Definition with multiple map groups, the viewer now properly supports them.

Thanks to the use of redux (as my previous blog adventure post explained), map state is all nicely isolated from each other and makes it easy for components and commands to easily be aware of multiple maps, such is the case of the measure component (notice how recorded measurements switch along with the active map)

Also for Task Pane content, we added some smarts so that you know whether current task pane content is applicable or not to the current active map.

Other Changes

• Update Blueprint to 1.9.0
• Update React to 15.4.2
• Improved performance of redux aware components to avoid unnecessary re-rendering
• Sidebar Template: Fix a small sliver of the Task Pane content visible when collapsed
• Legend: Fix infinite loop on maps with multiple (>2) levels of group nesting
• Hover styles no longer render for disabled toolbar items
• Clicking an expanded panel in an accordion no longer collapses it (an expanded panel should be collapsed by clicking another collapsed panel). This affects viewer templates that use accordions (eg. Slate)
• Added support for InvokeURL command parameters
• Fix default positioning of modal dialogs

Download

Announcing: MapGuide Maestro 6.0m6

Here's another long overdue new milestone release for MapGuide Maestro 6.0.

Here's a summary of what's new.

Friendlier connection error dialog

Rather than say MgConnectionFailedException, perhaps this dialog can explain things better?

Theme support

The latest version of DockPanelSuite supports theming. Maestro now includes a bunch of VisualStudio-style skins that you can choose from the options UI. For example, here's Maestro with the Visual Studio "blue" theme.

Non-modal map previews

Resource previews that use the local map viewer (ie. It doesn't launch an external web browser), now display as additional document-resident view content instead of a modal dialog.

MgCooker

Rather than punching in coordinates for override extents manually, you can now set the extents interactively with Maestro's map viewer component.

Also on that subject, when generating tiles with overridden extents, the total tiles calculation should be more accurate now, having verified the overridden extents against the contents of the physical tile cache, the visual verification made much easier with this new feature.

Other Changes

• Maestro now has new validation rules for ODBC configuration documents
• You can now enter a Google Maps API key in the Flexible Layout editor (if you require it)
• The mapguide-rest addin now generates configuration documents with valid representation nodes
• Fix NullReferenceExceptions when editing Fusion Flexible Layouts with multiple map groups. A nice timely fix to have to make way in preparation for when this is ready.
• Upgrading a WebLayout to a 2.4 or newer schema version will now include the MapTip command if it doesn't exist
• Upgrading a Layer Definition to a 2.4 or newer schema version no longer discards any URL settings.
• XML editor now automatically trims off null '\0' characters (the source of many bogus content validation errors)
• FDO stylization functions are no longer falsely reported as unsupported functions by the FDO expression validator.
• Fusion and Symbol Definition editors should now trigger dirty state more often.
• IronPython updated to 2.7.7

Download