При запуске, утилита генирирует древовидную карту, с помощью которой можно увидеть, какие именно файлы попадают в бандл.
К сожалению, почему именно это что-то попало в бандл утилита не говорит.
👉 В чём была проблема?
Иногда мы ленимся и в файле компонента кладём какую-нибудь утилитную функцию, enum или константу, а потом где-то в другом месте импортируем их.
Так вот, когда мы их импортируем, то в бандл “засасывает” не только импортируемую функцию, но и весь компонент, из-за чего размер бандла и увеличивается.
Веб-дизайн может быть источником множества курьезных ошибок, которые вызывают у пользователей недоумение, хуже того – мешают нормально взаимодействовать с сайтами. Некоторые компании оставляют все как есть, не обновляя интернет-представительства с 90-х годов, другие – игнорируют проблемы. Рассмотрим странные и смешные примеры веб-дизайна:
Pacific Northwest X-Ray Inc.
Компания предлагает портативные рентгеновские аппараты, очки, перчатки, фартуки и другие сопутствующие товары. Ее сайт известен своим неуклюжим и устаревшим дизайном, напоминающим стандарты 2000-х годов.
Сайт Йельской школы искусств выделяется необычным и аляповатым дизайном, сложным для восприятия. Он включает множество элементов, которые перекрывают друг друга и остаются плохо различимыми на ярком фоне.
Сайт LingsCars.com – образец того, как делать не нужно. Компоновка разнообразия оттенков, много анимации и перегруженность информацией существенно усложняют восприятие. Правда, проект позиционируется в качестве «самого сумасшедшего сайта по лизингу автомобилей» – так оно и есть.
Arngren.net – классический пример сайта с чрезмерным количеством информации на одной странице. Пользователю трудно ориентироваться из-за перегруженности различными элементами и предложениями.
Официальный сайт писательницы Сьюзен Коллинз, автора трилогии «Голодные игры» и экранизированного в прошлом году приквела «Баллада о змеях и певчих птицах», имеет совершенно несовременный дизайн. Здесь неудобные навигация и расположение основных элементов, незапоминающаяся цветовая гамма и изображения низкого качества. Такое ощущение, что он был создан в начале 2000-х.
- при каждом обновлении стейта значение селектора будет вычисляться заново - это приведёт к ре-рендеру компонента, так как каждый раз мы постоянно возвращает новый массив по ссылке, а по-умолчанию используется строгое сравнение (old === new).
Чтобы решить эту проблему в Zustand есть хук useShallow , который сделает “поверхностное” сравнение предыдущего и нового значения. Если они равны — ре-рендер не произойдёт.
Но при этом селектор всё равно выполнится, и в большинстве случаев нам не нужно об этом заботиться. Проблема появляется если выполнение селектора занимает много времени или же он вызывается много раз в различных компонентах или других селекторах.
Автор Zustand упоминает, что можно нарушить согласованность данных и просто положить вычисляемые данные в стейт (но в этом случае нужно вручную следить за их актуальностью).
Также он отмечает, что для этих целей можно использовать метод memoize из его библиотеки proxy-memoize (для redux есть reselect).
Аналогично immer’у proxy-memoize работает на основе Proxy. memoize запоминает предыдущий параметр функции и свойства к которым обращались в селекторе (для этого и нужен Proxy). При следующем выполнении функции, он проверит изменились ли используемые свойства, если нет — вернёт значение, вычисленное в прошлый раз.
Недавно делал код ревью и заметил, что в pnpm-lock.yaml (альтернатива yarn.lock в pnpm) добавлена 17-я версия реакта, хотя на проекте мы используем 18-ю. Нам не нужно тянуть в проект 2 версии реакта — поэтому идём разбираться.
Дело в том, что в библиотеке react-cheetah-grid, которую мы используем для рендера длинных таблиц, реакт указан в секции dependencies вместо peerDependencies.
dependencies vs peerDependencies
- dependencies: пакеты, которые необходимы для работы вашего приложения и устанавливаются автоматически - peerDependencies: пакеты, которые должны быть уже установлены в среде, где используется ваш пакет, чтобы избежать конфликтов версий
Чтобы быстро исправить проблему — можно переопределить версию реакта для определённого пакета в pnpm с помощью метода readPackage. Также нужно откатить изменения в pnpm-lock.yaml и запустить pnpm install .
Это статья для начинающих фронтенд разработчиков, которые с яркими глазами и минимальной зп готовы к первому коммерческому опыту.
Стэк: vue3, nuxt3
P.S. АХТУНГ! Много букаф, смысла null, потому я есть Shaltier Nullfallen! Статья написана ВЕЛИКИМ в "кавычках" грамотеем, если вы любите высококачественный контент, скорее всего вам не стоит читать эту статью. Все названия и имена были заменены, любое совпадение является чистой случайностью.
Добро пожаловать, заблудшие огоньки, сегодня я хочу поговорить о самых обычных моментах работы frontend разработчиком в маленькой фирме. Этот текст наполнен унынием и разочарованием, надеюсь он передаст толику моих эмоций.
Хромые клячи
Конец месяца, собеседование в компанию "Стрекозлы в АйТи" прошло весьма неплохо, я напортачил в предыдущей компании, создав образ посредственного падавана. Фронтендер из предыдущей фирмы "BODUNOV" видимо недавно открыл для себя vue и nuxt. Структура проекта была специфичной (это пример):
Я покажу тебе, как глубока кроличья нора
Примечание: Мне нравится структура из angular и это не мешает использовать похожий стиль в компонентах. Используйте основную структуру из доков nuxt. Старайтесь не допускать больше трех уровней.
Папка partials с огромной вложенностью передавала привет от мистера webpack, а точнее плагина по импорту html.
Разработчик сделал 40% проекта и метался от одного UI kit к другому, а я слушал и крутил барабан револьвера. Сделав одну страницу, меня попросили удалиться, попытка разбить вёрстку на компоненты и избавился от ненужных дубликатов html кода смутила разраба фирмы BODUNOV. И тут меня ждала новая не менее амбициозная компания, с 10-ти летним стажем на рынке.
На собеседование в "Стрекозлы в АйТи" я убедился у интервьюера, в отсутствие глуповатого маркетингового приёма, сверстать статический сайт и показать клиенту, сказав: 'Всё готово шеф, дело осталось за малым'. Люди серьёзные, работают с продукцией 1с и считаются в ней экспертами.
Битрикс есть, а отчеты пиши в excell. И не забывай щелкать таймер и писать отчёт в конце дня. Джира? Какая Джира? Продукты 1С топ! Мы пробовали только Яндекс и это был отстой.
Ну хоть хорошо что excell не используется как база данных для бэка. А вместо word не используют markdown. Вот тупые, кто `markdown` придумал.
После ознакомительного диалога ПМ-а по работе со Шмитрикс, я не понял как они ведут разработку. На канбан доске вместо привычных столбцов было несколько столбиков связанных со временем:
// Без срока // Запланированные // Сделаю сегодня // Сделаю на недели //
Хмм... наверное для перевода на тест нужно делегировать тестировщику, а потом...
А нееее... кроме менеджера, разработчиков и дизайнера больше никого нету. То есть нет тестировщиков, контент-менеджеров, seo, devops и т.д.
Менеджер сказал (не дословно, почти): "Всех кого-ты перечислил сомнительные личности и результат их работы не ясен. У нас было много SEO специалистов, целых 3, ой, 2 человека. Ну руководство не поняло их трудов и уволило."
Окей... Нам не в первой работать по старинке. Пока нам платят, мы будем радостно визжать как свиньи. Ну что погнали за работу!
Three Days Later...
Прошло 3 дня, а я ничего не сделал. Нет, вина не в моём титуле Капитан Улитка, просто задач нет! Как объяснил менеджер, он болеет, неделя очень тяжелая, задачу выдать не могу. (На самом деле было ещё 2 менеджера которые могли его подменить, но заставлять работать больного сотрудника веселее)
Обычно первым делом в любой компании заставляют читать документацию на 6 часов, ставить vpn, но в документах Шмитрикса было почти пусто, компания не хотела покупать продвинутую подписку, поэтому каждый создавал файлы в облаке, кто в гугл, кто в яндексе. Каждый держал файл у себя, а не в общей папке, поэтому узреть могли только избранные.
Первое задание. Разместить статический сайт выполненный начинающим верстальщиком Рыжий. Видимо только вчера прошел курс ХалалАкадемии и решил проверить новоиспеченный скил. Где-то пагинация была сделана картинкой, где-то отсутствовали блоки, где-то хромал адаптив.
Пишите а вам попадались сайты где не было верстки, только backgroundImage?
Мне дали доступ по ssh и попросили поставить сайт с сертификатом на nginx. В принципе окей, но в вакансии про эти скилы не слова.
One Day Later...
Разговор с дизом и ПМ. Дизайн находится под слоём черновик, каждый макет не имеет статуса готового к разработке.
Примечание: кнопка фигмы Ready For Dev, некоторые дизайнеры делают свой компонент для статусов макета или используют цветовые зоны, т.к. макет может иметь много статусов (прототип / в процессе доработки / на утверждение / готов)
Даже без матёрого глаза можно приметить множество огрехов в дизайне. Отсутствие модалок, элементы не интерактивные, нет статусов элементов форм. В некоторых местах много воздуха, неравномерные отступы... В общем полный комплект ошибок ждуна. Дизайнер пытается скрыть смущение, намекая на сроки, мол времени на UX и полировку UI не было. Удивительный факт, разработчикам всегда представляют диза так: "А это наш UI/UX дизайнер". Вот только времени на UX исследования у него нет.
И теперь работа? Нет. Доступа к гитлабу нет, задач в шмитриксе нет.
На следущий день получил доступ к гитлабу, сразу начал создавать проект, хотя задачи не было, есть интуиция и особая минтайная связь. ПМ захлебывался соплями и издавал предсмертный хрип, получить инфу по проекту было нельзя.
А инфы по проекту не было / LOL / Редизайн предполагалось делать на основе нового диза и поглядывая на старый сайт. Только новый дизайн сильно отличался. Не было к примеру локализации (был выбор региона) и ПМ сказал твёрдо её НЕ БУДЕТ! Вот тут и была первая подстава.
ПМ тоже не одобряет дизайн, но продолжает сюсюкаться (чей-то родственник или мидихлориан в избытке). Дизайн сделан посредственно и как оказывается не является техническим документом.
Спойлер: По мнению руководства я должен был делать не по дизайну, а по старому сайту, дизайн лишь красивый фантик для клиента и задача разработчика самому продумать адаптивность и функционал сайта.
Благо старый сайт не имел минификации и обфускации.
Примечание: После компиляции кода, файл со скриптом крайне тяжело прочитать. Начинающие разработчики умеют кидать скрипты в конец документа, чтобы не мешать прорисовке странице, на этом их знания исчерпываются. Раньше мы прописывали чанки в webpack ручками, теперь с vite многие разрабы не знают про это.
Ладно с дизайном всё ясно, ну мне нужно делать динамический сайт похожий по типу на интернет магазин, где взять бэкенд? Старый сайт был выполнен в php шаблонизаторе и имел мобильное приложение (отличается по функционалу от сайта), теперь предстояло сделать его на nuxt, а значит старое api не подходило.
Угадайте кто должен был придумать дизайн API? Бэкенд! Не угадали. Конечно же фронтенд (по факту vue SSR это уже fullstack)
Примечание: Бэкенд разработчики могут разработать API самостоятельно, а значит они могут приступить к работе сразу без верстки. После одобрения прототипа, уже можно предположить какие данные будут выводится. Прототип дазайна уже определяет базовое расположение блоков и медиаконтента
Мне позвонил специалист по отделу кадров, спрашивает как дела и мол я буду звонить тебе каждый месяц (это был последний звонок). А я такой: "not bad, но знаешь, тут ..."
- А покажи что ты сделал.
Я отправляю ему ссылку на сайт.
- Скажи, то что сделал Рыжий, тебе как-то помогло?
- Как я говорил на собесе, всю эту вёрстку все равно нужно переделывать, к тому же там было много косяков, вёрстка была абсолютная не валидна по w3c. Я начал с начала.
- Ну ты же понимаешь я не могу показать это?
На тот момент навигация еще не приходила с бэка, перемещаться по сайту было нельзя, а также были видны некоторые косяки. Я и не хотел демонстрировать сайт.
- Ну да, вы показали клиенту фантик без конфеты. Без серверной части нельзя оставлять заявки или отправлять формы, сайт и делается ради интерактивности, иначе мы могли бы продавать фотографию сайта.
Менеджер посмотрел на меня как на шарлатана. Почему кадровик ведет переговоры по проекту с клиентом? А может он, вовсе и не кадровик?
Если это была свежая компания из 5 человек, я бы понял. Но персонала было не менее 20 чел. А компании уже 10 лет. Наверное за это время можно было собрать базовую комплектацию.
Два месяца спустя или 44 раб дня
Бэкендер выходит из долгожданного отпуска...
4-5 остальных видимо были очень заняты. Я лично работал с двумя, но официально в штате их должно быть больше. Да и как-то на созвоне созвали толпу, которой объяснили как сделать 1 эндпойнт с получением данных из firebase. Результат: я поднял nuxt и сделал сам. Ну что сказать команда профессионалов, умеют убеждать.
Ах, да... Бэкенд выходит из отпуска и заходит в шмитрикс. Бэкендер плачет ПМ: "Там слишком много! Апи уже почти готово, там всё есть"
Конечно же там много чего не было, апи первой версии сделано не по REST, которому далеко до стандартов JSON:API.
Swagger-а нету, есть postman, апи которое написано ручками (тока шайтаны пишут доки в аннотациях и используют модуль автодокументации)
Примечание: Незнаю как в Yii, но в Symfony генерировать коллекции с готовыми Rest Api эндпоинтами милое дело. По идее мы один раз заморачиваемся пишем ядро, а далее используем от проекта к проекту. Документацию легко можно импортировать в postman. Если у вас будет фронтенд SPA/SSR в виде отдельного приложения, задумайтесь, а нужно ли его писать на php? Бэкенд на nodejs может сэкономить время. Низкой порог вхождения !== выгода. Nodejs может быть serverless, а php это танцы с бубном в плане деплоя. А там типизация от бэка почти готовая
Меня попросили переделать для бэка документ с api запросами и как вы думаете он приступил к правкам сразу? Конечно же нет. Рабочий день начинался в 9 часов, точнее так было у удалёнщиков, офисные планктоны почти всегда приезжали на работу после обеда. Оказывается часть сотрудников работают во вторую смену, а бэкендер на протяжения дня занимается бумажками от шефа, сам шеф со спокойной душой уезжал в командировку. По более сложному проекту с картами, мне приходилось ждать фидбека от шефа компании каждый вечер, а днём по указаниям из аудиосообщения я пилил приложение.
Конечно для написания ТЗ необходимо время, а наболтать по телефону сообщение это дело не сложное. Ну и тупые эти разработчики, носятся со своими ТЗ.
Хороший мальчик Бобби
Не курит, не пьёт. Деньги в копилку кладёт. Большая часть рынка разработки это ждуняшки ожидающие маны небесной. В один прекрасный день армию ждунов без тимлида, мидлов или сеньоров, только ждуны, только харкор. Банда маркетологов оказывается чаще всего во главе малого бизнеса (будем честны в крупных компаниях, тоже не всегда руководители инженеры), это приводит к печальным последствиям для IT рынка. Сначала нанимают партию разработчиков, через год или два, шеф проходит специальные курсы по бизнесу и открывает новые слова: "B2B" и "B2C". Он смотрит в собственное отражение и видит гениального человека, способного открыть свой телеграм канал и продовать свои собственные курсы. Увольняем 90% разрабов, получаем чистый профит с курсов. \ STONKS /
Судная ночь
Сайт в итоге сделали, правда за несколько часов до презентации (они решили все вместе приехать в офис клиента и открыть бутылку шампанского), а тут оказывается на сайте должно быть так, а ни сяк.
-- Эту кнопку убрать! Батюшки, я ведь всё ни так! Клиент? Какой клиент! Я так вижу! Сделать по моему! Клиент потом посмотрит и скажет. В смысле, конечно макет утвержден! Видишь дизайнер тока что стрелочки в дизайне дорисовал, а у тебя их нет! А ну быстро отсеките голову этому халопу! Стража! Стража!
Титры
Нет повести печальней, чем история о Shaltier и потерянном времени. Почему никто не плачет? Не забываем купить мои курсы "Как открыть IT стартап для ...". Продолжение пишем в комменты.
Спасибо за ваше потраченное время, надеюсь в следующий раз, контент будет лучше. Обычно мы начинаем работать в компании для поднятие скила, но этот опыт равносилен фрилансу, да еще платят меньше и мозг съедают чайной ложкой.
В воскресенье, 5 мая, Ренд Фишкин (известный во всем мире как основатель популярного сервиса Moz.com) получил электронное письмо от человека, утверждающего, что у него есть доступ к массивной утечке документации API из внутреннего подразделения поиска Google. В письме также утверждалось, что эти утекшие документы были подтверждены как подлинные бывшими сотрудниками Google, и что эти бывшие сотрудники и другие лица поделились дополнительной, приватной информацией о работе поиска Google.
Один из скринов "слитой" базы Google
Многие из их заявлений прямо противоречат публичным заявлениям сотрудников Google, сделанным за последние годы. В частности многократным отрицаниям компании о том, что сигналы пользователя, связанные с кликами, используются, что субдомены рассматриваются отдельно в ранжировании, отрицаниям существования песочницы для новых сайтов, отрицаниям того, что возраст домена собирается или учитывается, и многому другому.
"Сливщиком" информации оказался Эрфан Азими (ссылка на Линкедин). В его профиле указана Грузия как страна проживания. Именно он показал Ренду саму утечку: более 2,500 страниц документации API, содержащей 14,014 атрибутов (функций API), которые, по-видимому, происходят из внутреннего "Content API Warehouse" Google. Судя по истории коммитов документа, этот код был загружен на GitHub 27 марта 2024 года и не удален до 7 мая 2024 года.
Что интересного в этих документах?
Ложные Утверждения Google, Опровержения которых обнаружены в Документации API
Утечки документации API Google раскрыли значительные противоречия между публичными заявлениями Google и их реальными
Авторитет домена: Google неоднократно отрицал использование "авторитета домена", утверждая, что они не используют метрику для измерения авторитета сайта в целом. Однако утекшие документы показывают существование метрики под названием "siteAuthority", используемой в внутренних системах Google, что противоречит их публичным заявлениям. Такие известные личности, как Гэри Илш и Джон Мюллер, неоднократно заявляли, что Google не использует метрику авторитета сайта, что теперь кажется вводящим в заблуждение.
Использование кликов для ранжирования: Представители Google давно отрицают, что клики влияют на ранжирование в поиске. Несмотря на эти утверждения, свидетельства из антимонопольного процесса Министерства юстиции США и различных патентов указывают на существование систем, таких как NavBoost и Glue, которые используют данные о кликах для влияния на результаты поиска. Эти системы существуют с 2005 года и используют обновляемые данные для настройки результатов поиска на основе кликов пользователей. Эта практика противоречит публичным отрицаниям Google и подчеркивает их попытки ввести в заблуждение сообщество SEO.
Эти открытия подчеркивают разницу между публичными заявлениями Google и их внутренними операциями, вызывая вопросы об их искренности.
Что будет дальше?
Пожалуй, ничего. Google наверняка будет открещиваться и утверждать, что все это фейк. Признавать свои ошибки никому не хочется:) В любом случае мир SEO теперь не умрет совсем, но людям, которые работают в этой сфере будет наверняка интересно сопоставить свои знания с тем, что упоминается в слитых документах.
Что лично почерпнул для себя автор этих строк
Даты публикаций очень важны - Google ориентирован на свежие результаты, и документы иллюстрируют многочисленные попытки ассоциировать даты со страницами.
Фрагмент с упоминанием про важность упоминания дат изменений контента
Лучший подход – указать дату и быть последовательным в ее использовании в структурированных данных, заголовках страниц, XML-картах сайта. Указание дат в URL, которые противоречат датам в других местах на странице, скорее всего, приведет к ухудшению ранжирования контента. Что ж попробую протестировать полученные знания в своем блоге :)
