ES6 highlighting and lint checking in vim

I am a long-time "vimmie" (that is, I use vim for my IDE) and I love the plugin ecosystem which lets me do just about anything I want.

For example, I recently started using ReactJS (wish I hadn't wasted to so much time trying to get Angular to work) and one thing I love about it is how straight-forward it is to setup and start writing TDD/BDD for development (but that's another story).  My configuration uses Babel and es6, so I wanted to get syntax checking and indentation/highlighting working right off the bat.

Here's how -- it's pretty easy. I'm using Vundle as my plugin manager so that's the examples given. If you're using pathogen or vim-plug as your plugin manager, it should be pretty easy to modify and get it running. I've used pathogen and it's excellent, but have no experience with vim-plug.

1. If this is the first time you've used a plugin, go to the Vundle website and follow the instructions there.
2. Install the vim-javascript plugin by pangloss: vim-pangloss. This will give you basic syntax-highlighting / indentation using vim's built-in syntax support.
3. Install the syntastic plugin by scrooloose: syntastic (he's the author of the excellent NERDTree plugin which gives you a hierarchical tree menu for system files). This will allow you to use external syntax checkers with vim, in addition to the built-in syntax checking already available. I use the eslint program for this. The options I use in vim for syntastic are:
   

   """"""""""""""""""""" Syntastic """"""""""""""""""""""""
   " From: http://usevim.com/2016/03/07/linting/
   set statusline+=%#warningmsg#
   set statusline+=%{SyntasticStatuslineFlag()}
   set statusline+=%*
   let g:syntastic_always_populate_loc_list = 1
   let g:syntastic_loc_list_height = 5
   let g:syntastic_auto_loc_list = 0
   let g:syntastic_check_on_open = 1
   let g:syntastic_check_on_wq = 1
   let g:syntastic_javascript_checkers = ['eslint']
   let g:syntastic_error_symbol = '❌'
   let g:syntastic_style_error_symbol = '⁉️'
   let g:syntastic_warning_symbol = '⚠️'
   let g:syntastic_style_warning_symbol = '💩'
   highlight link SyntasticErrorSign SignColumn
   highlight link SyntasticWarningSign SignColumn
   highlight link SyntasticStyleErrorSign SignColumn
   highlight link SyntasticStyleWarningSign SignColumn
   """""""""""""""""""""""""""""""""""""""""""""""""""""""
   

4. Install the eslint program. This is a node module installed with the 'global' option so that it's available everywhere as an executable. This is just
   

   npm install -g eslint
   

5. You would think this would work (I sure did) but it's not yet fully baked. With this setup, the first import statement in some of your .js files will be flagged as an error. To solve this issue, you have to give eslint a few parameters, in the file ~/.eslintrc.json
   

   // From: http://eslint.org/docs/user-guide/configuring
   {
       "parserOptions": {
           "ecmaVersion": 6,
           "sourceType": "module",
           "ecmaFeatures": {
               "jsx": true
           }
       },
       "rules": {
           "semi": 2
       }
   }
   

Now you've got full es6 syntax checking and error notifications.

No, it wasn't the "world's least helpful error message"

Last wee, I commented about a problem with AngularJS and an error message that I found incredibly unhelpful.  Turns out it was more helpful than I knew although there are still problems.

Here's what it looked like in Chrome DevTools:

But that's a live link, so all you have to do is click on it and you're redirected to an AngularJS page that (hopefully) provides more information. Here's the link, and here's the link text iteself: quite a mouth/link full:

What you get when you click on this link is a customized error page -- pretty neat way to handle things and sometimes it works very well -- this example was spot on:

But here's one that wasn't nearly so helpful:

So...much better than I thought, although there are still some head-scratchers.

Cucumber, Capybara, and Webkit testing for Ajaxified actions

I recently upgraded my testing stack and now use Capybara and Webkit with Cucumber (and RSpec, too). I ran into a number of problems and found this post by Mathew O'Riordan incredibly helpful. He tracks the history of his research and testing through a github project and at various points on the blog entry shows the commit for the changes he just discussed: kudos on that approach!

A couple of gotchas that I ran into along the way:

First, you may need to add the following line to your features/support/env.rb file:

require 'capybara-webkit'

O'Riordan doesn't do this in his project, but I got an error:

"no driver called :webkit was found, available drivers: :rack_test, :selenium (Capybara::DriverNotFoundError)"

and found this discussion which gave me the solution.

Second, although it may be obvious, I missed the fact that you MUST put

@javascript

before each scenario that requires in-browser javascript. I had thought this was just a way of grouping scenarios together, but it actually triggers the use of the webkit driver to run the step.

Solving one IE rendering problem...

I know this has been posted elsewhere, but since I recently ran into the issue and had to do some digging and coding to work around it, I thought I'd post it for others to find.

While working with a drop-down select box in a form, I wanted to be able to show/hide different sections of the form depending on the value of the selection (I'm currently using the Prototype javascript library for this project). It all worked fine in every browser except IE (surprise... NOT!). IE was not setting the "value" property of the select box.

After some testing, I found that IE DID properly set the selectedIndex attribute, so I could use that to get IE to work like I wanted it to; here's the code:

MHC.select_display = function(select_id, select_value, select_number, toggle_id) {
/***
* NOTICE IE6 properly sets the selectedIndex value but does NOT set the value property; therefore, we have to give both values to this routine
* to handle both browsers.
* alert("Hi - I've been changed! / " + select_id + " / " + select_value + " / " + toggle_id + " / " + $(select_id).selectedIndex + " / " +  $(select_id).options[$(select_id).selectedIndex].value + " / " + $(select_id).value) + " / " + $(select_id).options.value;
**/     
if(Prototype.Browser.IE) {
  if($(select_id).selectedIndex == select_number) {
    $(toggle_id).appear();
    }
  else {
    $(toggle_id).hide();
    }
  }
else {
  if($(select_id).options[$(select_id).selectedIndex].value == select_value) {
    $(toggle_id).appear();
    }
  else {
    $(toggle_id).hide();
    }
  }
};

While I don't know this for a fact, I'm guessing that other problems with IE form fields (such as checkboxes and the "checked" attribute) may be due to the timing of updates to the attributes; you may be able to find alternative attributes that you can interrogate to get things done.