Recursion

I’ve been trying to get to grips with recursion lately and I think I might be on the verge of a mini breakthrough.

A recursive function must have two things:

• A ‘base case’ from which it finally returns.
• A statement in which it calls itself if the base case condition isn’t met.

The function below takes `n` arguments and adds them using recursion.

If there are only two arguments – the base case – the function returns the sum of those two arguments and does nothing else.

When there are three arguments, initially the function skips the base case. It takes the first of the three arguments and adds it to the result of running itself with the remaining two arguments (which, as we’ve seen, will satisfy the base case and just return a number).

For example, with two arguments the base case is met here:

`addRecursive(1, 1) // 2`

Adding a third argument – `addRecursive(1, 1, 1)` – we miss the base case on the first time round, effectively getting to

`return 1 + addRecursive(1, 1)`

As we saw above, the right side of that statement equates to 2, so it is equivalent to

`return 1 + 2 // 3`

At this point I can wrap my head around this single recursive call, because I can keep all the necessary logic in my brain at once – ultimately I can see that two numbers are going to be added together. Adding more recursive calls, I can just about figure out what’s going on conceptually, but it’s tricky. It’s the recognition that each of the recursive functions will finally return a value out to the point from where they were called that is most brain-melting for me. A bit like Inception.

For now I’m satisfied that I can convince myself logically of how recursion works. I think I’m a way off knowing when to use it in anger.

Stylelint hyphenated BEM config

Stylelint.io is flavour of the Sass-linting month (replacing scss-lint as the discerning bandwagon chaser's Sass linter of choice). Scss-lint caters to the Harry Roberts approved variant, calling it 'hyphenated BEM'. There is a BEM pattern plugin for Stylelint, but out of the box, it doesn't support this flavour.

In order to validate your hyphenated BEM selectors with Stylelint, add the BEM plugin – `npm install stylelint-selector-bem-pattern` – and add these regexes to the Stylelint plugin `.stylelintrc` config:

Then add `//* @define component-name-here; weak` to the top of each Sass partial and liberally pepper the file with `// stylelint-disable plugin/selector-bem-pattern` before any lines on which you don’t care that you’re not being BEMmy enough (you can start caring again with `// stylelint-enable plugin/selector-bem-pattern` below). The `weak` flag ensures that while initial selector sequences (before combinators) must match the defined convention, sequences after combinators don’t. This helps to keep things relatively sane, so you don’t have to reach for `stylelint-disable` too often.

The `ignoreSelectors` array included above is just what seemed to work well for me on one project – your mileage may vary, depending on what kind of utility classes make their way into your components.

Conway’s Game of Life in JavaScript

Generation:

Rules (from Wikipedia)

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
2. Any live cell with two or three live neighbours lives on to the next generation.
3. Any live cell with more than three live neighbours dies, as if by over-population.
4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

A classical JavaScript inheritance helper

Setting up inheritance in JavaScript, you have to do a couple of not-particularly-intuitive steps with the prototype.

I’ma add this guy to my TextExpander snippets:

You have to remember to call this method directly after the constructor, before you do anything else with the extending object’s prototype.

Custom select boxes

I've often heard that it's a Very Bad Idea to try and emulate a browser's native select box using JavaScipt, so I thought I'd give it a go to see what the fuss is all about.

Here’s a far from exhaustive list of things I found to describe how browsers seem to handle their native select boxes:

• Trigger open/close by pressing space on header
• Trigger open by pressing cursor keys on header
• Trigger open/close by clicking on header
• Focus currently selected item on open
• No dropdown focus if currently selected item is disabled
• Navigate from top/bottom if currently selected item is disabled
• Navigate from currently selected item using cursor keys
• Select focused item on pressing return/space
• Close (without updating) on pressing escape
• Select hovered option (unless cursor key pressed since initial hover) on pressing return/space
• Close (without updating) on pressing return/space when hovered over disabled option
• Navigate using cursor keys from most recently hovered option
• Skip over disabled options when navigating with cursor keys
• A disabled select doesn’t respond to events
• A disabled optgroup has all of its child options disabled

And here’s a JS Bin with my best shot. The styles are just for fun (i.e. don’t judge me) – it’s the functionality that I was interested in.

I feel like I’ve had a fairly good run at it – I think I’m relatively close to having implemented the keyboard and mouse driven idiosyncrasies.

It’s not even close to being acceptable for screenreader use, though. And I couldn’t even face attempting to handle the `multiple` attribute.

In any event, it’s been an interesting exercise – I’ll feel better able to defend against a custom select requirement in future.