1️⃣ Контрольовані та неконтрольовані компоненти в React
📌 Очікувана відповідь:

📍 Контрольований компонент (Controlled component) – це коли значення елемента форми повністю контролюється React через state.

Тобто:
• значення input зберігається у state
• кожна зміна проходить через onChange → setState
• UI завжди відображає state

Приклад:

function InputExample() {
  const [value, setValue] = React.useState('');

  return (
    <input
      value={value}
      onChange={(e) => setValue(e.target.value)}
    />
  );
}

👉 React – єдине джерело істини (single source of truth).

📍 Неконтрольований компонент (Uncontrolled component) – це коли значення зберігається в DOM, а React лише читає його при потребі (через ref).

Приклад:

function InputExample() {
  const inputRef = React.useRef(null);

  const handleClick = () => {
    console.log(inputRef.current.value);
  };

  return (
    <>
      <input ref={inputRef} />
      <button onClick={handleClick}>Submit</button>
    </>
  );
}

👉 Джерело істини – DOM, а не React state.

📌 Коли що використовувати:
📍 Controlled
• складні форми
• валідація в реальному часі
• залежні поля / динамічний UI
• коли потрібно повністю контролювати дані

📍 Uncontrolled
• прості форми
• швидкі прототипи
• інтеграція зі сторонніми бібліотеками (наприклад, legacy JS або non-React)
• коли не потрібен контроль на кожен input event

⚠️ Що часто питають додатково:
• при controlled компонентах більше ререндерів → можливі перформанс-проблеми на великих формах
• uncontrolled компоненти складніше тестувати та валідовувати
• не можна змішувати

value

і

defaultValue

в одному input

 • defaultValue

використовується саме для uncontrolled компонентів

І бажаємо успіхів на співбесідах!
Крок за кроком – до оферу 🚀

TikTok | Instagram | Telegram

Знаєш цей момент, коли думаєш: “та це ж просто background job, що тут може піти не так?” 🙂

А потім з’являється Sidekiq, черги, ретраї, і раптом усе стає трохи складніше, ніж здавалося.

Майже кожен Rails-проєкт має background jobs:
відправити email, порахувати щось, синхронізуватися з API чи згенерувати звіт.

І здається, що це просто… поки не починаються перші нюанси.

📍 Rails без магії: 7 помилок, які роблять навіть мідли

І майже кожен з нас колись писав джобу так:

class ChargeUserJob
  def perform(user_id)
    user = User.find(user_id)
    PaymentService.charge(user)
  end
end

Все працює. Поки не спрацює retry.

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

Ми всі так робили 🙂

Що таке ідемпотентність простими словами?
Ідемпотентна операція – це така, яку можна виконати кілька разів, і результат залишиться однаковим.

Наприклад:
• “створити запис” – ❌ не ідемпотентно
• “встановити статус = paid” – ✅ ідемпотентно
• “списати 100 грн” – ❌ дуже небезпечно
• “перевірити, чи вже списано, і якщо ні – списати” – ✅ вже ближче

Де найчастіше ламаються джоби
🔹 HTTP інтеграції без перевірки стану
🔹 Відсутність унікальних індексів
🔹 Немає перевірки “чи вже виконано”
🔹 Використання

create!

замість

find_or_create_by

🔹 Логіка, яка залежить від “попереднього стану” без блокувань

Як писати безпечні background jobs
1️⃣ Використовувати унікальні індекси в БД

add_index :payments, :external_id, unique: true

Validation не захистить від race condition. Індекс – так.

2️⃣ Робити перевірку перед виконанням

return if payment.processed?
payment.process!

3️⃣ Використовувати транзакції

ActiveRecord::Base.transaction do
  ...
end

4️⃣ Думати про retry як про нормальний сценарій
Не “якщо впаде” – а “коли впаде”.
Sidekiq retry – це не виняток, це частина механіки.

Міні-правило, яке рятує нерви
Якщо твоя джоба не витримає повторного виконання – вона небезпечна.

Особливо якщо це:
• гроші
• доступи
• інвентар
• інтеграції

У кого був продакшн-кейс із дублем через retry? І що тоді рятувало – індекс чи гарячий фікс? 😄

TikTok | Instagram | Telegram