foterio

Про работу с временем и датами уже столько написано. Почему бы сначала не погуглить и не почитать?:
https://habr.com/ru/post/100741/
https://habr.com/ru/post/123461/
https://habr.com/ru/post/61391/
https://habr.com/ru/post/357704/
https://habr.com/ru/post/273177/
https://habr.com/ru/post/278527/
https://habr.com/ru/post/146109/
https://habr.com/ru/company/yandex/blog/463203/
https://qna.habr.com/q/674245

Был такой нудный дедушка Эдгар Кодд. Он как-то из соображений своей нудности взял и объявил что только он знает как правильно делать реляционные базы.

Вобщем его первое правило касается атомарности данных которые лежат в ячейках таблицы. И если в рамках решаемой вами задачи JSON атомарен - то все в порядке и никакой проблемы нету. Храните себе JSON.

Но если внутри JSON будет поле которое способно изменяться независимо от остальной части документа - то старичок Эдгар будет на вас сильно зол. Может даже вас побить.

В наше время уже созданы специализированне БД (Mongo, CouchDb) которые плевали на нормализацию. Они расширяют и ослабляют понятия нормализации. Not-Only-SQL говорят про себя.

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

Для каждого типа данных, например для публикаций, создается отдельная таблица, содержащая поля, характеризующие соответствующие данные. Так, для хранения публикаций может быть создана таблица "publications" со следующими полями:

- id - уникальный идентификатор публикации;
- title - заголовок публикации;
- text - текст публикации;
- date - дата публикации;
- user_id - идентификатор пользователя, который опубликовал данную запись.

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

Для хранения комментариев и ответов можно создать аналогичные таблицы с аналогичными полями, но также дополнительно указывать идентификатор публикации, к которой они относятся. Таким образом, можно связывать комментарии и ответы только с теми публикациями, которые определенный пользователь опубликовал.

Важным моментом является связь между таблицами. Если у одного пользователя может быть несколько публикаций, то в таблице пользователей можно создать поле "id", которое связывается с полями "user_id" из таблиц публикаций, комментариев и ответов. Таким образом, можно легко связывать отдельные записи с конкретным пользователем.

Ну и ещё пара способов: 1. Использовать JSON-поля. Например, в таблице пользователей может быть создано поле "content", в котором будет храниться JSON-объект, содержащий информацию о публикациях, комментариях, ответах и прочих данных, связанных с пользователем. Однако, такое решение может усложнить поиск и фильтрацию данных.

2. Использовать таблицы на основе пользовательских идентификаторов. При таком подходе создаются отдельные таблицы для каждого типа данных, например, "publications", "comments", "replies" и т.д., каждая из которых содержит поля, связывающие запись с идентификатором пользователя. Таким образом, можно создать множество записей, связанных с одним пользователем, и при этом уменьшить вероятность дублирования данных.

Сделайте проще

const [errors, setErrors] = useState({
    name: '',
    teleph: '',
    email: '',
});

// когда нужно устанавливается одну ошибку
setErrors({ ...errors, [name]: value })
// где name - имя ключа объекта с ошибками, value - значение ошибки

А как без req.query вы передадите какие-либо дополнительные данные в GET запросе? GET запросы не могут иметь тела, однако для пагинации limit и offset как-то надо прислать, вот и остаются query параметры.

GET /entity?limit=10&offset=0

Если сделать это параметрами, то это будет выглядеть как-то так

GET /entity/10/0

Согласитесь, что реализовывать это так — очень плохая идея. Даже если не брать во внимание полное отсутствие читаемости, мы как минимум лишаем себя возможности сделать роут GET /entity/:id, тк перекрываем его предыдущим роутом.

Для преобразования HTML-кода в текст вам необходимо использовать функцию decodeEntities. В вашем случае, чтобы преобразовать поле "name" каждого объекта в HTML-код, вам нужно пройтись по массиву объектов с помощью метода map и применить функцию decodeEntities к полю "name". Вот пример кода на Node.js:

const entities = require('html-entities').AllHtmlEntities;

connection.query("SELECT * FROM database", function(error, results) {
    const decodedResults = results.map(result => {
        return {
            id: result.id,
            name: entities.decode(result.name)
        };
    });
    res.json(decodedResults);
});

монгусовский populate не выйдет совместить с аггрегацией в одном запросе,
попробуй как-то так

Post.aggregate([
  { 
    $lookup: {
      from: 'definitions',
      localField: 'definition',
      foreignField: '_id',
      as: 'definitions'
    } 
  },
  {
    $match: {
      'definitions.likes': { $gte: 10 }
    }
  }
])

(если не выйдет, то предлагаю потыкать аггрегацию в mongodb compass, там очень наглядно будет расписываться каждый шаг)

а вообще, нет причин хранить лайки и заголовок поста отдельно от поста

Что-то вы совсем намудрили, всё гораздо проще.

getEmail() {
	return new Promise((resolve, reject) => {
		this.start();

		this.db.query('SELECT * FROM contacts', (err, contacts) => {
			if (err) {
				reject(err);

				return;
			}

			const emails = contacts
				.map(contact => contact.email)
				.filter(Boolean);

			this.end();

			resolve(emails);
		});
	});
}

_db.getEmail()
	.then((emails) => {
		console.log(emails)
	})
	.catch((error) => {
		console.log('Error in the Query', error);
	});

По хорошему бы сделать что бы запросы к БД сразу возвращали Promise тогда это станет гораздо удобней.

https://kenwheeler.github.io/slick/

Создайте функцию проверки

function ThisIsWebP() {
    var def = $.Deferred(), crimg = new Image();
    crimg.onload = function() { def.resolve(); };
    crimg.onerror = function() {def.reject(); };
    crimg.src = "https://simpl.info/webp/cherry.webp";
    return def.promise();
}

И проверяем:

ThisIsWebP().then(function() {
    //Есть поддержка webp
}, function() {
   //Нет поддержки webp
});