Эффективное использование опций в VueTS - PullRequest
0 голосов
/ 05 февраля 2019

Будучи довольно новым для кодирования, особенно в Vue, мне интересно, какие разумные способы существуют в Vue / Typescript для объявления несуществующих значений в зависимости от контекста.

Предварительные мысли:

  • Всякий раз, когда мы связываем переменные с шаблонами компонентов, они не должны быть undefined в любое время - или отклик, по-видимому, нарушается
  • Имея это в виду, я начал использовать в качестве объявления по умолчанию typeA | null чаще
  • Имея дело с интерфейсами, структурой данных и реальной базой данных, я иногда теряюсь, как мне их писать.Давайте рассмотрим простой пример:

user-settings.ts

// For each new user a new object of type `UserSettings` is created, e.g. in the cloud in `onAuthCreate`

// option A
export interface UserSettings {
    analyticsEnabled: boolean
    personalDataRequestedAt?: number
    personalDataDownloadLink?: string
    userId: string
}

// option B
export interface UserSettings {
    analyticsEnabled: boolean
    personalDataRequestedAt: number | null 
    personalDataDownloadLink: string | null
    userId: string
}

// option C
export interface UserSettings {
    analyticsEnabled: boolean
    personalDataRequestedAt: number // starting with 0
    personalDataDownloadLink: string // starting with ''
    userId: string
}
  • A чувствует себя очень гибким ивероятно, ближе всего к тому, что кажется интуитивным;но я предполагаю, что мне нужно будет заново заполнить все свойства, которые undefined локально null, перед их передачей моим компонентам, чтобы защитить привязку к шаблону (или есть другой способ / что-то, что я пропускаю?)
  • После B У меня будет такая декларация почти везде в моих интерфейсах - она ​​очень четкая и требует свойств в каждом случае (что может быть как положительным, так и отрицательным?)
  • C больше похоже на то, что используется в компоненте пользовательского интерфейса для установки значений по умолчанию

Интересно, какой подход "vue-like" идетхорошо сочетается с машинописью и общими привычками кодирования.

1 Ответ

0 голосов
/ 05 февраля 2019

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

C не может быть и речи.Здесь это снова для справки:

export interface UserSettings {
    analyticsEnabled: false
    personalDataRequestedAt: 0
    personalDataDownloadLink: ''
    userId: string
}

В этом вы говорите, например, analyticsEnabled это всегда ложь.Это не то же самое, что сказать, что это значение по умолчанию.

В случае, если BI будет иметь такое объявление почти везде в моих интерфейсах - но оно выглядит очень явным

Я предпочитаю B. Явное - это хорошо, явное - это правильно ?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...