Соглашение о присвоении имен / шаблон для данных компонента, который прокси / увеличивает проп? - PullRequest
0 голосов
/ 02 ноября 2019

Я обнаружил, что пишу код компонента следующим образом:

<template>
 <input :value="value"  v-bind="optionsData" />
</template>

<script>

const BASE_OPTIONS = { ... };

export default {
  name: "MyComponent",
  props: {
    value: String,
    options: Object,
  },
  data() {
    return {
      optionsData: {
        ...BASE_OPTIONS,
        this.options,
      },
    };
  },
};
</script>

То есть я хочу разрешить родительскому элементу передавать набор опций компоненту, но сам компонент предоставляет значения по умолчанию длявсе, что не включено.

Есть аналогичные случаи, когда я мог бы создать вычисляемый "прокси" для значения prop, чтобы он мог правильно реагировать на установку.

Общая нить - в основном это значение упора , но технически оно не может быть опорой по причинам, которые выходят за рамки большинства случаев использования. Во многих случаях код начинается с непосредственного использования реквизита, и его необходимо изменить позже из-за новых требований.

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

Исходя из Python, мой первый инстинкт - префикс подчеркивания, например _optionsно это не верноЯ обнаружил, что добавление подчеркивания типа options_ работает, но это кажется мне менее очевидным. Поскольку все мои имена - camelCase, кажется, лучше что-то добавить, чтобы сохранить регистр «базового» имени.

...