Key в React

Мы привыкли, что key используется только для рендера списков. Но использование key не ограничивается только этим.

Изменение key показывает React что это другой компонент, и необходимо старый размонтировать, а новый замонтировать.

Мы например можем добавить prop key к компоненту формы

<UserForm key={userId} />

Таким образом если userId изменится, то вся форма размонтируется и смонтируется новая форма, и нам не придется обнулять значения формы руками при изменении пользователя.

BEARlogin dev

#react #advices #собеседования

Только я решил сузить тему канала до React\JS\TS, но не могу не поделится этим лайфхаком.
Кароче, когда режете лук, в рот воды наберите, и глаза болеть не будут!
Это какая долбаная магия, но работает!

setState функция в React

Допустим у нас есть какой то state.

const [count, setCount] = useState(0);
return <SomeComponent setCount={setCount} />

Так вот, setCount не нужно оборачивать в useCallback (некоторые так делают) при передаче его как пропс в дочерний компонент.

React гарантирует, что функция setState не изменится между рендерами.

Так же не нужно добавлять ее в зависимости useEffect, useMemo и useCallback.

Если не верите, то добавьте

useEffect(() => {
  console.log('It has changed!!!!! AAAAAaaaa!!!!11111')
},[setCount])

Но если я вдруг ошибаюсь, и кейс мемоизации сетера действительно существует, то напишите в комменты :)

BEARlogin dev

#react #advices #собеседования

SRP как много в этом звуке...

Буква S в SOLID вызвала больше холиваров и разбитых лиц чем React vs {anyFrontendFramework}.

Его классическое определение - Класс должен иметь лишь одну причину для изменений.

Что тут имел в виду Дядя Боб, да хер его знает этих гениев, скажем мы и пойдем дальше пилить таски из жиры.

Но к счастью для нас он уточнил потом в Clean Architecture

Модуль должен отвечать перед одним и только одним актором.

Тоже нихера непонятно, но уже можно размышлять. Что есть актор?

Актор — это кто-то или что-то, кто требует от твоего модуля выполнения задачи.
Это может быть:
- Пользователь, нажимающий на кнопки в интерфейсе.
- Соседний модуль, который вызывает твою функцию.
- Даже система, которая запускает твой код по расписанию.

Каждый актор — это внешний драйвер, который влияет на твою логику.
И вот что важно: модуль должен обслуживать только одного актора.

Понятней не стало?

Ок, приведем пример:

class OrderService {
  createOrder(orderData) {
    // Покупатель создает заказ
  }

  getOrderDetails(orderId) {
    // Покупатель и менеджер получают информацию о заказе
  }

  updateOrderStatus(orderId, status) {
    // Менеджер меняет статус заказа
  }

  cancelOrder(orderId) {
    // Покупатель отменяет заказ
  }
}

Представим, что нам нужно для пользователя добавить возможность указать комментарий к заказу.
Мы идём в OrderService и меняем его.

А теперь нужно дать менеджеру возможность перенести доставку на другую дату.
Мы снова идём в OrderService и меняем его.

И вот тут всё встаёт на свои места. Вот она "причина" для изменений. Это вот этот самый актор — драйвер изменений.
Итог: два актора на один класс. На лицо нарушение принципа SRP.

Что делать?

Разделить сервисы, чтобы они работали только с одним актором.

// Модуль для покупателя
class CustomerOrderService {
  createOrder(orderData) {
    // Логика создания заказа
  }

  getOrderDetails(orderId) {
    // Логика получения деталей заказа для покупателя
  }

  cancelOrder(orderId) {
    // Логика отмены заказа
  }

  createOrder(orderData) {
    // Логика создания заказа для покупателя
  }
}

// Модуль для менеджера
class ManagerOrderService {
  getOrderDetails(orderId) {
    // Логика получения деталей заказа для менеджера
  }

  updateOrderStatus(orderId, status) {
    // Логика изменения статуса заказа
  }

  changeDeliveryDateTime(orderId, dateTime) {
    // Логика изменения доставки
  }

  cancelOrder(orderId) {
    // Логика отмены заказа
  }
}

Надеюсь вы теперь понимаете, насколько глубже был этот принцип, относительно упрощенной, ошибочной интерпретации "Один класс решает одну задачу." распространенной на просторах интернета.
Вспоминается анекдот про "Рабинович напел" :)

SRP не про то, что делает класс, а про причину его изменений. Про, если хотите, заказчика, драйвера этих изменений.

P.S. Вы могли заметить, что для соблюдения SRP нам пришлось дублировать методы. А как же DRY??!!
Я мог бы сказать перефразируя цитату классика

Он нам и нах... не нужон DRY ваш!

Но не буду, и расскрою эту тему в дальнейших постах, так как в архитектуре все зависит от контекста(с).

STAY TUNE)

BEARlogin dev — подпишись!

#архитектура #advices #solid

Чистые и нечистые компоненты в React

Деление на чистые компоненты и нечистые контейнеры — это одна из best practice в React, которая помогает сделать код чище и проще в поддержке.
Но следование этому подходу требует дисциплины от разработчика.

Чистые компоненты
Чистые компоненты делают только одно: отображают данные. Они получают всё через props и не хранят никакого состояния. Это их главная сила — такие компоненты легко переиспользовать и тестировать.

Пример:

function UserCard({ name, age }) {
  return (
    <div>
      <h2>{name}</h2>
      <p>Age: {age}</p>
    </div>
  );
}

UserCard не знает, откуда взялись name и age. Ему должно быть всё равно, как эти данные попали в props. Его задача — просто показать их.

Чистые компоненты не должны:

1. Иметь своего состояния или использовать чужое (useState, useSelector и т.д.).
3. Работать с useEffect или другими хуками, которые создают сайд-эффекты.
4. Хранить бизнес-логику.

Да, из-за этого приходится писать больше кода. Но код становится чище.

Нечистые контейнеры
Нечистые контейнеры — это такие "оркестраторы", которые работают с данными: загружают их, хранят в состоянии и передают чистым компонентам. Они могут содержать сайд-эффекты, такие как запросы к API, диспатчинг действий в redux и т.д.

Пример:

function UserContainer() {
  const user = useSelector(state => state.currentUser);

  return user ? <UserCard name={user.name} age={user.age} /> : <p>Loading...</p>;
}

Контейнер берёт на себя всю грязную работу: он загружает данные и передаёт их в UserCard. А UserCard продолжает оставаться чистым и ничего не знает про состояние или API.

BEARlogin dev — подпишись!

#react #advices #собеседования

Когда используется значение, переданное в createContext?

Многие считают, что если value в провайдере не определен, то используется значение по умолчанию.
Но это не так.

На самом деле значение, переданное в createContext, будет использовано только тогда, когда React не найдёт подходящего провайдера в родителях компонента.

Пример:

// Создаём контекст с "default value" как значением по умолчанию
const MyContext = React.createContext("default value");

function MyContextProvider() {
  // В провайдере используем состояние с изначальным значением undefined
  const [contextValue, setContextValue] = useState(undefined);

  return (
    <MyContext.Provider value={contextValue}>
      <ChildComponent />
      <button onClick={() => setContextValue("updated value")}>
        Update Context
      </button>
    </MyContext.Provider>
  );
}

function ChildComponent() {
  // Используем значение из контекста
  const value = useContext(MyContext);
  return <p>Value from context: {value}</p>;
}

function App() {
  return (
    <>
      <h1>Without Provider</h1>
      <ChildComponent /> {/* value: "default value" */}

      <h1>With Provider</h1>
      <MyContextProvider>
       <ChildComponent />
      </MyContextProvider>
      {/* value: undefined → "updated value" после нажатия кнопки */}
    </>
  );
}

#react #advices #собеседования

Вот кто ставит 👎, вы там покажитесь, комент напишите, или вы на бобину обиделись? 😀 Или это один человек 6 аккаунтов зарегал, сидит ставит?
Прост тема холиварная, понимаю, ну давайте похоливарим.

Не тяните с обращением к врачу.

Я вчера понял, что если кашляешь месяц, то стоит сходить к врачу, а не ждать, что все пройдет само. Даже если температуры нету. Пневмония 🤧

#заболел

Пока я не очень в состоянии писать полноценные посты, буду делиться интересной инфой, что нашел.
Сегодня вот интересная инфа по задержкам https://gist.github.com/jboner/2841832. При этом в комментах есть свой "юмор", типа расчета задержек в бананах 😀

Помогите Паше найти работу

Ребят, бро ищет работу фронтом или фулстеком в React или React+NodeJs в целом по хардам крепкий джун, но при этом хорошо решает бизнес задачи, есть аналитическое мышление.

Кому не сложно, закиньте вашим HR, поможем всем миром, как говориться :)

ЛС Паши @eremenko_pa

#frontend #react #nodejs #nestjs #резюмешка

Зачем нужен useSyncExternalStore

Вопреки расхожему мнению, оно нужно не только для подключения внешних стейт-менеджеров.

Эта штука в целом работает с внешними источниками состояний.

Что такое этот источник состояния? В целом интерфейс евойный состоит из двух трех функций:

1. subsribe - которая используется, чтобы подписаться на изменение чегобытонибыло
2. getSnapshot - которая используется, чтобы получить то самое чтобытонибыло
3. getServerSnapshot - которая используется, чтобы это самое чтобытонибыло на стороне сервере

При ближайшем рассмотрении весьма и весьма полезная штукенция...

Рассмотрим пример с созданием хука для отслеживания изменения ширины окна

//Без  useSyncExternalStore
function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);
}

export default function WindowWidthComponent() {
  const width = useWindowWidth();

  return <div>Ширина окна: {width}px</div>;
}

//Вариант с useSyncExternalStore

import { useSyncExternalStore } from "react";

function useWindowWidth() {
  // Подписка на изменения
  const subscribe = (callback) => {
    window.addEventListener("resize", callback);
    return () => window.removeEventListener("resize", callback);
  };

  // Читаем текущее состояние
  const getSnapshot = () => window.innerWidth;

  return useSyncExternalStore(subscribe, getSnapshot);
}

export default function WindowWidthComponent() {
  const width = useWindowWidth();

  return <div>Ширина окна: {width}px</div>;
}

Или вот восхитительная тема с mediaQuery

import { useSyncExternalStore } from "react";

function useMediaQuery(query) {
  const mediaQuery= window.matchMedia(query);

  const subscribe = (callback) => {
    mediaQuery.addEventListener("change", callback);
    return () => mediaQuery.removeEventListener("change", callback);
  };

  const getSnapshot = () => mediaQuery.matches;

  return useSyncExternalStore(subscribe, getSnapshot);
}

export default function MediaQueryComponent() {
  const isLargeScreen = useMediaQuery("(min-width: 1024px)");

  return (
    <div>
      {isLargeScreen ? "Большой экран" : "Маленький экран"}
    </div>
  );
}

А в чем разница под капотом? Она как суслик, ее не видно, но она есть.

1. Поддержка Concurrent Rendering — гарантирует согласованность состояния даже при приостановке или перезапуске рендера.
2. Мгновенная синхронизация — состояние всегда актуально на момент рендера, без задержек, свойственных setState.
3. Меньше лишних ререндеров — React сравнивает значения из getSnapshot и вызывает рендер только при изменении.
4. Поддержка SSR и гидрации — позволяет задать серверное состояние через getServerSnapshot, устраняя расхождения между сервером и клиентом.

В общем, интересная тема, на мой взгляд, нужно брать!

Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью?
Если необходимо менторство - пишите @bearlogin

BEARlogin dev — подпишись!

#собеседования #react

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

Zustand подписка только на конкретные изменения стора

Если вам нужно подписаться на изменение какой то части стора, то используйте миддлварь subscribeWithSelector

import { create } from "zustand";
import { subscribeWithSelector } from "zustand/middleware";

const useStore = create(
  subscribeWithSelector((set) => ({
    count: 0,
    user: { name: "Alice", age: 25 },
    increment: () => set((state) => ({ count: state.count + 1 })),
  }))
);

// Подписка ТОЛЬКО на `count`
useStore.subscribe(
  (state) => state.count,
  (newCount, prevCount) => {
    console.log(`Счётчик изменился: ${prevCount} → ${newCount}`);
  }
);

Теперь подписка сработает только при изменении count, а изменения user её не триггерят.
--
Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью? Помогу с ростом грейда от миддла до синьора.
Если необходимо менторство - пишите @bearlogin

BEARlogin dev — подпишись!

#react #zustand

Экзитнулся

Вчера я принял решение выйти из стартапа Funlee, которому отдал 2,5 года.

В итоге — дырка от бублика, испорченные отношения с семьей из-за постоянной занятости, бесконечные созвоны. Полное отсутствие заботы о людях, манипуляции в духе "чёрное — это белое", жизнь в режиме ожидания и обещания "вот-вот выстрелит, скоро в тайланде жить будем, порш поедем покупать тебе", игнорирование фактов и всех практик создания и вывода на рынок SaaS продуктов, а главное — полное отрицание фаундерами необходимости платить команде, пока стартап не начнёт генерировать миллионы.

В общем, кушать что то нужно и детей с женой кормить, поэтому выхожу на рынок.

- CTO, технический лидер, тимлид или архитектор. Код писать не стесняюсь и люблю.
- Технологии, языки схватываю быстро
- Рассмотрю и корпоративные компании, и стартапы, но только если фаундеры понимают ценность оплаты труда команды и нет токсичной атмосферы.

📌 Резюме прикрепил, если есть контакты HR — буду благодарен если скинете.

Я теперь могу говорить, что собрал Бинго 8\8 токсичного стартапа. Ну, тоже опыт...

Знаете, сейчас многие пишут: "Блин, а вот вдруг оно выстрелит, а ты не дождался. Не будет обидно?"

Но дело совсем не в этом.
Этот выход — это победа.
Я победил FOMO длиной в 2,5 года.
Это результат полугодовой трансформации.

Еще летом, в июле, я наткнулся на SkillsLab и начал изучать коммуникацию, манипуляции и практики противодействия.
Потом прочитал книгу Никиты Непряхина "Я манипулирую тобой".

И в какой-то момент я УВИДЕЛ.
Как будто шоры спали.
Я прозрел и наконец-то разглядел всю сеть манипуляций, психологического насилия и контроля, которой опутали меня и всю команду.
Это было как в Матрице — как будто принял красную таблетку.

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

"Выгорания не существует. Это просто слабые люди собрались и не смогли дойти на Эверест."

Таков был их ответ.

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

Я наткнулся на пост Айюба, где он рассказывал, что работа с коучем помогла ему прочистить мозг.
До этого я уже искал коуча, но всё время натыкался на каких-то цыган.

Но тут Айюб поделился контактом.
Я написал и пошёл в работу.

Буквально за два занятия я начал приходить в себя.
Я понял, чего я хочу, куда двигаться, с кем работать и кем быть.
Мы разобрали всю ситуацию со стартапом.

И коуч задал мне один вопрос, который всё решил:

Андрей, за сколько ты был бы готов и дальше подвергаться психологическому насилию?

Я задумался и ответил:
"Ну… за миллион долларов в месяц."

Тогда последовал второй вопрос:

То есть ты утверждаешь, что люди имеют право применять психологическое насилие, если платят миллион долларов?

Я задумался. И сказал:
"Нет."

Тогда коуч повторила первый вопрос:

Андрей, за сколько ты был бы готов и дальше подвергаться психологическому насилию?

И в этот момент всё стало ясно.
Я ответил:
"Ни за сколько."

BEARlogin dev — подпишись!

#стартапы #манипуляции

еще один пострадавший