Как я впиливала стейт-менеджер и почему это спасло проект

Это, наверное, мой самый большой Pull Request за всё время работы, и он стал идеальным подтверждением того, что стейт-менеджер может очень сильно упростить жизнь и сократить количество кода.

До этого состояние в проекте хранилось через хуки. Сначала это не вызывало проблем – всё было относительно чисто и понятно. Но со временем непредвиденные изменения в бизнес-логике, помноженные на классическое "Это нужно на проде вчера", превратили код в хаос.

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

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

Итог:
✅ Чистая и предсказуемая структура хранения данных
✅ Упрощённые связи между компонентами
✅ Минимум лишнего кода
✅ Гораздо меньше боли при внесении изменений

Вывод: если проект начинает разрастаться, стейт-менеджер – не просто удобство, а необходимость. Лучше внедрить его заранее, чем потом раскапывать горы запутанного кода.

⚡ Задача дня

В этом коде есть проблема с производительностью.
❓Как можно его оптимизировать?

import React, { useState } from "react";

function App() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState("");

  function increment() {
    setCount(count + 1);
  }

  function handleChange(event) {
    setText(event.target.value);
  }

  function expensiveCalculation(num) {
    console.log("Выполняем тяжелый расчет...");
    return num * 2;
  }

  const result = expensiveCalculation(count);

  return (
    <div>
      <p>Результат: {result}</p>
      <button onClick={increment}>+</button>
      <input type="text" value={text} onChange={handleChange} />
    </div>
  );
}

export default App;

✅ Ответ
expensiveCalculation(count) вызывается при каждом ререндере, даже если count не менялся. Нужно мемоизировать его с помощью useMemo: const result = useMemo(() => expensiveCalculation(count), [count]);.

Если возникли сложности, почитай про useMemo и оптимизацию вычислений здесь:
👉 https://ru.react.dev/reference/react/useMemo

⚡ Задача дня

❓ Какой тип будет у переменной result?

function merge<T, U>(obj1: T, obj2: U): T & U {
  return { ...obj1, ...obj2 };
}

const result = merge({ name: "Анна" }, { age: 25 });

console.log(result);

✅ Ответ
{ name: string; age: number; }

Если возникли трудности, читай про эту тему здесь:
https://www.typenoscriptlang.org/docs/handbook/2/generics.html

Дженерики + объединение типов = мощь! 🚀 Используй и пиши гибкий код! 🔥

⚡ Задача дня

❓ Что выведет консоль?

const words = ["apple", "banana", "cherry"];

const result = words.filter(word => word.length > 5).map(word => word.toUpperCase());

console.log(result);

✅ Ответ
["BANANA", "CHERRY"]

📚 Почитать про filter и map можно здесь:
https://learn.javanoscript.ru/array-methods#filter
https://learn.javanoscript.ru/array-methods#map

Жизненный цикл компонента в React (в классновых и функциональных компонентах)

В современном фронтенде функциональные компоненты уже стали стандартом. Но классовые все еще встречаются, особенно в проектах, начатых несколько лет назад, когда React активно продвигал этот подход. На собеседованиях их часто спрашивают, а также просят объяснить, как аналогичные механизмы реализуются в функциональных компонентах. Давай разберемся в этом вопросе!

Фазы жизненного цикла в классовых компонентах

⚡️Монтирование (Mounting) — когда компонент появляется в DOM

constructor(props)

— вызывается при создании компонента. Здесь можно инициализировать state.

static getDerivedStateFromProps(props, state)

— вызывается перед рендерингом. Позволяет обновлять state на основе props.

render()

— отрисовывает JSX.

componentDidMount()

— вызывается после рендеринга компонента в DOM. Здесь обычно делают запросы к API или подписки.


⚡️Обновление (Updating) — когда компонент обновляется

static getDerivedStateFromProps(props, state)

— вызывается снова при обновлении props.

shouldComponentUpdate(nextProps, nextState)

— позволяет предотвратить ненужный ререндер, возвращая true или false.

render()

— отрисовывает компонент заново.

getSnapshotBeforeUpdate(prevProps, prevState)

— вызывается перед обновлением DOM, позволяет сохранить предыдущее состояние.

componentDidUpdate(prevProps, prevState, snapshot)

— вызывается после обновления компонента, удобно для запросов к API при изменении props.

⚡️ Размонтирование (Unmounting) — когда компонент удаляется из DOM

componentWillUnmount()

— выполняется перед удалением компонента. Используется для очистки таймеров, подписок и т. д.


🚀Жизненный цикл в функциональных компонентах (хуки)

Вместо методов жизненного цикла в функциональных компонентах используют useEffect:

import { useState, useEffect } from "react";

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

  useEffect(() => {
    console.log("Компонент смонтировался 🚀");

    return () => {
      console.log("Компонент размонтировался 💀");
    };
  }, []); // Пустой массив означает, что useEffect сработает только один раз

  return (
    <div>
      <p>Счетчик: {count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </div>
  );
}

useEffect(() => {...}, []) — аналог componentDidMount
useEffect(() => {...}, [deps]) — аналог componentDidUpdate
return () => {...} внутри useEffect — аналог componentWillUnmount

👉Итог
В классовых компонентах используются методы жизненного цикла (componentDidMount, componentDidUpdate, componentWillUnmount).
В функциональных компонентах используют useEffect, который заменяет эти методы.
В новых проектах лучше использовать функциональные компоненты и хуки, так как они проще и удобнее.

Попалась мне интересная статья, и я просто не могу не поделиться ей с тобой.

Сразу скажу, что уважаю эту компанию и её сотрудников за действительно сильные технические скиллы. Вместе с этим, как бывший сотрудник, могу сказать, что выводы в статье кажутся мне весьма занятными.

Расскажи, что думаешь)

https://habr.com/ru/articles/882724/

Советы по прохождению технического интервью в крупнейшие IT-компании (Big Tech):

📍 Подготовься к решению задач на доске: практикуйся в написании кода от руки, чтобы уверенно решать задачи на доске во время интервью.

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

📍 Задавай вопросы: если условия задачи неясны, не стесняйся уточнять детали, показывая своё стремление к точности и пониманию.

📍 Учитывай крайние случаи: обращай внимание на возможные исключения и нестандартные ситуации, чтобы продемонстрировать глубокое понимание проблемы.

📍 Тестируй свой код: после написания решения проверь его на наличие ошибок и убедись в правильности работы.

📍 Будь готов к вопросам по резюме: ожидай обсуждения проектов и опыта, указанных в твоём резюме, и будь готов подробно о них рассказать.

📍 Практикуй поведенческие вопросы: подготовь примеры из прошлого опыта, демонстрирующие твои навыки командной работы, преодоления трудностей и адаптивности.

📍 Проявляй энтузиазм и интерес: покажи искреннюю заинтересованность в позиции и компании, что подчеркнёт твою мотивацию. 🚀

Копаоник (Сербия)

.road {
opacity: 0.4
}

Мой мини-отпуск подошел к концу и я врываюсь в рабочие будни с новым видео про алгоритмы!

https://youtu.be/nWRl0gnx0gY?si=spYQ6u4L9FRaxZup

⚡ Задача дня

❓ Что выведет консоль?

const arr = [10, 20, 30];

const a = arr.push(40);
const b = arr.pop();
const c = arr.unshift(5);
const d = arr.shift();

console.log(a, b, c, d);

✅ Ответ
4 40 4 5

📚 Почитать про push, pop, shift, unshift можно здесь:
https://learn.javanoscript.ru/array-methods#push-pop-shift-unshift

#javanoscript #frontend #фронтендсобеседования

При решении алгоритмических задач нам часто нужно перебирать массив. Давай разберёмся, чем отличаются for, forEach и for...of, и в каких случаях каждый из них удобнее. 🔍


1️⃣ for
Классический способ перебора массива, подходит для случаев, когда нужен полный контроль над итерацией: досрочный выход (break, return) или переход к следующей итерации (continue).

const nums = [1, 2, 3, 4, 5];

for (let i = 0; i < nums.length; i++) {
  if (nums[i] === 3) continue; // Пропускаем число 3
  if (nums[i] === 4) break; // Останавливаем цикл
  console.log(nums[i]); 
}
// Выведет: 1, 2

✅ Позволяет управлять индексом.
✅ Можно использовать break, continue, return.
❌ Код получается более громоздким.


2️⃣ for...of
Современный способ перебора итерируемых объектов, включая массивы. Читается проще, чем for, позволяет break, continue и return.

const nums = [1, 2, 3, 4, 5];

for (let num of nums) {
  if (num === 3) continue; // Пропускаем 3
  if (num === 4) break; // Останавливаем цикл
  console.log(num);
}
// Выведет: 1, 2

✅ Простой и лаконичный синтаксис.
✅ Работает с break, continue, return.
✅ Подходит для работы с Set, Map, arguments и другими итерируемыми объектами.
❌ Нет доступа к индексу элемента (если нужен индекс, можно использовать .entries()).

for (let [index, num] of nums.entries()) {
  console.log(index, num);
}
// Выведет: 0 1, 1 2, 2 3, 3 4, 4 5

3️⃣ forEach
Метод массива, удобный для перебора элементов. Не прерывается с помощью break, continue или return.

const nums = [1, 2, 3, 4, 5];

nums.forEach((num, index, arr) => {
  if (num === 3) return; // НЕ ОСТАНОВИТ ВЕСЬ ЦИКЛ! Только текущую итерацию
  console.log(num);
});
// Выведет: 1, 2, 4, 5

✅ Упрощает работу с массивом, не надо следить за индексом.
✅ Лаконичный код.
❌ Нельзя выйти (break или return не остановят forEach).


📌 Вывод:
for – лучший выбор, если нужен индекс или возможность прервать цикл.
forEach – удобен для чистых переборов, но без возможности остановки.
for...of – читабельный вариант, если не нужен индекс.
👉 Что использовать – зависит от задачи! 🚀

Друзья, сняла для вас ролик про основные ошибки джуниор-разработчиков, которые мешают расти в профессии. Затронула противоречивые темы и постаралась рассмотреть некоторые пункты с разных сторон. Делитесь в комментариях: какие ошибки допускали вы, и как вам удалось с ними справиться?
https://youtu.be/-htWGDRyv1Y?si=mWVNWdx0nXdOseJI

#Frontend #ДжуниорРазработчик #ОшибкиРазработчиков #ITкарьера #Программирование