Landings
One more video (with my launches) is after the break
One more video (with my launches) is after the break
Imagine that you want to add support of some keybinds in your web application. Let it be Ctrl+L for liking\unliking something. What kind of issues can you face in such a scenario?
At first look at Ctrl. Probably on MacOS you’d like to replace it with CMD. You can check it by event.metaKey.
Probably you wouldn’t like to consider Ctrl+Alt+S as Ctrl+S. So don’t forget to handle this case.
Not every language that uses the Latin alphabet has the L button at the same position as in a typical English keyboard layout. You need to decide what is more important to you ― a real key position on a keyboard or a letter upon of it. I’d guess that the 2nd case is preferable for most applications.
To get a real key position you can use which, code, codeKey properties. To get a letter on the key use key property.
What’s about Greek or Russian alphabets? Or any other possible alphabets? Or not even alphabets? There’re different strategies. And one of them is to use a key from a typical English keyboard layout. So it leads us again to code and codeKey properties.
const getEventKeyBind = event => { const keybind = []; if (event.metaKey) keybind.push('cmd'); if (event.ctrlKey) keybind.push('ctrl'); if (event.shiftKey) keybind.push('shift'); if (event.altKey) keybind.push('alt'); if (event.key === ' ') keybind.push('space'); else { const key = event.key.toLowerCase(); if (key.length !== 1 || key.match(/^[a-z]$/)) { // latin key or a special key keybind.push(key); } else { // extra-latin or non-latin key const [, enSymbol] = event.code.match(/^Key(\w)$/) || []; keybind.push(enSymbol ? enSymbol.toLowerCase() : key); } } return keybind.join('+'); };
Two more videos are after the break:
German language contains some extra latin symbols that English language doesn’t: ä, ö, ü, ß. But if you choose German keyboard layout instead of English you get some keyboard keys moved to unusual positions. If it’s okay for you then you don’t need to do anything with it. Just get used to the new layout! But if you wanna stay with the English version of latin keys positions you need to find some convenient way to type German specific letters.
Under the cut 3 ways to handle it:
This article is a small guide about how to configure an enviroment for babel-plugin-module-resolver. This plugin allows you use custom prefixes for import/export declarations in JS files. E.g. import A from ‘com/A’ can be treated as import A from …/…/components/A.
npm i -D babel-plugin-module-resolver. map-config to your .babelrc file into the plugins section. E.g.:plugins: [ // ... [ "babel-plugin-module-resolver", { "alias": { "^com(.+)": "./src/com/\\1" } } ], // ... ]
npm i -D eslint-import-resolver-babel-module package for ESLint. It allows ESLint to check your rewrited imports, It assumes that you already use eslint-plugin-import package. If you don’t I recommend you to start using it. This package checks your import/export declarations, it’s very convinient..eslint file:{ "parser": "babel-eslint", "parserOptions": { "ecmaVersion": 6, "sourceType": "module", "ecmaFeatures": { "jsx": true } }, "settings": { "import/resolver": { "babel-module": {} } }, "plugins": [ // ... "import" ], // ... }
babel-eslint if you didn’t do it yet. And move its declaration from parseOptions to the root of the .eslintrc.babel-module part in .babelrc section is just {}, it’s okay.ESLint plugin in vsCode.vcode/settings.json something like next lines. They force vscode to change CWD (current directory) in the deamon of eslint plugin:"eslint.workingDirectories": [ { "directory": "./client", "changeProcessCWD": true } ],
path-intellisense plugin, you should consider configurate your mapping in .vscode/settings.json too. Use force, Luke. Set vscode setting “eslint.trace.server”: “verbose” and debug, debug, debug. I’ve spent on it several hours :(