Хеви металл, который мы заслужили

Теперь ты можешь слушать металл и учить Java.
Итальянцы Nanowar спели код)

Ссылка на ютуб тоже есть
https://www.youtube.com/watch?v=yup8gIXxWDU

P.S. Концовка убила..

Если вдруг у вас сегодня перестала билдиться призма на alpine, посмотрите эту issue https://github.com/nodejs/docker-node/issues/2175

Отрицательные даты

Сегодня была ржакаобоссака у нас в Funlee.
Значит прилетает с утра 3 оплаты за год, мы такие "ура открываем шампанское!"
Тут дизайнер прибегает, "эй, какого х.. вы у меня с карты пытались 27к списать??!!!!1111"
Я такой - "так, подержи мой бокал", начинаю проверять, смотрю аккаунт знакомый, смотрю значит свой телефон, а у меня там успешно списано 27к.

Тут еще бро пишет, "Э брат, вы чо ох..ли там? Почему у меня с карты улетело на ваш сервис 27к?, при том что у меня промокод бессрочный на 99%??!!!".
Ну кароч сделали возвраты, стали разбираться. Поняли, что это вообще оплата за месяц, а не за год :)
Но тесты же, сука, проходят...

Ну я попросил ребят разобраться, но как обычно (был послан на...), пошел разбираться сам.

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

 // Когда заканчивается скидка по промокоду.
      const discountEnds = dayjs(promocode.appliedDate)
        .add(promocode.durationMonths ?? 0, 'months')
        // Добавляем резервный период. Он позволяет менять тарифный план и опции после применения промокода.
        // Если пользователь применил промокод и оплатил тариф, а через день хочет поменять тариф на другой,
        // то без этого периода промокод применён не будет (хотя в теории ещё есть 29 дней).
        .add(promocode.daysLimitForPromoUse ?? 14, 'days');
      const monthsLeft = dayjs(discountEnds).diff(dayjs(now), 'months');

В итоге у нас выходило отрицательное количество месяцев и получалась ох.вшая сумма.

Как жаль, богатство было так близко...

Я вот сегодня заметил, что Codeium стал подсказывать какую то лютую дичь. Ну то есть больше мешать, чем помогать, контекста вообще не понимает железный болванчик. Что посоветуете вместо?

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 #резюмешка