Prefer const wherever possible

Summary:
Non-final identifiers make code harder to understand.
This is particularly true for JavaScript where even the *type*
can change as a value gets reassigned later.

This enforces to use `const` whereever possible, but doesn't
"outlaw" `let`. Mixed destructuring is also still allowed.

Used `eslint --fix` to change all existing cases.

Reviewed By: jknoxville

Differential Revision: D16131329

fbshipit-source-id: 2eceaca7c603b71b36e005be5d135e1849f2518d
This commit is contained in:
Pascal Hartig
2019-07-09 04:15:32 -07:00
committed by Facebook Github Bot
parent 662db20948
commit c588b650ae
34 changed files with 141 additions and 140 deletions

View File

@@ -9,24 +9,24 @@ import {uriComponents} from '../application.js';
test('test parsing of deeplink URL', () => {
const url = 'flipper://app/plugin/meta/data';
let components = uriComponents(url);
const components = uriComponents(url);
expect(components).toEqual(['app', 'plugin', 'meta/data']);
});
test('test parsing of deeplink URL when arguments are less', () => {
const url = 'flipper://app/';
let components = uriComponents(url);
const components = uriComponents(url);
expect(components).toEqual(['app']);
});
test('test parsing of deeplink URL when url is null', () => {
// $FlowFixMe
let components = uriComponents(null);
const components = uriComponents(null);
expect(components).toEqual([]);
});
test('test parsing of deeplink URL when pattern does not match', () => {
const url = 'Some random string';
let components = uriComponents(url);
const components = uriComponents(url);
expect(components).toEqual([]);
});