Статичний каталог на Python і JavaScript: як порівнювати дані без хибних результатів

Каталог можна зібрати зі статичних HTML-сторінок і додати фільтри на JavaScript. Але користь такого продукту залежить не лише від швидкості: важливо, щоб невідома ціна не перетворювалася на нуль, а одна програма в кількох містах не рахувалася як кілька різних пропозицій.

Покажемо ці рішення на прикладі Раціотеки — українського каталогу для порівняння сервісів доставки готових раціонів. Основні сторінки проєкту генеруються на Python із табличних даних. Клієнтські фільтри працюють на JavaScript.

1. Розділіть сервіс, програму та доступність у місті

У каталозі є три різні сутності:

• Сервіс — компанія, яка пропонує доставку.
• Програма — конкретний раціон цієї компанії.
• Доступність — зв’язок програми з містом та умовами доставки.

Наприклад, одна програма може бути доступна у двох містах. Це дві міські пропозиції, але одна програма. Таке розділення потрібне і для фільтрів, і для коректних підрахунків у заголовках.

У Раціотеці генератор читає окремі CSV-файли для сервісів, програм, міських записів і доставки. HTML формується під час збірки; основний текст не потребує виконання JavaScript, щоб з’явитися на сторінці.

2. Невідома ціна — це не нуль

У JavaScript Number("") повертає 0. Якщо без перевірки перетворювати порожнє поле ціни на число, програма без відомої вартості може виглядати безкоштовною та потрапити в підбірку найдешевших.

Тому у фільтрі спочатку перевіряється наявність значення:

function priceOf(card) {
  const raw = card.dataset.price;
  if (raw === undefined || raw === "") return null;

  const price = Number(raw);
  return Number.isFinite(price) ? price : null;
}

Коли користувач задає бюджет, картка з невідомою ціною не проходить цей фільтр. Це не означає, що пропозиція дорога: даних просто недостатньо, щоб підтвердити відповідність бюджету.

3. Для діапазонів перевіряйте перетин

Калорійність програми може бути діапазоном. Пошук лише за точним збігом пропустить відповідні варіанти.

Умовний приклад: програма має діапазон 1400–1600 ккал, а користувач шукає 1500–1700 ккал. Діапазони перетинаються, тому така програма має залишитися в результатах.

Логіка перевірки:

const overlaps = programMin <= selectedMax
  && programMax >= selectedMin;

Перед порівнянням треба перевірити, що потрібні межі відомі. У Раціотеці відповідні перевірки відкидають записи, які неможливо зіставити з установленими межами фільтра.

Сам фільтр допомагає знайти програми в каталозі. Він не визначає особисту потребу людини в калоріях.

4. Перевіряйте результат генерації

Помилка спільного шаблону може повторитися на багатьох сторінках. Тому перед релізом потрібна перевірка згенерованого HTML.

У проєкті перевіряються кількість H1, canonical, політика індексації, локальні посилання, потрібні ресурси та наявність очікуваних сторінок. Окрема перевірка вимагає, щоб відома ціна програми була більшою за нуль.

Такі перевірки знаходять структурні помилки. Вони не підтверджують актуальність тарифів: ціни та умови доставки потрібно звіряти з джерелами окремо.

Що застосувати у власному каталозі

Почніть із моделі даних і правил для відсутніх значень. Потім визначте, як працюють діапазони та підрахунки. Лише після цього будуйте картки й фільтри.

Спробуйте на власному каталозі три сценарії: запис без ціни, частковий перетин діапазонів і одна програма в кількох містах. Якщо результати зрозумілі та передбачувані, у продукту вже є добра основа для чесного порівняння.