Дмитрий Беляев

А что Вам не понятно в описании текста ошибки?

Argument of type 'ComputedRef' is not assignable to parameter of type 'string'.

Давайте я засуну в переводчик за Вас:

Аргумент типа 'ComputedRef' не может быть присвоен параметру типа 'string'.

const pErrorMinMessage = computed<string>(() => {
  return 'world'
})
const fun1 = function (val: string) {
  console.log('hello' + val)
}

fun1(pErrorMinMessage.value)

https://www.typescriptlang.org/play?jsx=0&module=1...

type AlbumType = {
  id: number;
  title: string;
};

enum ActionPoints {
  SET_ALBUMS = "SET_ALBUMS",
  ADD_ALBUM = "ADD_ALBUM",
  REMOVE_ALBUM = "REMOVE_ALBUM"
}

type ActionType = {
  type: ActionPoints.SET_ALBUMS;
  payload: AlbumType[];
} | {
  type: ActionPoints.ADD_ALBUM;
  payload: AlbumType;
} | {
  type: ActionPoints.REMOVE_ALBUM;
  payload: number;
};

const reducer = (state: AlbumType[], action: ActionType) => {
  switch (action.type) {
    case ActionPoints.SET_ALBUMS:
      return action.payload;
    case ActionPoints.ADD_ALBUM:
      return [...state, action.payload];
    case ActionPoints.REMOVE_ALBUM:
      return state.filter((album) => album.id !== action.payload);
    default:
      return state;
  }
};

mode === "development" ? "style-loader" : MiniCssExtractPlugin.loader,

вот на этой строке Вы обращаетесь к переменной mode, которая нигде не объявлена

Typescript compiler - это инструмент проверки типов и компиляции typescript в javascript. Так же он умеет транспайлить конструкции новых стандартов js в более старые стандарты, но это не основная задача этого инструмента, и делает он это хуже целевых инструментов, в частности его можно настроить только на конкретный стандарт.

Babel - это инструмент для парсинга js кода в AST, обхода и модификации AST и обратной сериализации AST в js. Так же это еще и экосистема плагинов и пресетов. Плагины как правило реализуют транспиляцию одной из фич более нового стандарта в более старый. Пресеты - это просто конфигурируемый набор плагинов.
Так же в Babel AST есть поддержка некоторых расширений js (а ts - это тоже расширение js), но включается это все флагами.

В экосистеме babel есть preset-env нацеленный именно на транспиляцию более новых стандартов в более старые. Его особенностью является поддержка browserlist и подключения только тех плагинов, которые нужны для указанных браузеров. За счет этого получается более оптимальный js на выходе, так как многие фичи после транспайлинга работают медленнее чем нативные и занимают больше кода.

Еще в экосистеме babel есть preset-typescript, который включает поддержку ts синтаксиса и транспиляцию ts в js. При этом, в отличии от tsc, он не делает проверку типов, а некоторые сущности может обрабатывать неправильно (как и большинство сторонних компиляторов ts, т.к. у ts нет строгой спеки и единственным источником правды является код tsc, который далек от идеального).

Оптимальным по выходному результату (пусть и за счет времени сборки) будет вариант, когда сначала ts код обрабатывается через tsc без транспиляции в старые стандарты, а затем происходит транспиляция с помощью babel + preset-env + browserlist.

https://www.typescriptlang.org/tsconfig#resolveJso...

Ну или создайте рядом с db.json файл db.json.d.ts со следующим содержимым:

declare const JSON: {
    id: number;
}[];
export default JSON;

interface Props {
  list: {
    id: number;
    name: string;
    children?: Props['list'];
  }[];
}

или

interface PropsListItem {
  id: number;
  name: string;
  children?: PropsListItem[];
}

interface Props {
  list: PropsListItem[];
}

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

Но если все же стили в каждом конкретном случае определяются сервером, то можно генерировать их на лету. Правда есть проблема, с тем, что такие стили не редактируются через devtools (хотя сейчас может уже что изменилось). Несколько лет назад я сталкивался с подобной задачей, когда стили для некоторых вариантов отображения UI задавались пользователями, я тогда написал вот такой модуль для решения этой задачи:
https://gist.github.com/bingo347/cb8e62606e206c009...

type T = {
  id: number;
  quantity: number;
}[];

У электрон под капотом node.js, а значит под него можно писать нативные аддоны так же как к node.

В плане Rust для этого есть 2 фреймворка:
https://neon-bindings.com/
https://napi.rs/

Из личного опыта, неон я пробовал, показывает он себя очень хорошо, но под капотом он не полностью использует napi, а так же задействует низкоуровневое api ноды для C++, что требует пересборки проекта под разные версии ноды, с электроном тут проще, так как мы тащим конкретную версию ноды с собой. Но с электроном есть другая особенность в плане нативных аддонов - кроссплатформенность. По сути нативные аддоны ноды - это просто динамически подгружаемая библиотека (.dll на винде, .so на линуксе и .dylib на маке), соответственно нужно будет делать билд под все платформы, под которые мы делаем наше приложение.
До napi.rs у меня руки пока не дошли, но выглядит очень хорошо. И на сколько я понял оно полностью сделано поверх napi - высокоуровневым C-abi совместимым апи, не требующем пересборки под разные версии ноды.

Насчет OpenGL/Vulkan/Metal - помимо node.js у электрон под капотом хромиум, в котором есть WebGL, который в свою очередь JS биндинг к OpenGL. Это по сути и есть OpenGL в чистом виде, просто прокинутый в JS. Но апи OpenGL весьма низкоуровневое, в отличии от DirectX/Vulkan/Metal

Потому что COUNT() - это агрегатная функция.
Делайте группировку по какому либо столбцу, и строк в результате будет ровно столько, сколько уникальных значений в данном столбце, и подсчет COUNT будет по этим значениям. Без группировки подсчет будет по всей выборке.
Либо делайте отдельными запросами вывод строк и подсчет.

Оператор ! - это булево отрицание. И он приводит свой аргумент к типу boolean. Автор не открыл Америку, и это используется. Но использовать нужно с умом.
Значения приводимые к false - это undefined, null, '' (пустая строка), 0, 0n (bigint 0), NaN.
Соответственно, когда у нас есть например строка или undefined или например число или undefined - такая проверка на undefined может быть небезопасна, так как она отсечет еще и пустую строку, 0 и NaN.

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

https://developer.mozilla.org/ru/docs/Web/API/Form...