Pull to refresh

Comments 20

А какие проблемы у вас были с vuex-module-decorators?
Признаться у меня в воспоминаниях осталось только что-то вроде «не сработало». Если мне не изменяет память (это было около 4-х месяцев назад) я пытался использовать модуль внутри модуля… Либо архитектура приложения что-то не позволяла сделать. Еще возможно, что были проблемы с типизацией, которые могли быть из-за неполноценной на тот момент поддержки IDE (WebStorm) Typescript (после недавних обновлений стало намного лучше). На vuex-smart-module остановился потому что он позволил все реализовать без танцев, ошибок и нетривиальных конструкций. А может все было просто из-за моей не опытности. Но могу наверняка сказать, что с моей небольшой подготовкой (на тот момент) именно этот модуль оказался идеальным инструментом, с которым удалось сходу (почти) начать работать.

Так самое-то важное, а как затипизированы commit и dispatch?

Примерно вот так (вырезал кусками и кое-что поменял, прошу прощения, если что-то упустил):
export type Category {
  attributes: {
    hasPrice: boolean;
    icon: string;
    lvl: number;
    name: string;
    slug: string;
  };
  id: number;
}

export interface IParams {
	city_id: number
}

class AppState {
	categories: Category[] = [];
}

/* ... */

class AppMutations extends Mutations<AppState> {
  setCategories(categories: Category[]) {
    this.state.categories = categories;
  }
}

class AppActions extends Actions<
  AppState,
  AppGetters,
  AppMutations,
  AppActions
> {
  async getCategories({params}: {params: IParams}): Promise<Category[]> {
    return categoriesAPI.get({params}).then(
      ({ data: categories }: { data: Category[] }) => {
        this.commit("setCategories", categories);

        return categories;
      }
    );
  }
}


Обновил статью. Спасибо, что указали на промах.

Главная проблема типизации в этой строчке:


this.commit("setCategories", categories)


Как вы обеспечиваете гарантию того, что такой mutation действительно существует и принимает именно такой набор аргументов?

Я, возможно, не правильно вас понял. Ответ лежит на поверхности: гарантии обеспечивает модуль vuex-smart-module, который берет на себя эту работу. Он предоставляет классы, которые через дженерики расширяются соответсвующими типами. В примере в статье видно, как это происходит. Таким образом, если вы попытаетесь указать в commit несуществующую мутацию, то Typescript вам об этом сообщит, подсветит место и подскажет, что не так. То же самое касается и принимаемых наборов аргументов.

Гарантия существования мутации и принимаемых аргументов:
class AppMutations extends Mutations<AppState> {
  setCategories(categories: Category[]) {
    this.state.categories = categories;
  }
}

class AppActions extends Actions<
  AppState,
  AppGetters,
  AppMutations,
  AppActions
> { /* ... */ }


Вот пара файлов, в которых можно увидеть, как это реализовано: раз, два.

Мне кажется, что проблема вот тут
this.commit("setCategories12345", categories);
Если в названии мутации написать людей текст, то он будет комплимент, но не будет работать. Это — отсутствие типизация. Почему бы не указывать вместо строкового литерала именно член класса?

Если в названии мутации написать людей текст, то он будет комплимент, но не будет работать.

Это на Алиэкспресском написано?
В моем случае при настроенной IDE (в т.ч. и в консоли вылетает) я получаю вот такой результат:

image

Теперь не уверен. А у вас какая ide?

У меня WebStorm последней версии. Посмотрите, может у вас TS не настроен?.. Либо VSCode как альтернатива — он работает с TS идеально.
Typescript, конечно, классная вещь, но хотя некоторые концепции требуют немалого напряжения извилин, так например Mapped Types осознать было не просто, но зато когда, наконец, понимаешь это, то поражаешься, насколько мощный это инструмент. С помощью этих Mapped Types создал свою библиотечку для управления состоянием в Angular, и теперь задумался — может ее и для Vue можно адаптировать.

ох, я бы сейчас не стал начинать проект на class components, сильно больно будет обновляться на vue 3

старый синтаксис никуда не денется ведь

ну так я про синтаксис ничего не говорил, но вот в 3 версии искаропки не будет поддержки class api, рисковать ради непонятно чего? нафиг, лучше на объектном синтаксисе делать, что бы потом можно было легко обновится на 3 версию. или, даже лучше, быстро сконвертировать в новый функциональный синтаксис.

так и во втором не было поддержки class api. В чём проблема?

во втором таки поддержка class api официальная, репо классов лежит в репо вуя, а в 3 версии поддержку уже не обещают.

vue-class-component это всё равно не часть фреймворка. Ничто не помешает ей работать с Vue 3 и дальше

А мне было интересно и полезно, спасибо автору за статью (:
До этого работал с Vue только в связке с Flow, т.к. осознание преимущества типизации зашло не сразу (не у меня, у тиммейтов), а переделывать было уже некогда. Теперь вижу как можно подружить Vue с TS и первое впечатление крайне положительное (:

По идее, TS можно настроить так, что он практически ни на что не будет ругаться. Это позволит прозрачно перейти на TS без изменения кода. Особенно мне понравилось, что когда ты основательно типизируешь всякие сущности, то IDE в дальнейшем сразу подсказывает тебе какие есть ключи, что можно использовать сразу, а что надо проверить на null и т.д… В итоге отладки стало в разы меньше. (Понятное дело, что это могут решить тесты, но вы же понимаете...)
Sign up to leave a comment.

Articles