Languages API

[dhilt]

Нужно добавить в API выдачу массива зыков. Для этого

1) добавь в helper.js

const languages = {
  data: [
    {
      id: 'rus',
      name: 'русский',
      name_rus: 'русский',
      name_eng: 'russian',
      default: true
    },
    {
      id: 'eng',
      name: 'english',
      name_rus: 'английский',
      name_eng: 'english'
    }
  ],
  getLang: function (id) {
    const lang = this.data.find(lang => lang.id === id);
    return lang ? lang.id : this.data.find(lang => lang.default).id
  }
}

2) замени все вхождения строк 'rus' и 'eng' на вызов

languages.getLang('rus'/'eng')

3) добавь в app.get('/api/common', ... массив зыков

{success: true, translators: ..., languages: languages.data }

После этого на клиенте положи этот массив в state common.languages. И замени все вхождения 'rus'/'eng' на languages[].id, а также строки "русский"/"английский" на languages[].name_rus

[dyuvzhenko]

@dhilt Вроде готово: https://github.com/dhilt/dharmadict/commit/23f01492d8546922adb6ed33ea4ff3620101bb15 Заметил еще что Edit.js некорректно работает. Если перейти со страницы поиска на страницу исправления/добавления переводов, все будет отлично. Но если загрузиться изначально на роуте вида http://localhost:5000/edit?termId=chos&translatorId=MK, то никаких переводов видно не будет. И да, я там немного внес свою лепту https://github.com/dhilt/dharmadict/commit/23f01492d8546922adb6ed33ea4ff3620101bb15#diff-edfed8a5708b2459c6d8853a83a01d0eR17, но и до этого были проблемы.

[dyuvzhenko]

@dhilt Проблему с Edit.js пофиксил - https://github.com/dhilt/dharmadict/commit/00070be7d98d75e64c327c93239b78c37fcbbb57. Просто на одном action'е неправильно брались данные с серверного ответа.

[dhilt]

@BitDen Хорошо! я снова не могу запуститься оркально, но я сделал небольшой рефакторинг и это требует проверки на работоспособность, и еще нужны тесты на новый API: https://github.com/dhilt/dharmadict/issues/18

[dyuvzhenko]

@dhilt Все просмотрел, единственное что пришлось сделать, это return дописать в getUserInfo. И еще хочу предложить, чтобы параметр isPublic в getUserInfo всегда был по умолчанию true. Логин мы отдаем один лишь раз, когда создаем токен только что авторизорованному пользователю. В общем взгляните - https://github.com/dhilt/dharmadict/commit/3bce65bc41099144fe0da7fb78308845be4f323b

[dhilt]

@BitDen Обычно аргументы по умолчанию имеют значение false, чтобы не делалось лишних присваиваний, поскольку в ES5 такой код (listen = (el = true) => el ? do(el) : null) превращается в

listen = function(el) {
  if (el == null) {
    el = true;
  }
 return el ? do(el) : null;
};

тогда как вариант с undefined по умолчанию (он же false в плане трактовки значения переменной-флага) транспилируется без изменений.

И второе есть соображение: неизменность прежних вызовов. Если нет существенной разницы, то предпочтительнее добавлять функционал без изменения старого. То есть только на расширение.

Но пусть будет так.

[dhilt]

@BitDen babel 5 делает следующее.

listen = (el = true) => el ? do(el) : null

становится

listen = function () {
  var el = arguments.length <= 0 || arguments[0] === undefined ? true : arguments[0];
  return el ? do(el) : null;
};

Тогда как обратная логика

listen = (el) => !el ? do(el) : null

приводит к

listen = function (el) {
  return !el ? do(el) : null;
};

[dyuvzhenko]

@dhilt Ну и дела. Подобное относится ко всем языкам программирования или же это такой случай из-за babel? Можно и переписать обратно, но тогда придется в очень многих местах дописывать второй аргумент true. Почти все данные, что отдаем с сервера, почти все публичные.

[dyuvzhenko]

@dhilt А, можно поступить хитрее. Сделать переменную isNotPublic или что-то вроде этого. И избежим случая с лишними сравнениями, и лишь в исключительных случаях будем приписывать второй аргумент в виде true в getUserInfo.

[dhilt]

@BitDen Надо оставить это в покое. Тем более, что это nodejs, там никакой транспиляции нет 😄😄😄