Андрей

Потому что здесь возникает коллизия.

Когда вы пишите 1.bla - интерпретатор думает что это что-то вроде 1.234 т.е. число с десятичной дробью. А там внезапно не число.

По этому взятие числа в скобки - работающее решение.

Вам будет гораздо легче решать большую часть стоящих перед вами задач (а другим гораздо легче вам в этом помогать), как только вы перестанете описывать их общими фразами (типа "максимально эффективно", "полноценный дев", "хорошим специалистом" и т.п.).

Будьте конкретны:
- "Моя цель на ближайшие 6 месяцев - вырасти до позиции XXX в текущей компании". И далее:
- "Что мне нужно сделать для того, чтобы в течение 6 месяцев в моей компании вырасти до XXX ?"

С этим уже можно обратиться к людям, обладающим достаточной компетенцией в помощи вам с ответом на этот вопрос: "Для того, чтобы в нашей компании стать XXX, нужно знать ЭТО и уметь ТО".

- "Что мне нужно для того, чтобы узнать ЭТО и научиться делать ТО ?". Cоставляете план действий (разбиваете необходимые шаги на месяцы, недели, дни) с дежурными сроками (для проверки запланированного и достигнутого, внесения в связи с этим необходимых корректировок и т.п.) - и вперед.

Но все начинается с конкретики:
- "...хочется максимально эффективно развивать себя...". Что конкретно значит (для вас) "максимально эффективно"? По каким критериям вы будете определять, эффективно вы развиваетесь или нет? Количество прочитанных книг? Сложность решаемых задач? Что конкретно?
- "...чтобы стать не только полноценным девом...". Что конкретно значит (для вас) "полноценный дев"? Как вы поймете, что стали "полноценным девом"? Вы добьетесь определенной должности? Будете зарабатывать определенную сумму денег? Что конкретно?

Успехов.

Всё это очень абстрактно. У нас Java-разработчики с 8-летним опытом знали меньше матёрых мидлов с 2-3 годами разработки. Собеседование - это лотерея. Где-то 80%-90% на learnjs и на Senior'a прокатят))
Тут уж лучше профиль на github, это как-то надёжнее. Зашёл, посмотрел, какая проблема была, с помощью каких технологий решал и тд.
PS: Кстати "прототипы, call, apply, bind, каррирование" не так часто и применяются. А под "глубоким пониманием js" подразумевается, что вы понимаете, как это реализовано под капотом очередного js-фреймворка.

вы все знаете — Junior
вы поняли что ничего не знаете — Mid
вам все равно — Senior

habrahabr.ru/post/231649/#comment_7826819

Они экспортируются в нативном коде, к примеру в java есть такой декоратор, который позволяет вызвать эту нативную функцию из JS потока:

// my method class
 @ReactMethod
    public void setCurrentTime(final Integer key, final Float sec) {
        MediaPlayer player = this.playerPool.get(key);
        if (player != null) {
            player.seekTo((int) Math.round(sec * 1000));
        }
    }

В Obj-C есть свое:

// создается нативный модуль OutputVolume
@implementation OutputVolume

RCT_EXPORT_MODULE();

// Отдает метод get
RCT_REMAP_METHOD(get,  
                 resolver:(RCTPromiseResolveBlock)resolve
                 rejecter:(RCTPromiseRejectBlock)reject)
{
  float volume = [AVAudioSession sharedInstance].outputVolume;
  NSString* volumeString = [NSString stringWithFormat:@"%f", volume];

  if (volumeString) {
    resolve(volumeString);
  } else {
    reject(@"get_error", @"Error getting system volume", nil);
  }

}

А вот как принимать это в JS коде:

import { NativeModules } from 'react-native';

const MyNativeModule = NativeModules.MyNativeModule;

Почитать:
- https://www.promptworks.com/blog/writing-native-mo...
- https://clever.ly/blog/2017/05/09/going-native-cre...
- https://shift.infinite.red/native-modules-for-reac...

/^\d{6}-([A-Z]|\d){4}$/

Нет, не правильно.
Для вашего примера правильно будет:

a = new ExampleObjeact();
a.makeSomething = function(action) {
    return a[action]();
});
a.makeSomething('makeSome1');
a.makeSomething('makeSome2');
a.makeSomething('makeSome3');

Идея в том, что вы делаете один публичный метод, который принимает грубо говоря action-type. В зависимости от action вы уже делаете требуемое(возможно преобразуете аргументы и вызываете конкретную приватную функцию). Скрыает внутренний API вашего модуля за "Фасадом".

Поделюсь своим решением. Хотя у меня на сервере стоят рельсы, а реакт только на морде. Но тем не менее, вдруг будет полезно.

При авторизации сервер генерит:
- access token
- cookie
- refresh token
которые затем гоняются между клиентом и сервером.

Refresh token может отсутствовать. Вообще говоря он нужен только для обновления access token, и клиент добавляет его в запрос только когда истекает срок действия access token. В этом случае сервер генерит новый access и refresh token.

Cookie отдается с пометкой HTTP only, то есть клиент их прочитать никак не может. Cookie нужны только для проверки валидности access token, то есть никаких сессий по ним нет (вообще приложение полностью stateless).

Оба токена (access и refresh) клиент хранит в local storage, откуда извлекает их для каждого запроса на сервер.

Любой запрос от клиента, содержащий валидный access token, считается авторизованным, только если в нем есть соответствующие токену куки (не совпадающие, а соответствующие, то есть закодированные по какому-то алгоритму с access token в качестве базы). Ну и если есть refresh token, то также смотрим, подходит ли он к нашему access token.

Такая схема, в совокупности с HTTPS, неплохо защищает от XSS или от CSRF уязвимостей (оговорка: но не от обеих сразу).

Немного теории, почему это работает, можно прочитать здесь: www.redotheweb.com/2015/11/09/api-security.html

Обычно под native подразумевается, что программа выполняется в родной среде устройства, использует родные UI-виджеты и т.п. Например приложение выполняющееся в браузере и рендерящее себя внутри браузера будет "неродным" для мобильной платформы и "родным" для браузера. Сам же браузер будет "родным" для мобильной платформы. Язык на котором вы написали приложение роли не играет, можно и на java писать "неродные" приложения под андроид.