Евгений Журов

Есть ли принципиальная разница между этими подходами?

Ну, как бы да - в первом случае используются классы, во втором - функции. В этом

какой подход правильнее использовать. Пока возникает ощущение, что всё это - сугубо вкусовщина.

Это, имхо, вопрос размера проекта и сложности ориентирования в нем. То есть, для простой КРУД-ориентированной системы классы могут быть излишни. Но чем больше логики вынесено за пределы "чтения-записи" из БД, тем ощутимее нужны будут классы.

И какие еще есть подходы

Есть еще процедурное, но оно сейчас используется исключительно для простых программ и на скриптовых языках по типу питона и ванильного js.

Перегрузки нужны в следующих случаях:
1. Когда от типа некоторого аргумента зависит тип возвращаемого значения;
2. Когда от типа некоторого аргумента зависят типы последующих аргументов;
3. Комбинация из 1 и 2 вариантов.

Важно понимать, что в TS перегрузки существуют только на уровне типов, в отличии от других языков. Притом сами перегрузки реализованы как intersection от всех сигнатур, что порой вызывает проблемы с присвоением функции к типу с перегруженной сигнатурой. Все дело в вариантности, так как аргументы функции контравариантны сигнатуре самой функции, когда большинство отношений типов (и intersection в том числе) в TS ковариантны. В вашем примере с SumOrConcat эту проблему решили через тип any, который делает любую композицию типов с ним бивариантной.

На самом деле в примере с SumOrConcat вполне можно задать типы аргументам:

type SumOrConcat = {
  (a: number, b: number): number
  (a: string, b: number): string
}

const result: SumOrConcat = (a: number | string, b: number): any => {
  if (typeof a === 'number') {
    return a + b
  }

  return `${a} ${b}`
}

Но надежнее все же так:

type SumOrConcat = {
  (a: number, b: number): number
  (a: string, b: number): string
}

const result = ((a: number | string, b: number): number | string => {
  if (typeof a === 'number') {
    return a + b
  }

  return `${a} ${b}`
}) as SumOrConcat;

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

function sumOrConcat(a: number, b: number): number;
function sumOrConcat(a: string, b: number): string;
function sumOrConcat(a: number | string, b: number): number | string {
  if (typeof a === 'number') {
    return a + b
  }

  return `${a} ${b}`
}

const result = sumOrConcat;

Так же, очень часто можно обойтись без перегрузки используя дженерики. Сам такой код будет выглядеть сложнее, но пользоваться им будет проще. Пример.

Ну или, может, какие-то другие варианты есть?

Есть. Использовать каждую СУБД по назначению и не пытаться запихнуть реляционные данные в документную БД.

А вообще, наверное стоит просто для независимых сущностей генерировать новые ObjectId, и протаскивать их во все зависимые сущности вместо соответствующих id. Ну т.е. не нужно пытаться решать задачу в лоб, пытаясь сконвертировать один id в другой, вам нужно сконвертировать СВЯЗЬ, а не id. Чтобы сконвертировать связь, вам не нужен оригинальный id, вам важно соединить с помощью нового ObjectId те же самые сущности, что были соединены в реляционной базе оригинальным id.

Можно на CSS

Накликайте свой полигон в geojson.io и подставьте туда.

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

Никакое, ибо не зачем.

Валидация делается по событиям keyup и paste

Почему бы не городить костыли и просто не использовать событие input?

input с type="number" уже отсеет невалидные символы, хотя валидное число будет далеко не обязательно

Последовательно:

async function fetchRecursive(arr) {
  const result = [];

  if (Array.isArray(arr)) {
    for (const n of arr) {
      try {
        result.push({ status: true, result: await fetch(n.url).then(r => r.json()) });
      } catch(error) {
        result.push({ status: false, error });
      }

      result.push(...await fetchRecursive(n.children));
    }
  }

  return result;
}

Параллельно:

const flat = arr => (arr || []).flatMap(n => [ n.url, ...flat(n.children) ]);

const fetchRecursive = arr => Promise.allSettled(flat(arr).map(n => fetch(n).then(r => r.json())));

Попробуйте заменить мутацию на такую:

startMutation(state, data) {
  const index = state.listings.findIndex(item => item.id === data.id)
  state.listings.splice(index, 1, {...state.listings[index], is_edited: true})
}

Потому что экземпляр компонента заново не создаётся при смене значений параметров. За ними надо следить:

watch: {
  '$route.params.slug': {
    immediate: true,
    handler() {
      // сюда переносите код из created
    },
  },
},

Вот официальная схема. Родители детям через props, назад через events.


1) Пример объявления child в template родителя

<child :somedata="data1" @bestEventEver="someMethod"/>

-передаешь данные из переменной родителя data1 чилду в пропс somedata.
-вешаешь метод родителя someMethod для обработки кастомного ивента 'bestEventEver', приходящего из чилда

2) В child вызываешь this.$emit('bestEventEver', 'params pam pams')

Есть сокращения этого для простых случаев через :v-model и .sync, читай официальный гайд

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

Если нужно общение не уровня родитель-ребенок, а все со всеми, вот варианты

Дофига лишний компонентов на первый взгляд..
Но фиг с ним. Пилите роутер-вью на месте меняемых компонентов:

<div id="app">
    <router-view></router-view>
</div>

<main class="main">
    <app-aside></app-aside>
    <router-view></router-view>
</main>

<section class="app__section">
    <section-header></section-header>
    <router-view></router-view>
</section>

Ну а дальше изучать https://router.vuejs.org/ru/guide/essentials/neste...

Вот вариант максимально короткий и лёгкий для понимания:

const unique = (arr, keys) =>
  arr.filter(n => n === arr.find(m => keys.every(k => m[k] === n[k])));


const result = unique(arr, [ 'model', 'param1', 'param2' ]);

Для вашего случая подходит, но вообще, есть ряд проблем:

• Иногда косячит

  
  Если объект присутствует в массиве несколько раз, то такие дубликаты не будут отброшены. Конкретно эта имеет тривиальное решение - вместо ссылок можно сравнивать индексы, под которыми объекты представлены в массиве:
  
  

  - arr.filter(n => n === arr.find
  + arr.filter((n, i, a) => i === a.findIndex

• Недостаточно гибко

  
  Что если уникализировать надо не по собственно свойствам, а по каким-то производным от них значениям? Например, у объектов есть вложенные объекты, и нужны их свойства; или есть число, а нужен остаток от его деления на какое-то другое число; или есть дата, в которой важен только месяц.
  
• Сложность

  
  Фильтрация линейна, поиск тоже, одно внутри другого даёт квадрат.
  

Так что вот вариант потяжелее:

const unique = function(arr, keys = n => n) {
  const picked = new Map;
  return arr.filter((...args) => {
    const p = []
      .concat(keys(...args))
      .reduce((acc, k) => acc.set(k, acc.get(k) || new Map).get(k), picked);

    return !p.set(this, p.has(this)).get(this);
  });
}.bind(Symbol());


const result = unique(arr, n => [ n.model, n.param1, n.param2 ]);