1 жовтня — день нашої безмежної вдячності кожному й кожній, хто нас захищає.

Дякуємо за кожен ранок, за можливість працювати, бути вдома та обіймати рідних. Наша повага — кожному, хто зараз у строю. Пам’ять про тих, кого з нами немає — назавжди в серці 💔

Бережіть себе та повертайтеся.
Слава Україні! Героям слава!! 🇺🇦

TikTok | Instagram | Telegram

Коли кажеш оцінку “два дні”, закладаєш час на каву та непередбачувані баги, а все одно виходить “ще вчора треба було закінчити” 🙃

В ІТ є три нескінченні речі: вогонь у продакшені, правки перед релізом і фраза “Це ж просто текст поміняти, чому так довго?”

Зібрали фрази для тих моментів, коли менеджер або клієнт просить “зробити дрібничку за 5 хвилин”:

#codica_english

💬 “Even small changes can have side effects in the existing codebase.”
Навіть невеликі зміни можуть мати побічні ефекти в існуючому коді.

💬 “I can implement a quick workaround, but we’ll need to refactor it later.”
Я можу зробити швидке тимчасове рішення, але потім доведеться його рефакторити.

💬 “Let’s estimate the risks before diving into this.”
Давайте оцінимо ризики перед тим, як занурюватися в це.

💬 “We need a proper investigation to give you an exact timeline.”
Нам потрібне детальніше дослідження, щоб дати точні терміни.

💡 Зберігайте, щоб не казати “я швидко”, коли точно знаєте, що це на весь день)

TikTok | Instagram | Telegram

Хто тут ще намагається «вайбкодити», коли підходи до роботи з ШІ змінюються швидше, ніж ми встигаємо за ними стежити?

Якщо ви вже використовуєте ChatGPT та інші AI-інструменти в роботі, але відчуваєте, що використовуєте їх далеко не на максимум — час трохи систематизувати знання.

Ми знайшли безкоштовний курс «Від початківця до експерта в ШІ» від FRACTAL.

Він підійде тим, хто хоче зрозуміти, як використовувати ШІ для роботи, навчання та професійного розвитку.

Тож зберігайте, сідайте клацати й перевіряйте себе: що з інструментів і підходів ви вже давно використовуєте в роботі, а що досі пропустили 👀

👉 [Гайда на курс]

TikTok | Instagram | Telegram

Друзі, всім легкого і трохи лінивого вихідного!

Сьогодні той момент, коли планував просто подивитися серіал, але випадково відкрив відео про IT. І бац — через три години ти вже «сеньйор-помідор» у власних думках, який обирає колір для своєї яхти 😄

Тож приємного перегляду 👇

➡️ 5 способів вивчити мову програмування
Не існує одного “правильного” способу — тут розкладуть по поличках, як вчитися ефективно і не витрачати час дарма.
⏱ Тривалість — 20 хв

➡️ Концепції Linux. Пояснення роботи та чому більша частина інтернету працює на лінукс
База, яку варто знати кожному, хто працює з серверами або хоче зрозуміти, як влаштований інтернет зсередини.
⏱ Тривалість — 10 хв

➡️ Що трапилось з медіа в браузері і до чого тут Apple? | Злет і падіння вільного інтернету
Глибока документалка про еволюцію вебу. Вона варта кожної хвилини, якщо хочете зрозуміти, як корпорації та технології змінили наш цифровий світ.
⏱ Тривалість — 2 год 22 хв

➡️ Навіщо програмісту універ?
Чесний розбір: універ, курси чи самонавчання — що реально працює і де не втратити час.
⏱ Тривалість — 16 хв

➡️ Як постало українське IT
Історія індустрії, якою ми зараз користуємось щодня — від перших кроків до світового рівня.
⏱ Тривалість — 51 хв

Нехай ці вихідні будуть з користю, новими ідеями і без відчуття “я нічого не встиг” ☕
І якщо раптом захочеться щось змінити — це вже хороший знак 🚀

TikTok | Instagram | Telegram

Раночку! ⚡️

Таски відкрили, каву заварили і до справ! Всім успішного дня! 😎

#codica_humor

TikTok | Instagram | Telegram

🎯 А як у інших? Питання з IT-співбесід

#codica_interviews

✅ Хороша підготовка — розуміти, чому саме React так працює.
❌ Погана — відповідати: «Ну… так у документації було».

Ми зібрали 5 питань, на яких часто перевіряють не знання синтаксису, а розуміння того, як працюють JavaScript і React.

Готові перевірити себе? 👇

1. Чому useEffect може працювати з «неактуальним» state?

📌 Питання:

Що буде виводити console.log, якщо натискати кнопку?

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count);
    }, 1000);

    return () => clearInterval(id);
  }, []);

  return (
    <button onClick={() => setCount(c => c + 1)}>
      {count}
    </button>
  );
}

📌 Очікувана відповідь:

console.log продовжить виводити 0.

Причина — stale closure.

Callback усередині setInterval замикає значення count із того render, у якому був створений Effect. У нашому випадку це 0.

При цьому count — reactive value, яка використовується всередині Effect, але відсутня в dependency array. Тому Effect не синхронізується з наступними значеннями count.

До речі, правило exhaustive-deps у eslint-plugin-react-hooks саме на це й поскаржиться.

Якщо Effect має реагувати на зміну count, його можна додати в dependencies:

useEffect(() => {
  const id = setInterval(() => {
    console.log(count);
  }, 1000);

  return () => clearInterval(id);
}, [count]);

Тоді після зміни count React спочатку виконає cleanup попереднього Effect, а потім запустить Effect знову з актуальним значенням.

Важливий нюанс: у цьому варіанті interval буде перестворюватися при кожній зміні count, тому в реальному коді можуть бути доречними й інші рішення залежно від задачі.

📌 Що перевіряє інтерв'юер:

Чи розуміє кандидат JavaScript closures, React render model, Effects та dependency array, а не просто знає синтаксис useEffect.

2. Чому key={index} може призвести до проблем зі state?

📌 Питання:

Є список:

{users.map((user, index) => (
  <UserRow key={index} user={user} />
))}

У UserRow є локальний state:

function UserRow({ user }) {
  const [isEditing, setIsEditing] = useState(false);

  return (
    <>
      <span>{user.name}</span>

      <button onClick={() => setIsEditing(true)}>
        Edit
      </button>

      {isEditing && <input />}
    </>
  );
}

Що може статися після видалення або сортування елементів?

📌 Очікувана відповідь:

index — це позиція елемента, а не його стабільна ідентичність.

Наприклад:

До:

Alice Bob Charlie
0     1   2

Після видалення Alice:

Bob Charlie
0   1

React використовує key, щоб зіставляти елементи між render’ами.

Після видалення Alice той самий key={0} уже належить Bob. Для React це означає, що компонент із key 0 залишився тим самим, хоча на рівні наших даних це вже інший користувач.

Через це локальний state компонента може «переїхати» до іншої сутності.

Тому для списків, які можуть змінювати порядок, краще використовувати стабільний ID:

{users.map(user => (
  <UserRow key={user.id} user={user} />
))}

📌 Важливий нюанс:

key — це не просто спосіб прибрати warning у консолі.

Він допомагає React визначати identity елементів між render’ами та правильно пов‘язувати з ними state.

3. Чи завжди useCallback покращує performance?

📌 Питання:

Чи обов’язково тут потрібен useCallback?

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log('click');
  }, []);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>
        {count}
      </button>

      <Child onClick={handleClick} />
    </>
  );
}

const Child = React.memo(function Child({ onClick }) {
  return <button onClick={onClick}>Child</button>;
});

📌 Очікувана відповідь:

Не обов‘язково.

useCallback дозволяє зберігати ту саму function reference між render’ами, доки його dependencies не змінилися.

У цьому прикладі він може бути корисним разом із React.memo: Child отримує ту саму reference handleClick, тому незмінний onClick не змушує memoized-компонент render’итися повторно.

Але якщо стабільна reference функції ні на що не впливає, useCallback може бути просто зайвою memoization.

Тому не варто автоматично додавати:

useCallback(...)
useMemo(...)
React.memo(...)

до кожного компонента.

📌 А що із сучасним React?

У проєктах із React Compiler багато memoization-оптимізацій React може виконувати автоматично.

Це зменшує потребу вручну додавати useCallback, useMemo і React.memo лише заради оптимізації render’ів.

Тому хороша відповідь на рівні senior звучить приблизно так:

«Спочатку я визначаю, чи потрібна тут memoization взагалі. Якщо проєкт використовує React Compiler, значну частину таких оптимізацій він може виконати автоматично. Ручну memoization додаю, коли для цього є конкретна причина».

4. Чому useEffect не потрібен для derived data?

📌 Питання:

Чи правильно написаний цей компонент?

function ProductList({ products }) {
  const [visibleProducts, setVisibleProducts] = useState([]);

  useEffect(() => {
    setVisibleProducts(
      products.filter(product => product.inStock)
    );
  }, [products]);

  return (
    <ul>
      {visibleProducts.map(product => (
        <li key={product.id}>
          {product.name}
        </li>
      ))}
    </ul>
  );
}

📌 Очікувана відповідь:

У цьому випадку useEffect не потрібен.

visibleProducts — це derived data, яку можна отримати безпосередньо з products під час render:

function ProductList({ products }) {
  const visibleProducts = products.filter(
    product => product.inStock
  );

  return (
    <ul>
      {visibleProducts.map(product => (
        <li key={product.id}>
          {product.name}
        </li>
      ))}
    </ul>
  );
}

У першому варіанті ми створюємо зайвий цикл:

render
↓
useEffect
↓
setState
↓
ще один render

Крім того, ми зберігаємо у state значення, яке можна просто отримати з уже наявних props.

📌 Коли useEffect справді потрібен?

Коли потрібно синхронізувати React із зовнішньою системою: наприклад, subscription, timer, DOM API, WebSocket або сторонньою бібліотекою.

Якщо ж derived calculation справді дорогий, тоді можна розглядати memoization — але це не причина переносити derived data у state.

5. Чому компонент може render’итися, навіть якщо його props не змінилися?

📌 Питання:

Чому Child може повторно render’итися при кожному натисканні?

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>
        {count}
      </button>

      <Child name="John" />
    </>
  );
}

function Child({ name }) {
  console.log('Child render');

  return <div>{name}</div>;
}

📌 Очікувана відповідь:

У React без автоматичної memoization, коли Parent render’иться повторно, React за замовчуванням також виконує його дочірні компоненти.

Те, що props Child не змінилися, саме по собі не означає, що React пропустить його render.

Якщо є реальна потреба уникнути такого render, можна використати React.memo:

const Child = React.memo(function Child({ name }) {
  console.log('Child render');

  return <div>{name}</div>;
});

Але тут важливо розуміти reference equality.

Наприклад:

<Child options={{ theme: 'dark' }} />

На кожному render Parent створюється новий object.

Тобто навіть якщо його вміст однаковий:

{ theme: 'dark' } !== { theme: 'dark' }

Це різні object references.

Тому така prop може завадити React.memo пропустити render.

📌 А що з React Compiler?

Якщо проєкт використовує React Compiler, він може автоматично застосовувати memoization і пропускати частину зайвих render’ів без ручного React.memo.

Тому React.memo — не універсальна кнопка «зробити швидше».

Спочатку потрібно зрозуміти, чи є повторний render реальною performance-проблемою і чи не виконує потрібну оптимізацію Compiler.

🍀 Що об'єднує ці питання?

На співбесіді важливо не просто знати API React, а розуміти, чому код поводиться саме так.

Тому вчіть не тільки useEffect, useCallback, useMemo чи React.memo, а й:
JavaScript closures, React render model, state, component identity, Effects та memoization.

Вчіть не відповіді. Вчіть логіку. Удачі!

TikTok | Instagram | Telegram