While the test should work without this assertion, the intention of the
test is to check what happens if a user selects and investment and, once
it's selected, clicks the "next" link.
When we were inserting a row or replacing an existing one (just like we
do when we click the link to select an investment), we were entering a
row containing all columns, and all of them were displayed even if they
had been excluded using the column selector.
This caused the table to move in a strange way, which sometimes made the
investment selection tests fail.
This way we can reduce the number of locales used in the test
environment as well, while still testing every possible scenario for
remote translations.
Using `Array(0, 1, 2)` will *not* create an Array with the elements
[0, 1, 2]. This is a mistake I've seen in the past, and the JavaScript
community recommends adding this rule.
It's very easy for Ruby developers to omit the `return` statement in an
array callback, such as the ones in `map` or `filter`. Doing so will
make those funcions have the same effect as `forEach`, which is usually
not the intended behaviour.
Using the same variable name makes the code more difficult to read.
We're also enabling the `no-param-reassing` rule since we accidentally
reassigned params in commit 824dd26d, and this rule will prevent us from
doing so in the future.
While I personally prefer the "never" option for this rule, we haven't
discussed which guideline to follow, so for now I'm applying the rule
CoffeeScript used when generating these files.
We originally wrote `undefined` in CoffeeScript.
CoffeeScript compiled it to `void 0` when generating the JavaScript
files. However, the reason to do so was the `undefined` variable was
mutable before ECMAScript 5. Using `undefined` is more intuitive, and
nowadays there's no reason to use `void 0`.
For now we're only adding rules related to spacing and double quotes,
following the same rules we use in Ruby, which are the same rules
CoffeeScript followed when compiling these files.
We're also using the recommended ESLint rules, which will warn us about
many JavaScript common pitfalls, the `strict` rule which enforces using
strict mode, and the `no-console` rule, which will prevent us from
shipping code meant for debugging.
Although it's arguably more common to use the JSON format to define
these rules, I've chosen YAML because it's the format we use in all our
linters.
These statements were automatically added by CoffeeScript.
I'm only removing the obvious cases; there might be more cases where the
`return` statement isn't necessary.
We accidentally removed the `count` option in commit 55fb14ac, which
made the translation return a hash.
The test is a bit hacky, which makes me think changing the user
interface would probably be a better solution.
Local variables are one of the things CoffeeScript doesn't compile to
modern JavaScript automatically: it uses `var` instead of `const` or
`let`.
Besides, using `$this = $(this)` is usually done to reference the
current object in another function where the current object is a
different one. Here we were using it with no clear purpose.
In JavaScript we cannot easily repeat something N times, and
CoffeeScript's range loop compiles into complex JavaScript.
We could also use `Array.from({ length: N })`, but that's not supported
by old browsers like Internet Explorer 11.
Iterating through the jQuery elements with `each` is more similar to
other iterators we use. Furthermore, we avoid declaring the `index`
variable we don't use.
The `append` method can handle arrays, so there's no need to loop
through each element.
There's more to improve on this method, like the `asc` variable being
global to a table instead of depending on the current column, but for
now I'm only refactoring and maintaining the current behaviour.
These methods were added in 2009 and are supported by 98.5% of the
browsers, including Internet Explorer 9, 10 and 11. We were already
using them in some places.
Calling it directly might make it difficult to detect bugs, particularly
when we don't trust the data we receive:
https://eslint.org/docs/rules/no-prototype-builtins
If we trust the data we receive, then IMHO we shouldn't even check for
`hasOwnProperty`, since we know what we're going to receive.
In JavaScript, when there isn't a `break` or `return` statement inside a
`switch` case, the next case will be executed as well.
That wasn't a problem here because CoffeeScript automatically inserts a
`return` statement in this specific situation. However, since we don't
want to return the result of the `hide()` operation, it might be easy to
accidentally remove the `return` statement, causing the code to break.
I've added a test for the scenario where neither `break` nor `return`
statements are present, so we don't run into this error.
This code requires the variable `_paq` to be set somewhere, but we never
set it.
In the past Decide Madrid added some custom JavaScript using this code.
However, in CONSUL we're using Ahoy to track events, and we don't have
any documentation about adding custom JavaScript to use piwik nor we've
got any other piwik integration.
The `removeCookie` function is never called, and the `initialize`
function doesn't do anything. The only functions we use here are
`getCookie` and `saveCookie`.
