⚛️ React 19 — use(Promise)

use — новый хук, который позволяет считывать данные из промиса и при этом интегрирован с Suspense и ErrorBoundary.

ℹ️ Основные моменты:

- На этот хук не распространяются правила хуков — его можно использовать внутри циклов и условных операторов.
- Если мы используем хук use(Promise), то где-то в родительском компоненте мы должны положить сам промис (не данные как мы делали раньше) в стейт (useState). Это позволяет избавиться от useEffect’а, который был нужен, чтобы запросить данные при первом рендере.
- Хук интегрирован с Suspense, поэтому пока промис не разрезолвится — будет показан fallback объявленный в ближайшем Suspense.
- Если промис зареджектился, то будет показан fallback объявленный в ближайшем ErrorBoundary

- Песочница тут
- Официальная документация тут

#frontend #react #new

⚛️ React 19 — useOptimistic

useOptimistic — новый хук, который позволяет отобразить “оптимистичное” состояние. Оно называется “оптимистичным”, потому что мы “оптимистично” надеемся, что наш запрос не свалится с ошибкой и после выполнения запроса состояние будет выглядеть именно так.

❓Как используется

- В useOptimistic передаётся реальное состояние (cart) и функцию-reducer, для обновления оптимистичного состояния
- Компонент (Cart) использует “оптимистичное” состояние (optimisticCart) для рендера
- Перед выполнением запроса обновляется “оптимистичное” состояние
- Когда запрос завершился, нужно обновить реальное состояние
- Как только реальное состояние обновилось, оптимистичное состояние обновится автоматически, так как оно передано в useOptimistic первым параметром. ⚠️ Поэтому важно следить, чтобы приходило одно и то же состояние.
- Если запрос упал с ошибкой, нужно откатить изменения в оптимистичном состоянии.

ℹ️ Первый вопрос, которым я задался, а в чём отличие от обычного setState, путём экспериментов, вот что удалось найти:

- useOptimistic работает с формами. Работать с обычной кнопкой в Single Page Application мне не удалось, обновление происходило только после завершения запроса
- useOptimistic работает только внутри асинхронного обработчика, что логично. Если убрать async/await, обновление произойдёт только после завершения запроса
- Параметр в useState используется только для инициализации, и игнорируется в последующих рендерах. useOptimistic будет сихронизироваться со значением переданным первым параметром.

🤷‍♂️ Очень мало полезного удалось найти о useOptimistic. Во всех статьях и видео тривиальные примеры, нигде не рассказывается как обрабатывать более сложные ситуации:

- Как обновлять оптимистичное состояние, если запустить несколько запросов одновременно?
- Как использовать useOptimistic в SPA вне форм?

Поэтому пришлось создать пару ишью: раз и два. В любом случае, пока useOptimistic выглядит каким-то низкоуровневым API. Надеюсь скоро появится больше Best Practices по его применению. Если вам есть что добавить — пишите в комментах.

Ещё по теме:

- Frontend First — Ep 179 - React Deep Dive: useOptimistic
- Официальная документация по useOptimistic
- Код из примера тут

#react #frontend #new

Максимальная длина строки в V8

У меня есть небольшой пет проект, для построения различных графиков для пул реквестов, которые показывают кто кому оставляет комментарии, ставит аппрувы и прочее. Бэкенда там нет, фронт ходит в Gitlab или Gitea, выкачивает информацию за указанный период времени и рисует графики.

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

JSON.stringify Uncaught RangeError: Invalid string length

Немного погуглив, нашёл, что длина строки в V8:
- 268.4 мегабайт на 32-битных платформах
- 538.8 мегабайт на 64-битных платформах (на М1 похоже такая же)

✅ Решил проблему просто: при экспорте разбиваю мой большой массив, на несколько частей и экспортирую несколько файлов.

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

const reader = new FileReader();
reader.onload = function () {
 console.log(reader.result); // result будет пустой строкой
}
reader.readAsText(file);

В Firefox такой проблемы нет, всё работает.

#browser #frontend

#рекомендую_канал

Сегодня решил начать делиться каналами, которые читаю сам, возможно когда-нибудь даже опубликую ссылку на папку с каналами 🤔 , но это не сегодня …

Возможно вы уже знаете Даниэля по его сообществу Фронт.ру, он достаточно молод, и уже успел поработать фронтендером в Сбере и Яндекс Поиске. Даниэль пишет интересно и не только о коде, но и о том как работается в самой компании. Возможно, как-нибудь и я решусь написать пару постов о своей работе 😄.

В этих постах можете познакомиться с тем как проходят первые дни в Яндексе:

- Прошел первый день в офисе Яндекса
- Сегодня было парное программирование
- Моя первая таска в проде
- Как проходили собеседования в Яндекс?
- Сегодня ровно месяц как работаю в Яндекс.
- Закончился мой испытательный срок в Яндексе.

Кстати, сегодня ровно год блогу Даниэля а завтра, год как он работает в Яндексе, поэтому давайте поздравим его подпиской на его канал 🎂.

@cherkashindev

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

- https://chat.openai.com/ — представления не требует
- https://www.phind.com/ — о phind писал здесь
- https://gemini.google.com/app - AI чат бот от гугла, работает только через VPN
- https://ya.ru/alisa_davay_pridumaem — чат бот от Яндекса
- https://300.ya.ru/ — краткий пересказ, статей и видео от Яндекса
- https://news.1rj.ru/str/gigachat_bot — чат бот от Сбера

В Сбере заморочились и реализовали расширение по типу Codeium (о нём писал здесь) для VS Code и IDE от JetBrains. Скорее всего это связано с запуском ими аналога Github — Gitverse, и альтернативы Copilot — Gigacode. Инструкция по установке здесь.

А какими AI ботами или другими сервисами пользуетесь вы?

#ai

🗣 Фраза недели — “Да надо”

В честь первого апреля расскажу вам одну историю.

📖 Несколько лет назад во время пандемии скучными вечерами, покуривая кальян, я читал книгу “Программист Прагматик”. Обсуждать всю книгу я конечно же не буду, остановлюсь лишь на одной теме, которая задела меня за живое. Автор описывал, что лишь одна фраза может внести полнейший хаос в работу и взаимопонимание коллектива — фраза “мы должны” также известная как “нам надо”.

Простой пример: на очередном митинге кто-то невзначай произносит “мы должны что-то сделать, чтобы эта страница загружалась за 2 секунды”. После этого митинг продолжается, затем заканчивается, но вам всё ещё непонятно, а кто мы? Кто именно должен это сделать?

ℹ️ Вот чтобы такого не было, нужно использовать более конкретные и четкие формулировки, которые ясно указывают на ответственность за выполнение задачи. Например, вместо того чтобы говорить "мы должны ускорить загрузку страницы", лучше сказать "Черкашин, тебе нужно ускорить загрузки страницы в следующем спринте".

👨 Не думаю, что мой батя читал эту книгу тайком, пока я кодил, но он сумел превратить недостатки фразы “нам надо” в достоинства. Родители живут в частном доме, и каждый год моя мама говорит отцу “Ваня, отделай крыльцо плиткой”, а он говорит “Да надо” (что означает, делать этого я конечно же не буду), и так уже года 4. Верх дипломатии, вроде и не отказался, но ответственность размыл, сроки тоже туманные.

Я как истинный сын своего отца, теперь всегда поддерживаю своего тимлида. Если он говорит “Нам нужно …” или “Мы должны”, я отвечаю ему “Да, надо”, в итоге никто этими предложениями не занимается 😄. Это стало своего рода мемом в команде.

👉 В общем, будьте конкретны в своих предложениях. И ставьте лайки для бати — если пост наберёт 20 лайков батя сделает крыльцо в этом году (но это не точно).

#weekphrase #meme

Сегодня я вам принёс важную статью “Решение, которое нужно принять, чтобы не жалеть о жизни через 30 лет”. Важная — потому что она не о программировании, а о нашей с вами жизни в целом. В статье рассказывается как стоит жить сейчас, чтобы на смертном одре не пожалеть о прожитом.

⚠️ Главная проблема, о которой говорит автор, заключается в том, что мы гонимся за краткосрочными успехами, которые дают быстрый результат, что позволяет нам почувствовать собственную значимость. В погоне за этим “лёгким дофамином” мы забываем думать о будущем и строить планы, чтобы добиться того, чего мы действительно хотим. Так мы отдаляемся от того, о чём действительно мечтаем.

ℹ️ За примерами далеко ходить не нужно:

- Люди не хотят быть одиноки, но уделяют работе всё своё время, забывая о семье, из-за чего семьи разваливаются
- Не хотят умирать “преждевременно” — но выбирают пиво с чипсами, вместо ЗОЖ
- Не хотят быть безработными или бедными — но смотрят очередную серию сериала, вместо обучения
- Не хотят быть глупыми — но не уделяют времени чтению
- Не планируют жить в постоянном нервном напряжении — но игры и отдых кажутся пустой тратой времени

✅ Чтобы перестать думать в краткосрочной перспективе и научиться видеть долгосрочную нужно понять ключевой принцип “перспективных занятий”. Перспективные занятия — занятия, которые окупаются в долгосрочной перспективе, но не всегда в краткосрочной.

🧠 Автор статьи советует уделять 10 часов в неделю “перспективным занятиям”. Однако это не так-то просто, ведь чтобы увидеть результаты, потребуется много времени и возможно даже не один год. Лучший способ найти время для перспективных занятий — сделать выделяемые им часы неприкосновенными и ввести их в привычку.

#fridayreading

@cherkashindev

XOR — исключающее или

Пару раз в год в нашем C# коде я встречаю оператор ^ и впадаю в ступор 🤦‍♂️. Через минуту другую я вспоминаю, что оператор называется “исключающее или” или XOR. Потом, проходит ещё пара минут (на самом деле больше) и я вспоминаю, как он работает и для чего применяется. Поэтому сегодня я решил написать пост, чтобы моим преподавателям не было стыдно запомнить этот оператор раз и навсегда.

1️⃣ Как работаете XOR?

Тут всё просто XOR - это сравнение, если A и B равны, то получаем 0, если разные 1

| A | B | A XOR B |
|---|---|---------|
| 0 | 0 |    0    |
| 0 | 1 |    1    |
| 1 | 0 |    1    |
| 1 | 1 |    0    |

2️⃣ Перечисления — Битовые флаги

Каждое значение, представляет собой степень двойки (один бит), что помогает удобно хранить и передавать несколько значений.

[Flags]
enum Permissions
{
    None = 0,                    // 000
    Read = 1,                    // 001
    Write = 2,                   // 010
    Execute = 4                  // 100
    All = Read | Write | Execute // 111 
}

3️⃣ Применение XOR с битовыми флагами:

Оператор XOR часто используется для добавления и удаления определенных битовых флагов.

Permissions myPermissions = Permissions.Read | Permissions.Execute;

// Добавление прав на запись
myPermissions ^= Permissions.Write;   // 101 ^ 010 = 111

// Удаление прав на выполнение
myPermissions ^= Permissions.Execute; // 111 ^ 100 = 011 

#essential #csharp

@cherkashindev

Время ожидания — это «процент занятого времени», разделённый на «процент свободного»

Это фраза из книги Проект «Феникс»”

📖 Вот небольшой отрывок:

Время ожидания — это «процент занятого времени», разделённый на «процент свободного».

Другими словами, если ресурс загружен на пятьдесят процентов, то он на пятьдесят процентов свободен. Время ожидания равняется пятидесяти процентам, разделённым на пятьдесят процентов, то есть единица времени. Назовём её, например, один час.

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

Другими словами, наше задание будет ждать в очереди в девять раз дольше чем в том случае, когда ресурс свободен на пятьдесят процентов.

В случае с заданием для «Феникса», у нас есть семь инстанций, в каждой из которых сотрудники заняты на девяносто процентов. В таком случае наше задание будет ждать в очереди перед каждым из семи шагов по девять часов…

🙀 Шестьдесят три часа — только время ожидания в очереди.

👆Из этого графика следует, что всем нужно свободное время, время «холостого хода».

-----------

⚠️ Если все в команде заняты высокоприоритетными делами и не имеют ни секунды свободного времени, то общее время разработки увеличивается:

- не будет времени помочь коллеге
- некогда будет сделать код ревью
- на документацию тоже не будет времени

всё это увеличивает время разработки. А помимо этого, всегда возникает «незапланированная работа» в виде багов и хот фиксов.

#weekphrase #planning

​​Полиморфизм

Полиморфизм в программировании — это способность объектов принимать множество форм. Это означает, что один и тот же код может работать с разными типами данных.

Пример 1️⃣

Допустим, мы пишем графический редактор, и нам нужно добавить возможность экспортировать элементы в noscript формате (как в excalidraw.com). Напишем метод, который экспортирует массив выделенных элементов в SVG:

interface ISvgItem {
  toSvg(): string;
}

function exportToSvg(items: ISvgItem[]) {
 return `<noscript>${items.map(noscript => noscript.toSvg()).join('')}</noscript>`;
}

В данном случае, тот самый объект, который можем принимать множество форм — параметр `items`, так как в этом массиве могут находиться элементы разных типов. Единственное условие — все они должны реализовывать интерфейс ISvgItem.

Реализуем парочку таких типов: круг и квадрат.

class Square implements ISvgItem {
    constructor(public side: number, public x: number, public y: number) {
    }
    toSvg(): string {
     return `<rect 
         x="${this.x}" 
         y="${this.y}" 
         width="${this.side}" 
         height="${this.side}" 
      />`;
    }
}

class Circle implements ISvgItem {
    constructor(public radius: number, public x: number, public y: number) { }

    toSvg(): string {
        return `<circle x="${this.x}" y="${this.y}" r="${this.radius}" />`;
    }
}

Наш метод exportToSvg может работать с экземплярами обоих классов:

exportToSvg([
 new Square(40, 10, 10),
  new Circle(25, 10, 15),
])

В этом примере, когда код работает с объектами, он не знает точно, какой объект будет передан в качестве параметра. Но он точно знает, что у объекта будет метод toSvg(), это и есть полиморфизм.

Пример 2️⃣

Ваше приложение может работать как с PostgreSQL, так и с MSSQL, всё зависит от конфигурации, которую задал пользователь.

В таком случае мы выделяем абстракцию (абстрактный класс или интерфейс) DataBaseConnection, и всё приложение работает именно с этой абстракцией, а не с конкретной реализацией.

В таком случае создаваться DataBaseConnection скорее всего будет с помощью паттерна “фабрика”, но об этом как-нибудь в другой раз.

📌 Я бы сказал, что полиморфизм — это логическое продолжение абстракции, без которого невозможно было бы реализовать большинство паттернов проектирования.

#essential #oop

🗨️ Скорость отдельно взятого разработчика важна, но она не так важна, как скорость всей команды.

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

https://google.github.io/eng-practices/review/reviewer/speed.html

#codereview #weekphrase

Вот вам наглядное представление как выглядит закомментированный код - как этот "закомментированный" дорожный знак 😁.

Ну и вдогонку анекдот от ChatGPT в стиле советских анекдотов:

— Товарищи программисты, почему закомментированный код всегда остаётся закомментированным?
— Потому что он как легендарная пятилетка - всегда в планах, но никогда не реализуется!

#meme

Несмотря на то, что с балетом у меня натянутые отношения (предыдущие пару раз я еле досидел до конца и грозился, чтобы я ещё раз?!), жена уговорила меня поехать в Москву в Большой театр на Лебединое озеро.

Но я решил, что хорошо должно быть не только ей, но и мне. И я отправился в Москву на день раньше и посетить конференцию Teamly по управлению знаниями.

Если кто-то не знает — Teamly, это 🇷🇺 российский аналог Notion и Confluence. Каждые пол года компания организовывает бесплатную конференцию, где рассказывает о новой версии продукта и о важности управления знаниями в целом. Конференция была на уровне, что в принципе видно по качеству записи трансляции.

ℹ️ Вот некоторые тезисы, из докладов спикеров:

- Чем больше компания — тем больше пользы от системы управления знаниями.
- Если в вашей компании много департаментов — внедрение можно начать с «департаментов-энтузиастов», которые любят внедрять что-то новое. Так будет легче начать внедрение.
- Проект нужно разрабатывать не с конца, а с начала. Например, сначала следует убедиться, что вы можете получить данные для системы, до того как приступить к её разработке. Иначе вы рискуете потратить много времени, денег и сил.
- Всем нам сложно делиться своими провалами, поэтому важно в компании выстраивать культуру так, чтобы сотрудники могли безболезненно о них говорить. Тут поможет встреча Fails nights, на которой, например, раз в квартал сотрудники могут рассказать о своих факапах, а остальные бы могли учиться на чужих ошибках. Подробнее в статье Miro.
- Если благодаря работе у сотрудников закрываются их потребности, например, они выступают на внутренних митапах или делятся знаниями, то они более лояльны компании и не захотят уходить к конкурентам.
- В Teamly можно реализовать поиск сотрудника по компетенциям. У каждого сотрудника есть личная страница, на ней указываются навыки, а система позволяет искать по этим навыкам. Например, если вам нужен эксперт по Google Sheets и MongoDB, то вы можете легко его найти. Основное преимущество в том, что вся информация хранится в одном месте. Буквально на прошлой неделе в нашей компании решили составить подобный список в Google Sheets, и я уверен, со временем он потеряется и никто его не найдёт.

🔥 Отдельного внимания заслуживает Гарретт Джонстон, его выступление рекомендую посмотреть полностью. Оно может показаться своеобразным, но внимания точно заслуживает.

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

🔍 Например, рыболовный магазин с продавцами знающими своё дело и качественными удочками и снастями — клиентоориентированный бизнес. А если сюда добавить — индивидуальный подбор снастей, выбор локации для рыбной ловли и обучение рыболовству — то бизнес станет клиентоцентричным. Иными словами такой бизнес будет создавать рыболовов, что будет приносить ему больше денег.

P.S.
От балета удовольствия я особо не получил, а обзор новых функций Teamly вы можете посмотреть здесь.

#conference #teamly

📖 Cohesion и Coupling: отличия

Сегодня посоветую короткую статью, чтобы наконец-то разобраться что есть что.

🛑 Основные моменты

- Нужно стремиться к достижению low coupling (низкой связанности) и high cohesion (высокого сцепления)
- Cohesion — степень, в которой часть кодовой базы образует логически единую атомарную единицу — блок.
- Coupling — степень взаимосвязи между этими блоками.
- Блок здесь необязательно является классом. Это может быть метод, класс, группа классов или даже модуль: понятия cohesion и coupling применимы на разных уровнях.
- Высокий cohesion означает хранение связанных друг с другом частей кода в одном месте.
- Например, мы храним код работы с пользователями в одном месте, и это может быть как стандартный MVC контроллер, так и отдельный микросервис.
- В то же время низкий coupling заключается в максимально возможном разделении несвязанных частей кодовой базы.
- Например, react и react-dom хранятся в разных пакетах, благодаря чему мы можем использовать react-native вместо react-dom и писать нативные приложения.
- В отличие от такого показателя, как цикломатическая сложность, степень cohesion  и coupling не может быть измерена напрямую.


ℹ️ Понятие cohesion похоже на Принцип единственной ответственности, который утверждает, что у класса должна быть одна ответственность, что аналогично тому, что делает код с высоким cohesion. Разница здесь в том, что высокий cohesion необязательно означает, что код должен иметь только одну ответственность. Можно сказать, что Принцип единственной ответственности в этом смысле более строгий.

#essential #fridayreading