Ответ на пост «Маг из мира фронтенда»
На самом деле чтобы заблокировать блокировщик адблока достаточно зайти в настройки и отключть на сайте жабаскрипт. Ну правда сайт при этом может немного поломаться, но статью свою ты прочитаешь.
На самом деле чтобы заблокировать блокировщик адблока достаточно зайти в настройки и отключть на сайте жабаскрипт. Ну правда сайт при этом может немного поломаться, но статью свою ты прочитаешь.
Использование контекста реакта и хуков, упрощает управление состоянием приложения. В небольших проектах уж и вовсе позволяет отказаться от использования менеджеров состояний. Но у него есть ряд проблем, о которых необходимо знать.
1️⃣ Дизайн по умолчанию, не совсем безопасен.
1. Логика хранения стейта и его изменения разбросана между контекстом и использующими его компонентами
2. Значение value контекста необходимо мемоизировать с помощью useMemo
3. Если компонент, не нашёл контекст в родительских узлах — он будет молча использовать значения по-умолчанию. Мы не увидим никаких предупреждений или ошибок
Эти проблемы и их решения рассматривается в статье React: How I learned to create optimized contexts
✅ Вместо использования контекста напрямую, нужно:
- Указать null в качестве значения по-умолчанию для контекста
- Реализовать useSafeContext — кастомный хук, который будет проверять, что значение не null
- Реализовать SafeContext — компонент, который содержит логику инициализации значения реакт контекста
2️⃣ Отсутствие атомарных обновлений — компоненты или хуки, которые используют контекст, перерендеривается каждый раз, когда контекст изменяет состояние. Даже если ваш компонент использует лишь одной свойство из контекста, которое никогда не изменяется — компонент будет перерендериваться при изменении любого другого свойства в контексте.
✅ Как решить проблему?
- Не класть всё в один большой контекст, а разбить его на несколько маленьких
- Использовать библиотеку для управления состоянием, например, zustand
- Минимизировать использование контекста. Например, можно использовать контекст в родительском компоненте, а дочерним передать нужные значения через пропсы.
Проблемы и решения описаны в статье The Problem with React's Context API (тут перевод на русский).
Сегодня порекомендую статью о структуре фронтенд проектов на основе вертикальных слайсов.
Автор начинает рассказ с описания структур первых проектов, где использовался подход “Разделения по техническим слоям”, в котором мы группируем файлы по функциональности, а не по доменной области:
- api/services
- components
- stores
- constants
- и т.д.
и затем описывается, как этот подход всё ещё используется внутри “вертикальных слайсов”.
Разделение по техническим слоям
✅ Плюсы подхода
- хорошо работает для маленьких проектов
- у слоев есть однонаправленный поток использования, и нельзя импортировать файлы из слоев, находящихся на уровне выше (например сторы могут использовать api, а страницы могут использовать базовые компоненты, но не наоборот).
❌ Проблемы подхода
- Даже для небольших продуктовых фичей приходится править код по всему проекту, так как он раскидан по разным папкам
- Неявные связи в рамках конкретных слоев: бизнес компоненты (ProductCard, UserProfile) смешиваются c UI компонентами (Link, Button) в components, то же самое касается бизнес логики
«Vertical sliced» подход
Подход подразумевает, что архитектура строится не вокруг технических слоев, а поверх конкретных слайсов проекта.
По сути, мы берём структуру “разделения по техническим слоям” и делаем разрез по фичам. То есть, создаём папку для каждой фичи, внутри которой все файлы относятся только к этой фиче и “разделены по техническим слоям”.
ℹ️ Описание папок
- shared - тут хранятся всё, что можно переиспользовать и не зависит от определённой бизнес фичи. Например в shared/components будут лежать, обычные кнопки, радио кнопки и прочее
- domain - базовый UI для бизнес-сущностей (домена) проекта, например карточка товара. Простая аналогия (но не совсем правильная) - в домене можно хранить все то, что хранится в базе данных на бекенде.
- features - самодостаточные компоненты — большие бизнес сущности приложения, например корзина. Для реализации фичи, скорее всего будет использоваться несколько компонентов из доменной области.
- pages - страницы приложения.
✅ Плюсы подхода
- Когда необходимо внести изменения в фичу — все изменения происходят внутри одного слайса.
- На выходе получаем высокое зацепление (high cohesion) внутри слайса и низкую связанность (low coupling) между разными слайсами
- Сохраняется правило однонапревленного использвания: pages ⇒ features ⇒ domain ⇒ shared
- Фичи не могут напрямую использовать друг друга
- На самом нижнем уровне используется “разделение по техническим слоям”
Чтобы обеспечить однонаправленный поток использования можно взять eslint c плагином import/no-restricted-paths.
После того как прошел "курс" на ютубе по HTML
Здравствуйте, уважаемые Гигачады-программисты с зп в 300к/наносекунду и прочие биороботы запрограммированные на успешный успех "с пелёнок".
Вот уже как 3 месяца поверив в себя я решил что достоин поучаствовать в грандиозной королевской битве "Войти в айти" где на 1 вакансию на HH может быть 1к+ откликов.
Получил очередную дозу негатива от попыток в учебы по HTML/CSS/JS (на самом деле не серьёзную дозу, но систематическую) когда пытался сделать имитацию pet проекта который я бы потом залил на GitHub (короче просто повторял за учителем с ютуба) что бы иметь на 0.001% шанса больше при просмотре "портфолио".
и что-то загрустил...
Полез смотреть какой вообще стэк технологий нужно конкретно знать junior frontend developer, какую зп он получает на старте (я понимаю что зп там растет по экспоненте, но все же тяжело морально осознавать что чек у тебя будет как у кассирши с местного магнита и при этом наверняка будут переработки)
Но самое добивающее для меня (крипа )было это осознать насколько этот ваш сектор IT перегрет. Перед созданием поста я прошелся по куче разным форумам где люди делятся с проблемой трудоустройства даже после освоение всего нужного стэка технологий что бы иметь микрошанс на рассмотрение резюме HR-ом. Люди по полгода ищут работу, буквально, и не могут её найти и это крайне сильно удручает.
Да, 100% сейчас полетят аргументы что это самая трудная часть, но потом сразу после того как ты становишься мидллом с 3-х летним коммерческим опытом, то твой член вырастает на 10 см, чсв будет затмевать Эверест, а на зп за год ты можешь купить квартирку где-нибудь в области. Но до этого этапа супер-чемпионов генетически совершенных высших организмов нужно еще каким-то образом добраться.
Лично я еще далеко не на стадии "готов начать проходить собеседования" , у меня есть конкретные проблемы с навигацией по учебному материалу ( не знаю как и где учиться "правильно" и по порядку), но есть надежда на бесплатную школу The Rolling scope курс которой стартует через полтора месяца.
Тем не менее, уже сейчас подумываю о том что бы попытаться реализовать себя где-нибудь еще (но точно не за кассой или со специалистами таскать ящики за 30к в своем Зажопинске)
Пытался до этого зарабатывать денюшки на Upwork делая видосики забугорным Джонам( даже 60$ смог заработать), но на поиск 1 нормального заказа может спокойно уйти не 1-2 дня, и это меня сильно напрягало и все за небольшой прайс (спасибо индусам за демпинг). Да и с выводом денег большие проблемы (я так понял единственный рабочий вариант находясь в Необъятной это выводить на Райф с комиссией 30$ + 500р. за каждый вывод)
Да, я понимаю что это робкие потуги слабака напрячь немногочисленные умственные способности что бы выдать такой "weak-speech" в стиле омежки, но вот такие карты я имею на руках и хочу услышать от людей которые "смогли" стать козырными тузами которые ехидно посмеиваться над такими 15-сортными унтереми типо меня. Или просто мудрых и опытных людей которые не прочь поделиться своим взглядом на мою проблему. Создав этот пост я понимаю что в меня полетит много дизов и осуждения, но лично я (хоть и наивно) надеюсь услышать какую-нибудь светлую мысль/идею/и что-нибудь подобное в надежде что в моём примитивном разуме наконец таки сложится паззл который запустит алгоритм по реализации себя и изгнанию апатии и самобичеванию. Многого прошу, понимаю, но надеюсь мисс Фортуна пошлёт мне воздушный поцелуй и что-то подобное случится.
За кассу и прочую подобную работу я браться ПРЯМ КАТЕГОРИЧЕСКИ НЕ ХОЧУ!! Это забагованный daily quest который ты проходишь ради возможности пройти его ещё раз! (на зп с него невозможно построить хоть сколько ощутимую прогрессию себя как персонажа).
Возможно как экстремальный вариант на 1 месяц, и то я скорее всего вернусь на kwork делать плашки для 1xчлен за 350р в день. Я готов "пахать", но организм просто не даёт энергии на это когда не видит смысла, а ему очень не привлекательны столь туманные перспективы "убить" еще годик что бы иметь небольшой шанс вырвать какую-нибудь галеру у 1000 подобных себе "вайтишников".
Скорее всего мои "умозаключения" покажутся кому-то где-то нелогичными/излишне инфантильными и прочее, я лишь попытался создать общий портрет своей проблемы. Блин мужики, ну реально уже башка лагать начинает.
P.S.
У меня уже конкретные беды с бошкой из-за отсутствия самореализации, 25 годиков до сих пор с родителями и уже год прошел с тех пор как я без работы + весь денежный запас иссяк и нет денег даже что бы оплатить последний семестр.
Стараюсь заниматься спортом (дома есть инвентарь для этого + груша), смотреть позитивные + мотивирующие видосики, но по ощущением уже давно превратился в негативным сгусток энергии (пытаюсь сублимировать этот негатив в топливо для учёбы), пересрался со всеми друзьями в том числе с друганом который "смог" и зарабатываем 1кк драм в Армении работая по 4-6 часов дома удаленно, он то меня и мотивировал своим примером.
Мысли о Роскомнадзоре лезут постоянно, я уже устал их скипать (потому что я трус и знаю что я никогда не решусь), а мысли пойти стать удобрением где-нибудь под Бахмутом кажутся мне более привлекательными чем существовать на зп в 35-40к 5/2, просыпаться и ненавидеть каждый день, общаться с людьми которых ты не хочешь видеть и заниматься рутинной однотипной работой которая окончательно превратит мозг в жижу и так до самой смерти... Зачем уж тянуть?((
Как я упомянул в посте о Zustand, мы начали его использовать в июне 2021 года.
До этого использовали просто useState/useReducer/useContext, поняли что так больше нельзя, и перед разработкой новой большой фичи мы начали искать подходящий менеджер состояний. У нас были следующие требования:
1. Использование состояния между компонентами, у которых нет общего родительского компонента. Мы мигрируем с JQuery на React, поэтому большинство компонентов рендерятся с помощью createRoot и не имеют общего родителя, что не позволяет использовать контекст реакта и совместно использовать состояние между компонентами
2. Атомарные обновления, чего нет у контекста реакта
3. Поддержка асинхронных обновлений стейта вне компонента. Чтобы избегать ошибок типа Can't perform a React state update on an unmounted component, которые происходят, когда обновляется состояние для уже удалённого компонента
4. Поддержка Computed Properties
5. Поддержка TypeScript
6. Тестируемость
7. Маленький размер бандла
8. Англоязычное комьюнити, потому что команда англоязычная
И следующий 2 требования я выделю отдельно:
1. Простота использования. Очень важно, когда у вас разработчики со всех концов света и скилы у всех разные. К тому же, очень просто наговнокодить, когда вы начинаете использовать новый инструмент.
2. Возможность использовать вне реакта. Как я уже упомянул, мы мигрируем с JQuery на React, поэтому мы хотели использовать стейт менеджер и в легаси коде. Это позволило бы:
- мигрировать глобальный стейт в новую кодовую базу и использовать во всём приложении
- управлять реакт компонентами из JQuery, просто меняя стейт.
1️⃣ В первоначальном списке оказались:
- Redux
- MobX
- Recoil
- Zustand
- Jotai
- Akita
- Effector
2️⃣ После анализа, в следующем раунде отбора оказались: MobX, Recoil и Zustand. Recoil попал по блату, его проталкивал один из членов команды, и потому что он разработан в стенах авторитетной “запрещённой” организации.
Мы переписали один и тот же небольшой компонент на MobX, Recoil и Zustand, чтобы проверить их в деле:
❌ MobX. По большей части нам не понравилось, что каждый компонент нужно оборачивать в observer, если он использует observable объект. К тому же, у него не самый простой API.
❌ К Recoil было очень много вопросов. Начиная от того, что он жирный — почти 80Кб без GZip и заканчиваю тем, что нельзя просто взять и вынести из компонента асинхронные обновления стейта. С асинхронным получением данных всё понятно, там есть селекторы, но как асинхронно обновить стейт — хз. К тому же он не production ready.
✅ Zustand нам понравился своей простотой, чтобы понять код – даже не нужно смотреть документацию. Также круто, что он удовлетворял буквально каждому нашему требованию.
Если вы ещё не знакомы с Zustand, то обязательно посмотрите видео из предыдущего поста. А если вам в целом интересна тема стейт менеджеров — то подписывайтесь на Артёма — автора реатома.
P.S. Кстати, Zustand прост не только в использовании, его исходники тоже просты как дважды два — четыре. Лучше понять, как он работает под капотом поможет статья Как работает Zustand.
https://t.me/cherkashindev/124