Антон Антон

Как вариант:
ссылка

ProfileEntity теперь type, не interface

есть такая штука - typeguard. он сообщает ts'у, что этот объект определенного типа, который указан после is. вот простенький, дальше разберешься, думаю.

function isData(data: any): data is { id: number | string } {
  return data.id !== undefined
}

Тебе надо юнион здесь и тогда тс поймёт, что дата может быть только одного типа после проверки.

export async function upsert(
  path: string,
  data: { id?: never } | { id: number | string }
) {
  if (data.id !== undefined) {
    return update(path, data)
  } else {
    return create(path, data)
  }
}

Но даже это не до конца верно, потому что у тебя передаваемый объект полностью должен быть типизирован и тогда получаем что-то в этом роде:

interface SomeDataCreate {
  name: string
}

interface SomeDataUpdate {
  id: number | string
  name: string
}

export async function upsert(
  path: string,
  data: SomeDataCreate | SomeDataUpdate
) {
  if ("id" in data) {
    return update(path, data)
  } else {
    return create(path, data)
  }
}

Никак. С кодом после минификации не надо никак работать. Минифицированный код предназначен для доставки его по сети максимально быстро на клиент. Для изменения кода вам следует вносить изменения в исходный код и уже только потом его минифицировать, а не наоборот. Если исходного кода нет - то пропускаете через любой деобфускатор и вручную восстанавливаете исходный код. Ну или пишете сами с нуля то же самое.

Обращайтесь к дискам по uuid, или по id, там в /dev/disk/by-* симлинки прописаны.

Это называется PHP. Потому как PHP изначально создавался как сам себе шаблонизатор HTML. Именно поэтому в коде присутствуют открывающие и закрывающие конструкции "<?php" и "?>"

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

<?php if ($isSent): ?>

    <p>Email sent successfully!</p>

<?php else: ?>

<form method="post" action="<?php echo $_SERVER["PHP_SELF"]; ?>">
    <label for="subject">Тема письма : </label> <br>
    <input type="text" name="subject" size="30"> <br>

    <label for="elvismail">Содержание письма : </label> <br>
    <textarea name="elvismail" id="" cols="30" rows="10"></textarea> <br>

    <input type="submit" name="submit">
</form>

<?php endif; ?>

Погуглите "php endif endfor"
https://www.php.net/manual/en/control-structures.a...

Для немецкого я всегда ставлю utf8mb4_unicode_ci
Работает просто отлично.
А кодировка utf8mb4.
Но вы скорее всего будете выбирать тип сортировки, если через phpmyadmin.
Если руками будете таблицы создавать, то надо прописать типо
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
А когда будете создавать таблицу, то примерно так.

CREATE TABLE example (
  id INT PRIMARY KEY,
  name VARCHAR(255)
) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Тут вам не нужны методы btoa и atob. В вашем коде есть место где можно получить base64 вашего изображения:

const reader = new FileReader();

  reader.onload = (e) => {
    formPreview.innerHTML = `<img src="${e.target.result}" alt="Обложка книги">`
// 
    const base64String = reader.result;
    console.log(base64String); // Вывод base64-строки, можно сохранить ее в LS
  };
  reader.onerror = (e) => alert('Ошибка!');
  reader.readAsDataURL(file);
}

А обратно кодировать ее в бинарный формат не нужно. Если присвоить атрибуту src изображения эту строку (base64String) - то картинка отобразится в html-документе

imgPreview.src = base64String;     // показываем изображение, imgPreview - id тега с img

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

Получилась вот такая функция с использованием Intl.DateTimeFormat.

function guessDate(str) {
    const f = new Intl.DateTimeFormat('en-US', {
        timeZone: 'Europe/Moscow',
        hour: '2-digit',
        minute: '2-digit',
        hour12: false,
    });

    for (const offset of ['+03', '+04', '+02']) {
        const d = new Date(`${str}:00${offset}:00`)
        if (str.endsWith(f.format(d))) {
            // console.log(offset, '\t', str);
            return d;
        }
    }
}

Пример результатов (из console.log):

+03      1980-06-01 12:00
+03      1980-12-01 12:00
+04      1981-06-01 12:00
+03      1981-12-01 12:00
+03      1991-06-01 12:00
+02      1991-12-01 12:00
+04      1992-06-01 12:00
+03      1992-12-01 12:00
+04      2011-06-01 12:00
+04      2011-12-01 12:00
+04      2014-06-01 12:00
+03      2014-12-01 12:00
+03      2015-06-01 12:00
+03      2015-12-01 12:00

Возьмите ФИАС и выдерните из неё данные в любом удобном вам виде.

наверное, корректнее поворачивать весь блок изоображений

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

Ну а малограмотный кодер вставил этот markdown-код не задумываясь.
Так что причина - копипаста без знания синтаксиса конкретного диалекта SQL.