[ARCHIVED] i18n / Применимость / DataFlow

[azinit]

@karina-jovian @sergeysova @AlexandrHoroshih @ilyaagarkov @martis-git

i18n - что это?

• entity?
• shared/lib?
• shared/config?

Как ее реализовывать в методологии?

Частично обсудили на публичном созвоне #2 29.05

Как организовывать DataFlow?

Должна ли это регламентировать методология?

Применимость методологии

Насколько высокий порог у методологии? С каким уровней знаний должна быть доступна документация и концепции, изложенные в ней?

[azinit]

i18n / theme / {fundamental-entities}

• Если locale - меняется с помощью динамического конфига, то для него нужен model-сегмент. Класть такое в shared/config - не очень

  • Бизнес-логику можно построить на моделях данных, но не всё что построено на них - бизнес-логика?
  • Как построить реактивный конфиг без модели данных?
    • На примере эффектора, создать стор, но не писать к нему методов
    • (или сингл тон + замыкание)
  • Никакой логики, лишь get/set

• Идея - менять переводы при подгрузке

  // app/init.js
  load().then(t => setTranslations(t));
  // changeLocale
  setLocale("ru")
  load("ru").then(setTranslations)

• shared/models - слишком опасно вводить

  • Если это config, то надо придумать как строить реактивные конфиги, при том что там нужен тот же ридакс и саги для фетчинга и запихивания в стор с менеджментом

• Нужно посмотреть на реальные примеры использования в библиотеках

  • Библиотеки для i18n обычно имеют примерно такое апи
    • https://github.com/lukeed/rosetta
    • https://www.i18next.com/overview/api
    • В целом, вполне себе и get/set с одной стороны и узкоспециализированный стм с другой
    • Можно i18n/theme подвести как раз под понятие shared/lib
  • Можно положить как либу (со своими геттерами и сеттерами)

[azinit]

DataFlow modelling

• Модель данных нужна для проектирования БЛ, а не для проектирования особенностей фронтенда.

  • Данные для UI (н-р тема) - тоже данные. Но их не надо складывать в модель
  • Модели которые используются в FS - это скорее business process model
  • datamodel vs business process model

• Методология - про то, как избежать ошибок при проектировании фронтенд приложений на верхнем уровне. Датафлоу, модель данных - не наша зона ответственности, и это должен решать каждый пользователь для себя

  • Мы лишь можем показать некоторые примеры применения

• Даже СТМ не про то, как моделить данные

[azinit]

Применимость методологии и ЦА

• Поступают отзывы от джунов, что ничего не понятно, но мы пока пришли к выводу что нужно больше гайдов

  • Ну да, мы же как раз когда планировали бета-релиз, выбирали какие секции по дивио-гайду для док будем делать в первую очередь
  • Джунам нужны туториалы и хауту-гайды, но для того чтобы их хорошо написать нужно много фидбека и поэтому был и фокус на сухих референсах для начала

• Методология - это комплексная вещь

  • Одних объяснений - мало
  • Нужны инструменты, основа, базис.
  • А не "у нас есть 10 видов логики..."
    • если у кода нет состояния, и там в основном функции — lib
    • если там компоненты для визуалки — ui
    • если там настройки которые шарятся по приложеию — config
  • Сложно описать грань между бизнесовой логикой и обычной

• Методология - про то, как избежать ошибок при проектировании фронтенд приложений на верхнем уровне. Датафлоу, модель данных - не наша зона ответственности, и это должен решать каждый пользователь для себя

  • Мы лишь можем показать некоторые примеры применения

• Даже СТМ не про то, как моделить данные

• Методология не должна предполагать, что пользователь полностью владеет Computer Science

• В методологии должна быть консистентность

  • Нельзя просто взять и засунуть entities в shared
  • Не должно быть много видов entities
  • Вся прелесть в консистентности - когда говорим про сегменты (lib/ui/api/...) - и везде это значит одно и то же, не возникает путанницы. Все однозначно