DEV Community: racioteka

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

racioteka — Wed, 14 Oct 2026 21:03:50 +0000

Каталог можна зібрати зі статичних 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, політика індексації, локальні посилання, потрібні ресурси та наявність очікуваних сторінок. Окрема перевірка вимагає, щоб відома ціна програми була більшою за нуль.

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

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

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

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

I built a comparison catalog for meal delivery in Ukraine - and stopped opening 20 browser tabs

racioteka — Wed, 14 Oct 2026 12:26:03 +0000

Choosing a meal delivery service (ready-made rations) in Ukraine used to mean opening 20+ websites and comparing them manually: price per day, calories, delivery zones, diets, goals. Every service has its own menu format, its own pricing logic, its own definition of "one meal". It's a classic directory problem.

So I built Racioteka — a catalog that aggregates dozens of Ukrainian meal-delivery services in one place, with filters by city, goal, diet and calories, plus a calorie calculator and a side-by-side comparison tool.

Here's what I learned building it.

The problem: everything is "almost comparable"

The services are similar on the surface: daily rations, X meals per day, Y kcal, delivered in the morning. But the details are messy:

Pricing: some quote per day, some per week, some per "program". One service includes delivery, another adds it at checkout.
Calories: ranges like "1200–1500 kcal" vs exact numbers.
Meals: 3, 4, or 5 meals per day — and "snack" means different things to different brands.
Diets: keto, vegan, gluten-free, lactose-free, sugar-free — with overlapping definitions.

The core engineering task was normalization: mapping all this chaos into a single schema.

// Simplified normalization shape
const service = {
  name: "Example Food",
  city: ["kyiv", "lviv"],
  pricePerDay: { min: 420, max: 850, currency: "UAH" },
  calories: { min: 900, max: 3000 },
  mealsPerDay: 5,
  goals: ["weight-loss", "fitness", "detox"],
  diets: ["keto", "vegan", "gluten-free"],
  delivery: { free: true, zone: "city + suburbs" }
};

Once you have a clean shape, everything else becomes easier — filtering, sorting, comparing.

The filters that matter

Users come with different intents. The filter set we settled on:

City — most services are local (Kyiv, Lviv, Odesa, Ivano-Frankivsk...). A national catalog without city filtering is useless.
Goal — weight loss, maintenance, muscle gain, detox, medical nutrition.
Diet — keto, vegan, vegetarian, pescatarian, gluten-free, lactose-free, sugar-free.
Calories / price — the two numeric dimensions everyone compares.

Nothing revolutionary — but getting the category taxonomy right is 80% of the product. We iterate on it constantly.

The calorie calculator

A common question: "How many kcal do I actually need?" Instead of making users guess, we added a calculator based on the Mifflin–St Jeor equation:

Men:   BMR = 10*weight + 6.25*height − 5*age + 5
Women: BMR = 10*weight + 6.25*height − 5*age − 161

Then we multiply by an activity factor (1.2 sedentary … 1.725 very active). The result plugs directly into the calorie filters — a nice "wow, it understands me" moment.

The comparison tool

The most requested feature: compare two programs side by side. We show:

price per day (and total for N days)
calories per day and per meal
number of meals
delivery zones and schedule
included diets / exclusions

It sounds trivial, but the UX detail matters: users want to compare their two shortlisted options, not a table of all 30 services. So the flow is: filter → pick 2 → compare.

Business model: the directory play

Racioteka is free for users and takes no commission — orders happen directly on the service's website. We're a discovery layer.

Revenue directions (in progress):

Featured listings — priority placement for services that want more visibility.
B2B / corporate — companies ordering meal plans for teams.
Affiliate / promo codes — when it makes sense for users.

The interesting part of the directory model: the catalog itself becomes a backlink source for every service listed. Which means the services have an incentive to keep their data accurate and even link back. It's a positive loop.

Lessons learned

Data quality beats features. A catalog with wrong prices is worse than no catalog. We manually verify and always show "confirm with the service" disclaimers.
Taxonomy is the product. Invest in the category tree early; refactoring it later is painful.
Local matters. For Ukraine, delivery zones and cities are the #1 filter. "National" services barely exist — almost everyone is city-specific.
Don't build a marketplace first. Start with the directory (information), prove traffic, then add transactions.

Try it

If you're in Ukraine (or curious about the market), check out Racioteka — it's free.

If you've built a directory or comparison product, I'd love to hear:

How did you handle data normalization?
What's your taxonomy strategy?
Directory vs marketplace — which did you start with?

Drop your thoughts in the comments 👇