Давай заключим контракт?

[Arlekcangp]

Эээ, ну не знаю что сказать... Не верю что фронтэндеры за столько времени не разобрались с базой ООП. Контрактное программирование? Забыто или не познано? 😁 Или всё же статья про то как джуны пишут (да, с помощью этих ваших БЯМ'ов теперь 🤣) Не затронут вопрос, что вообще то совершенно логично использовать не только ООП, но и ФП, типизировав интерфейс store параметром, который и будет типом итема. Или это на вторую часть? Можно было и сюда. Статья довольно короткая...

[ghaechka]

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

Что по существу - я не вижу смысла выводить текст через принципы ООП. они могут быть неизвестны читателю и загонять теоретической духотой я также не вижу смысла. Такое по нраву далеко не всем.

про дженерики комментарий валидный, но он нужен для переиспользования. При этом использование его требует явного интерфейса где-то снаружи, иначе он будет также непрозрачен, как и any.

Разбирать это в любом случае надо отдельно, не вижу смысла все в одно мешать.

[cmyser]

Store это антипаттерн

антипаттерн именно как отдельный слой, а не контракт, идея которого отлично разобрана

к концу статьи от стора остаётся ровно доменная модель Token + нормализатор RawToken → Token. Это и есть весь контракт. defineStore вокруг ничего к нему не добавляет а даже наоборот, синглтон и набор ref-ов поощряют «свалю сюда на всякий» (тот самый lastError).

Контракт живёт в модели! и её можно описать без всякого хранилища:

class TokenModel {
  constructor( private raw: RawToken ) {}
  get id() { return this.raw.type_id }
  get label() { return this.raw.name ?? 'Без названия' }
  get isStatic() { return this.raw.is_static } // boolean, как обещано
}

Геттеры это ленивая нормализация. Реактивность любой фреймворк навесит сверху (reactive / computed / mem) т.е контракт от этого не зависит. Граница "raw data против домена" перестаёт быть вопросом: она и есть конструктор.

Убери стор и контракт останется. Значит, обещание давал не он. Жду вторую часть про нормализатор,

Где по-моему, ответ как раз «в модель».

Подробнее о "не" разделении инициализации и хранении тут https://mol.hyoo.ru/#!section=docs/=qdee2z_6ocqkh

[ghaechka]

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

Убери стор, контракт остается

Да, но кудато-то денется задача держать список токенов, который будет общим для компонентов. Кто-то должен его держать, pinia – один из вариантов, валидный именно для VUE.

Стор – антипаттерн как слой

Это позиция отдельной школы. Я пишу про VUE и на нём же разрабатываю. Логично, что этот вопрос будет вовсе за рамками этой серии. :)