#фишка дня

Один из моих любимых вопросов на собеседованиях был про поведение Array.prototype.sort().

Вы не представляете какое количество людей просто не задумывается о том, что sort — мутирующий метод, то есть он возвращает не новый массив, а ссылку на изменённый текущий.

Да, в большинстве случаев ничего страшного не произойдёт, но в остальных — будет неприятно.

Так вот, к чему это я. С выходом Firefox 115 в июле этого года мы получили иммутабельные методы работы с массивами во всех браузерах:
.toReversed()
.toSorted()
.toSpliced()
.with()

Если что, with — это про замену элементов по индексам.

Есть и полифиллы на core-js, так что без работы никто не останется.

И это прекрасно.

#js #array #sort #бородач

#фишка дня

Поскольку селектор has почти прилетел во все браузеры (Firefox 121 вот-вот выйдет), самое время использовать его для чего-то более прозаичного, нежели анимации а-ля macOS Dock: https://news.1rj.ru/str/htmlshit/1873

Как вам, например, подсветка колонок в таблице? Ведь без JS эту задачу было решить довольно сложно.

Самый популярный способ подсветки без JS на сегодняшний день — создать очень (очень) высокий псевдоэлемент и показать его по ховеру: https://css-tricks.com/simple-css-row-column-highlighting/

Но это, конечно, какой-то стыд. Хочется что-то чуть менее колхозное.

И, наконец, мы можем это сделать!

Пример от Стэна Хуугарда: https://codepen.io/alinaki/pen/oNmmooN

Значащий код:

table:has(td:nth-child(5):hover) {
  td:nth-child(5) {
    background: var(--hover);
  }
} 

Что тут происходит? Всё просто: если в таблице имеется (has) наведённый мышью пятый (nth-child) элемент в любой строке, надо подсветить все остальные пятые элементы в каждой строке таблицы вообще.

Дыхание будущего! Правда, всё немного портит хардкод номера ячейки... но можно просто сгенерировать сразу штук 10.

По-моему, это решение ну в разы приятнее высоких псевдоэлементов.

Как вам, котаны?

#css #has #table

#заметка дня

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

И нытьё это о процессе изучения программирования вообще и веб-разработки в частности.

TL;DR веб-разработка никогда не была настолько простой, а процесс обучения ей — настолько усложнённым.

Теперь давайте по порядку. Будет 2-3 части и некий итог. Если хотите коротко — рекомендую дождаться итога. Я пытаюсь создать атмосферу.

Мне 36 лет и я уже на полном серьёзе могу применять фразы вроде «моё поколение». Так вот, это самое моё поколение начинало изучение программирования на интегрированных средах разработки — IDE. Сначала это был Turbo Pascal, но очень быстро мы все переползли на Delphi.

Почему я упоминаю IDE вообще? Всё просто, секрет в той самой букве I, «интегрированности».

За свои деньги (2002 год в РФ, конечно же за деньги, что вы, что вы) вы получали:
1. Справочник по языку
2. Текстовый редактор с автоподстановкой
3. Визуальный конструктор интерфейса (буквально мышкой размещать компоненты!)
4. Компилятор
5. Отладчик

Что на выходе? А на выходе рабочее desktop-приложение под де-факто одну доминирующую платформу. Напомню, минут 30 назад вы всего лишь перетащили кнопку из палитры на окошко и кликнули по ней дважды, получив готовый код обработчика события нажатия.

В 2002 году при этом веб-разработка была уже устоявшейся, но не считалась серьёзной, особенно после бума дот-комов. Если интересно, я раздам расклад, но мы всё-таки попробуем сфокусироваться на фронтенде.

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

Да, были редакторы вроде Front Page и DreamViewer, но это считалось примерно тем, чем сейчас считаются Tilda и Framer: не для серьёзных пацанов.

У вас был браузер (IE или Netscape 6), блокнот и сочетание клавиш Ctrl-U для просмотра кода страниц. Всё.

Уже подготовленные знанием о том, что для работы кнопки по нажатию нужно писать какой-то код мы находили на интересующем сайте саму кнопку, нажимали Ctrl-U, искали её в коде страницы, копировали в блокнот. Потом искали в коде этой же страницы всё, что могло быть с этой кнопкой хоть как-то связано и чаще всего находили кусок JavaScript в теге <noscript>.

Иногда ничего не находилось, но после просмотра всего, что хоть как-то походило на ссылку с расширением js улыбалась удача и приходило понимание: код можно хранить в других файлах. И опять начинался процесс поиска, чтобы заставить кнопку показать alert().

Естественно, потом бралась в школьной же библиотеке куча книг с названиями вида Dynamic HTML, DHTML, "веб-мастер" где серьёзные дяди на серьёзных щах рассказывали как написать калькулятор или прилепить к курсору мыши снежинки. Так приходило понимание работы с DOM.

Пост становится слишком длинным, потому я рискну выпустить эту часть к полуночи и понять, нужно ли вам продолжение, уже утром. Дайте знать 🙂

#заметка дня

Продолжаем

Делиться же результатом труда было очень просто. Гораздо проще, чем копировать друзьям на дискету скомпилированный экзешник из Delphi.

Каждый интернет-провайдер в те годы давал возможность разместить «персональную веб-страницу» с диким адресом вроде http://example.com/~username.

Даже поддержка Perl и иногда PHP имелась, зависело от вашего умения ныть по телефону техподдержке. Как вы понимаете, этим стоило пользоваться. А ещё был легендарный narod.ru, но туда можно было грузить только простой HTML и сопутствующие файлы, что не мешало многим строить целые миры.

То есть, чтобы распространить результат, нужно было наляпать что-то в блокноте и загрузить это на FTP провайдера, обозвав index.html или index.php. Всё!

К этому моменту многие могли потерять мысль, но я всё же выражу её ещё раз: кроме блокнота и браузера не нужно было ничего, а масштабы распространения были при этом безграничны.

Вполне логично, что в какой-то момент хотелось сделать, например, книгу посетителей, отзывы... чат. Для этого применялись языки на сервере, тот же PHP, которые генерировали некий HTML код. Ни о каком изменении содержимого без перезагрузки страницы речи пока не шло: вы отправляли форму кнопкой Submit, сохраняли значения куда-то в базу данных или файл, потом генерировали при помощи PHP новый HTML и возвращали его обратно. Каждый раз всю страницу целиком.

JavaScript так и использовался в большинстве случаев для того, чтобы сделать снежинки.

Gmail, перевернувший мир, появился только в 2004.

Всё это хотелось сделать красиво, потихоньку набирал обороты CSS, который изначально буквально был нужен чтобы убрать подчёркивание у ссылок при наведении. Но уже от этого был восторг. Веб-страницы так и верстались при этом таблицами, даже до понятия семантики было ещё лет 10.

Я не планировал связывать свою жизнь с вебом и после 2004 года выпал на несколько лет. Вернувшись уже профессионально в 2009 году, я с удивлением обнаружил, насколько всё стало больше. При этом веб как был ориентирован на генерацию страниц на сервере, так и остался.

Но, хвала Gmail, дико распространился AJAX! Если коротко, это загрузка контента без перезагрузки страницы.

При этом JavaScript-файлы так и оставались чем-то отдельным и обособленным, но их роль уже заключалась в том, чтобы обработать какое-то событие нажатия на элементе, выполнить AJAX-запрос, получить в ответ, опять же, кусок HTML и вставить на страницу.

Где-то в эти же года (2006) на сцену вышел jQuery, который сразу обозначил свою позицию:
- безумно простой AJAX
- безумно простые анимации
- безумно простые обработчики кликов по элементам

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

Но он дал нам кое-что ещё, и это самое важное: систему плагинов. Это время расцвета каруселей, кастомных селектов, попапов и лайтбоксов. Подключали плагин, описывали свои правила его работы и вперёд. Именно в это время распространяется IIFE: это был на тот момент лучший способ делать независимые модули.

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

Чувствуете, куда подбираемся? Да, дамы и господа. К системам сборки и минимизации кода. Как раз в 2009 году вышла первая версия Node.js.

И вот об этом-то через несколько часов и будет следующая часть.

#заметка дня

Как я уже сказал, будет три части и итог. Это третья часть. В двух сообщениях.

В 2009 году я для себя базой выбрал Drupal, CodeIgniter и jQuery. Вёрстку к тому времени изучил по Маниакальному веблогу, за что Ивану Сагалаеву огромное спасибо, база оттуда осталась неизменной.

В 2010 году появляется Angular 1. Где-то в то же время нарастает движение HTML5 против XHTML 2.0, в ход вступает семантика и то, что называлось «вёрсткой на дивах» становится «семантической вёрсткой». У нас уже есть Firefox, Safari и только-только появился Chrome. IE предстояло потесниться.

Конечно, были ещё Ext.js, Backbone и Marionette, Dojo, MooTools...

Я плавно подвожу к тому, что с 2009 по 2014 год веб сильно рос. Именно с той поры пошли шутки про новые фреймворки каждый день, и это не было преувеличением.

Рост массы JS-кода был лавинообразным, но до какого-то момента было всё равно: ты подключал кучу файлов и не парился.

Но в какой-то момент это всё же стало зачастую превышать разумные пределы, потому появились инструменты для минификации и обфускации кода; для сжатия картинок.

Требовалось что-то для сборки шаблонов и упрощения вёрстки. Так родился Gulp, позволявший выполнять задачи по порядку: собрать JavaScript-файлы в кучу, минимизировать их, сжать картинки, склеить HTML...

К 2015 году появилась концепция ES6/ES2015, ES-модулей. К тому времени уже был Node.js с CommonJS и его require(), но все хотели стандартов; Node.js-вариант не всем нравился и имел свои минусы, хотя на фронтенде его можно было использовать через Gulp и Browserify, что многие очень активно и делали.

Крупные разработчики стали обращать своё внимание на такой простой и детский JavaScript и резко захотели приблизить его к индустриальным стандартам.

Естественно, браузеры все новые фишки JS не поддерживали, потому вместе с идеей ES6 родился и «транспилятор» Babel.js, который можно было использовать как прямо на странице, так и в своих сборках на Gulp.

Помните я в первой части рассказывал про IDE, в которой было всё? Я не упомянул одну важную штуку: линковщик. Или, собственно, сборщик. Чтобы скомпилированный код собрать в один исполняемый EXE-файл вместе со всеми ресурсами, картинками, иконками и звуками именно его и нужно было использовать.

И как раз вместе с концепциями ES6, ES2015 и ES Modules на рынок вышел Webpack, принёсший идею сборщика в веб.

Отличием Webpack от Gulp стало то, что он именно что собирал всё, что вы ему передали, в один огромный JS-файл. Webpack катком прошёлся по стандарту модулей и позволил импортировать CSS, SCSS, LESS, HTML, JS, JSON, SVG и даже картинки вообще простой директивой import! Это совпало с ростом запросов на одностраничные лендинги от бизнеса, где такой подход потрясающе себя оправдывал.

Случился настоящий взрыв. Разработчики, привыкшие к идее сборщиков на серьёзных системах, прониклись идеей максимально.

А Node.js к 2014-2015 году уже доказала свою полезность не только как серверная среда, но и как пакетный менеджер и основа для запуска бесконечного количества JS-кода для инструментов сборки и выполнения задач.

Да, это было безумно медленно с точки зрения длительности процесса сборки и разработчиков вроде меня, привыкших к классической генерации HTML, приводило в ужас: только вдумайтесь, огромная мешанина всего на свете внутри одного JS-файла и чтобы вытащить всё наружу требовались плагины-экстракторы, ну просто смешно. Но это позволяло писать и выкатывать фичи очень быстро, используя современные возможности языка. Никто не хотел оглядываться на генерацию HTML на PHP и прочем. Обратился к API, сгенерировал HTML на клиенте — и всё, мухи отделены от котлет.

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

1. HTML и DOM
2. CSS и SCSS/LESS
3. JavaScript, ES Modules
4. Командную строку
5. Базу Node.js и npm
6. Конфигурацию Webpack
7. Конфигурацию Babel
7. AJAX/AHAH и API

И где-то тут появляются полновесные фреймворки/UI-библиотеки вроде React.js с его дополнительным языком JSX, Vue.js с его концепцией скоупов, Ember.js с его классическим MVC и утилитами командной строки и Angular 2.0 на чём-то с названием TypeScript.

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

«Так, вот это командная строка, тебе надо скачать Node.js вот отсюда, написать вот такую команду, установить с десяток пакетов, теперь взять Webpack, написать конфигурацию (в смысле, ты хочешь многостраничник? зачем?), импортировать SCSS внутрь твоего JS, раскатить перезагрузку по сохранению страницы... а отладчик у тебя будет в браузере, вот по F12. Ах, не понимаешь, что там написано? Так тебе ещё нужны source maps, чтобы склеенный минимизированный код расшифровывать».

Вам не кажется, что это малость далековато ушло от «вот блокнот, вот браузер»?

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

Есть только одна проблема: люди просто хотят чтобы по нажатию на кнопку браузер с ними поздоровался.

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

#заметка дня

Мой посыл в итоге будет таким: не используйте промышленные методы разработки до того момента, как вам реально это будет нужно.

Зачем пытаться развернуть весь стек у себя на компьютере, если есть решения вроде https://codesandbox.io/? Туда же replit.com и codepen.io

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

При этом делать на таких ресурсах можно практически всё, что угодно (на CodePen чуть меньше): создавать веб-страницы, писать на React и Vue, загружать файлы, ставить пакеты Node.js, выставлять на всеобщее обозрение. Захотелось большего — песочницы позволяют редактировать конфигурации и поднимать уровень сложности. Вплоть до полноценной виртуальной машины.

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

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

И, конечно, постарайтесь разобраться с базовым владением компьютером и английским языком до того, как начнёте пытаться что-то делать: научитесь отличать /, от ./, ../ и https://.

Чтобы не страдать с настройкой Webpack и отладкой кода после упаковки, есть прекрасные современные средства вроде Parcel, Vite и Snowpack, которые не станут запутывать ваш код так, что вы не сможете даже с отладчиком его распутать. Все браузеры уже давно умеют в поддержку модулей, всё, что вам нужно — это сервер и немного прослойки к пакетам, чем эти инструменты и являются.

Но особо хочется отметить тот факт, что никто и никогда за все эти года не отменял такое простое сочетание блокнота и index.html.

Поддержка фишек JavaScript в современных браузерах сейчас на своём пике. Всё, что вы найдёте в руководствах по JavaScript — будет там. Даже CSS и тот поддерживает вложенность, если вам так лень писать классы.

На ваши HTML-файлы на файловой системе вполне можно ссылаться, для этого не надо поднимать сервер, достаточно понимать, что такое ./.

Не ведитесь на рассказы, что веб-разработка или какой-то конкретный скилл в программировании это социальный лифт. Социальный лифт — это умение декомпозировать и решать задачи. Остальное приложится.

А разбивать себе лоб промышленной разработкой на самом старте не имеет никакого смысла.

#итоги года

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

Но мы-то с вами знаем, что настоящие итоги — они в State of JavaScript, State of CSS (правда эти ребята почему-то закрыли итоги года аж в июле) и CSS Wrapped 2023.

Опрос State of JavaScript открыт прямо сейчас. И пусть вас не смущает то, что это опрос — каждый вопрос это возможность узнать о существовании чего-то нового. Авторы спецификаций и статей тюнят маркетинг таким образом и знают, о чем стоит писать :)

CSS Wrapped же просто большая статья всех появившихся фишек CSS в этом году. А было много чего: has к концу года будет во всех браузерах, контейнерные запросы с нами, вложенность уже везде.

Тока ради бога не пытайтесь понять русский перевод в CSS Wrapped. По всей видимости, машинному переводу от Google ещё очень далеко до понимания контекста... Обёрнутый CSS, my ass. Gemini, говорите? Ну да, ну да 🤡

P. S. Wrapped в данном контексте переводится как «подведенный к итогу», «итоговый», от словосочетания «wrap up», что значит «summarize». И понятное дело, под Новый год получилась игра слов, будто подарок под ёлку.

#stateofjs #css #js

#фишка дня

Итак, сегодня я спросоня долго смотрел на этот пример от Джея и никак не мог понять, какого фига тут происходит.

Не, ну я вижу, что в итоге получается градиентная граница, но... но почему?

И тут до меня дошло: оказывается, при настройке фона можно фактически указывать боксовую модель! Ну то есть называется-то оно background-origin, но по факту работает по тем же принципам, что и box-sizing.

Итак, три значения: border-box, padding-box и content-box.

Выходит, border-box заполнит фон, включая границы, padding-box — до полей, a content-box — по контенту.

Ну и для градиентных границ (к сожалению, только с непрозрачным фоном), получается так:

article {
  background: // layer them up with different origin!
    linear-gradient(var(--bg), var(--bg)) padding-box,
    var(--gradient) border-box;
  border: 4px solid transparent;
}

Обратите внимание, котаны, такое прокатывает только с фоном-изображением или градиентом, для сплошного заполнения просто указать цвет не выйдет!

Ну и пример, конечно же: https://codepen.io/alinaki/pen/QWYoPpx

#css #background #origin

#инструмент дня

Важной частью процесса разработки является сканирование уязвимостей в коде и зависимостях. А ещё более важной — слежение за ними.

И этот процесс было бы неплохо автоматизировать.

Да, в какой-то мере справляется dependabot, но не во всех компаний используется GitHub и хотелось бы получать сводки в любой момент. Ну а npm audit такая себе игрушка.

И тут у нас имеются прекрасные инструменты. Для начала, конечно же, база уязвимостей для Open Source библиотек: https://ossindex.sonatype.org/

Обратите внимание, речь не только про JS aka npm, в каталоге присутствуют практически все мыслимые среды и пакетные менеджеры.

Второй момент это тулинг. И тут от тех же Sonatype имеется пакет AuditJS: https://github.com/sonatype-nexus-community/auditjs

И расширение для VS Code: https://marketplace.visualstudio.com/items?itemName=SonatypeCommunity.vscode-iq-plugin

Всем безопасной разработки, котаны!

#security #vulnerability #scan #audit

#баг дня

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

inb4 я в курсе, что большинство подписчиков из РФ и Stripe там не работал никогда, но мой поинт не в этом, принцип работы платёжных систем на клиенте одинаков.

Тут вы замечаете, что 1-2% пользователей не могут завершить покупку. И никак не можете понять, что же не так. И всё как-то нестабильно при этом... то могут, то не могут.

В какой-то момент до тебя доходит, что проблемные пользователи сидят на нестабильном интернете или за VPN. Включаешь Throttle на вкладке Network — и, чудо, повторяешь проблему!

Не очень понятно, почему сразу нельзя было залезть на гитхаб официальной клиентской библиотеки, но выясняется, что проблема стара как говно мамонта, сразу даю ссылку на повтор: https://github.com/stripe/stripe-js/issues/26#issuecomment-1477716731

Конечно, если говну мамонта 4 года. Но это именно так в случае подобных библиотек.

Проблема прям настолько простая, насколько вообще возможно: люди на нестабильных соединениях могут быть неспособны загрузить библиотеку.

Но, более того, загрузчик реализован таким образом, что если ты попытаешься реализовать повтор загрузки самостоятельно, у тебя не выйдет. Стоит получить "Error: Failed to load Stripe.js", поможет только перезагрузка страницы.

К счастью, Stripe, наконец, выпустила решение: https://github.com/stripe/stripe-js/pull/518

И оно потрясающе простое: удалить упавший промис и дать возможность создать его заново.

Я почему вообще это вынес, пусть многие никогда с проблемой Stripe и не встретятся: надо быть очень внимательным, загружая код по запросу. Всегда думать о возможности перезапустить загрузку и не позволять коду оставаться в подвешенном состоянии.

Да и PR достаточно прост, чтобы понять принцип работы подобных решений.

#stripe #promise #defer

#инструмент дня

Ох что я вам нашёл! Просто пушка.

Как вам отладка на мобильных устройствах? Ну только честно. По-моему — мучение.

Да, можно подключить телефон кабелем к компьютеру и пользоваться консолью настольного браузера. Можно купить доступ к Browserstack или аналогам и разруливать косяки на десятках устройств. Ах да, можно ещё воспользоваться эмулятором!

Но почему бы просто не воспользоваться девтулзами? Ну потому что в мобильных браузерах их нет.

Зато есть Eruda! Встраиваемая консоль для мобильных браузеров: https://github.com/liriliri/eruda

Демо: https://eruda.liriliri.io/

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

В общем, забавная вещь! В какой-то момент может и выручить.

#js #devtools #mobile #бородач

#инструмент дня

Что быстрее всех на свете?

Неправильно! Быстрее всех на свете Lightning CSS. В чём конкретно быстрее это сейчас не важно :)

Важно то, что это шикарный инструмент для парсинга, последующей обработки, сборки и минификации вашего CSS. Создан ребятами из Parcel и написан, как это нынче принято, на Rust. А ты уже учишь Rust?

Вот: https://lightningcss.dev/

Объединяет в себе возможности CSSNano, ESBuild и PostCSS. Кстати, не только быстрее, но ещё и размер сжатого файла получается меньше.

Основан на коде из Firefox, поэтому назвать его появившимся из ниоткуда просто невозможно. Lightning CSS обработает CSS точно так же, как браузер, построив правильную CSSOM (Object Model, по аналогии с DOM), с учётом типов токенов.

Естественно, имеется разлапистая поддержка плагинов и CSS-модулей.

Кстати, молния понимает @import, за бандл не беспокойтесь.

И вообще, сам Андрей Ситник предлагает мигрировать с PostCSS: https://web-standards.ru/podcast/381/#01:17:39

Пробуем?

#css #lightningcss #rust #бородач

#фишка дня

А приходилось ли вам, котаны, плавно менять текст?

Тогда вы не могли не заметить раздражающее мерцание, особенно заметное на одинаковых частях текста.

Причина, по которой это происходит, не уложится в один пост: это много-много математики цвета и режимов смешивания. Для такого у меня подготовлена вам целая статья: https://jakearchibald.com/2021/dom-cross-fade/

А фишкой же дня будет простое решение проблемы:

mix-blend-mode: plus-lighter;

И мерцания как не бывало. Особенно заметно на больших объёмах текста.

Пример: https://codepen.io/alinaki/pen/zYeVdgX

#css #blend #mix #color

#библиотека дня

Нужно ли вам представлять date-fns? Думаю, нет. Но всё же: это небольшая и весьма эффективная библиотека для работы с временем и датами. В отличие от (уже устаревшего) moment.js она не является монолитной и во многом опирается на современные API.

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

- операции с датами в честном UTC (и поддержка расширений класса Date)
- только именованные экспорты
- плоская структура модулей
- 100%-е покрытие типами TS (библиотека полностью переписана на TypeScript)

Полный список изменений и немного истории создания можно почитать в блоге разработчиков: https://blog.date-fns.org/v3-is-out/

#date #lib

#заметка дня

Почему-то так получилось, что на канале очень мало WebGL и я даже React Three Fiber не обозревал. Думаю, надо исправить.

Давайте сразу ссылку на демо из видео, а потом поясню, что к чему: https://nrzns4.csb.app/

Итак, для работы с производительной 3D-графикой у нас имеется WebGL. Но работать с сырым API никому не охота, поэтому вокруг него образовалась куча фреймворков, и наиболее популярный — Three.js.

А вот чтобы объединить React-приложение и сцену (так принято называть 3D-работы) — имеется интересная штука с названием React Three Fiber. В итоге можно с лёгкостью смешивать HTML, хуки, сцены и вообще любой код вместе.

Как-то так:

<Canvas camera={{ position: [0, 0, 20], fov: 15 }}>
  <Lens>
    <Background />
    <Words />
  </Lens>
</Canvas>

Кажется странным, но если вспомнить, что JSX это не что иное как вид вызова функций и передачи аргументов — и всё встаёт на свои места.

Давайте уже к разбору примера. Когда-то давно мой однокурсник забрал RedDot Award за сайт яичного протеина: https://minglabs.com/our-work/pumperlgsund/

Особый кайф был в бутылке, которая искажала текст за собой. Да, зная о том, что это "всего лишь" карты нормалей — магия уже не кажется такой магической, но менее интересным это не становится. И я подумал, было бы забавно повторить этот эффект на React Three Fiber, хотя бы на минимальном уровне.

Если имеется желание сразу перейти к коду, то вот: https://codesandbox.io/p/sandbox/lens-component-nrzns4

Компонент линзы — хотя больше похоже на донышко бутылки — создан Полом Хеншелем, мне же оставалось разобраться с тем, как его подключить и расставить текст и изображение.

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

Следующим шагом надо попробовать сделать портал, чтобы линза, например, работала как рентген. Или новогодний шар! Или параллакс.

В общем, давайте ваши предложения, котаны.

#webgl #3d #react

#инструмент дня

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

Вот он, CSS Selectors: A Visual Guide: https://fffuel.co/css-selectors/

Однозначно подойдёт даже опытным верстальщикам: освежить знания про ~, $= и удостовериться, что ты понимаешь :has — очень полезно.

Удобная навигация, иллюстрации, конечно, не Джош Комо и даже не Ахмад Шадид, но с задачей справляются :)

Кстати, https://fffuel.co/ в принципе очень большой проект с кучей разных инструментов для генерации интересных градиентов и паттернов. Точно стоит вашего внимания, котаны.

#css #education

#инструмент дня

Ладно, мы все можем согласиться, что у TypeScript замечательный офсайт, прекрасная документация и удобная песочница, но в мире есть сотни тысяч JS-библиотек и десятки тысяч из них либо написаны на TS, либо имеют выделенные типы.

А единой документации по этим типам нет!

Точнее, не было, но теперь вышел https://tsdocs.dev/

Это система поиска по существующим пакетам с типами. Она установит нужный пакет, распарсит типы и JSDoc и отобразит в удобном формате.

К слову, котаны, что вы предпочитаете по cmd- (ctrl)-click в редакторе? Прыгать к имплементации, или к типам?

Я вот — к имплементации, прыгать к типам меня раздражает.

#typenoscript #dts #types #doc

#инструмент дня

Есть категория инструментов, наиболее сильные в тех средах, которые все кругом ненавидят.

Это всяческого рода таблицы с CRUD- (Create-Read-Update-Delete) возможностями.

Несложно догадаться, что наиболее прокачаны они в разного рода энтерпрайз-фреймворках (на Java и C#), под общим названием GridView, в Sencha Ext JS и... в том же 1С.

Ну ещё бы бухгалтерская платформа не умела в таблицы.

Для веба их в целом огромное количество, но многие из них, как тот же Ext JS, разрабатывались последние лет 20, выросли в огромных слабо поддерживаемых монстров. Казалось бы, ну уж за столько времени можно написать что-то гибкое и универсальное? Да не особо. И ещё денег просят.

К счастью, прогресс не стоит на месте и у нас уже есть несколько прекрасных гридов. Одним из самых крутых, несомненно, является универсальный TanStack Table (бывший React Table): https://tanstack.com/table/v8

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

И пример такого рабочего грида мне на днях прислал подписчик: Material React Table.

Ссылка: https://www.material-react-table.com/

Как раз пару месяцев назад у них вышел новый релиз.

Если TanStack Query оставляет выбор UI-кита за вами, то MRT, как несложно догадаться, берёт за основу MUI (Material UI до версии 5) и добивает плюшками и полновесными примерами.

Отличная документация, готовый код прямо на главной странице. Имеется сравнение с конкурентами (куда ж без этого).

В общем, рекомендуем, котаны :)

#js #table #crud #grid

#фишка дня

Валидация форм в HTML, мягко говоря, раздражает. Я даже не буду начинать о том, что все встроенные способы валидации или выглядят уродливо, или имеют странную логику.

Тем не менее, браузеры пытаются и много лет назад у нас появились селекторы :invalid и :valid.

Как несложно догадаться, они целятся в поле ввода, не соответствующее критериям и соответствующее критериям соответственно. Например, required.

Я сел на книгу с каламбурами, простите.

Казалось бы, вот оно, счастье! Пишем что-то такое:

input:invalid ~ .invalid-message {
  display: block;
}

...и получаем сообщение о незаполненном поле!

Ага, хрен там.

Прикол того же :invalid в том, что пустое, не тронутое пользователем поле, изначально не удовлетворяет заданным условиям! И сообщение будет висеть сразу, раздражая всех.

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

Что же делать?

Потребовалось всего 6 лет ожидания, чтобы в Chrome и Safari, наконец, появилось то, что в Firefox было все эти годы: концепция грязных полей в виде селекторов :user-invalid и :user-valid.

Почему грязных? Потому что их потрогал пользователь! То есть, совершил ввод.

Кроме шуток, это буквально самый настоящий термин для библиотек обработки форм, вроде того же react-hook-form, или Angular.

Есть ещё концепция touched, когда ввода не было, но произошло событие blur.

Я, чувствую, мог запутать... Давайте сразу к делу. Если вы до сих пор не прошли по ссылкам, то вот сейчас самое время пойти в CodePen с примером, который показывает разницу: https://codepen.io/alinaki/pen/NWJPvPE

Согласитесь, это уже похоже на удобную валидацию, котаны!

#css #validation #required #forms

#релиз дня

Итак, котаны, что мы с вами пропустили?

А пропустили мы релиз Firefox 121!

Что в нём такого важного? Ну, как минимум, поддержка :has aka родительский селектор!

Конечно же, он не родительский, но то такое.

Теперь поддержка имеется во всех трёх движках, а это значит, что можно вовсю применять!

На что способен :has

1. Подсветка колонок: https://news.1rj.ru/str/htmlshit/2396
2. Анимация в стиле MacOS Dock: https://news.1rj.ru/str/htmlshit/1873 с полным разбором: https://news.1rj.ru/str/htmlshit/1876
3. Весёлая анимация букв: https://news.1rj.ru/str/htmlshit/1634
4. Когда вышел Chrome 105, разработчики разродились большой статёй: https://news.1rj.ru/str/htmlshit/1391
5. Джим Нильсен тоже не отставал: https://news.1rj.ru/str/htmlshit/1313
6. Зум на определённых частях изображения: https://news.1rj.ru/str/htmlshit/1206
7. Ну и шикарнейший тред от Веса Боса в Твиттере о десяти применениях новинки: https://twitter.com/wesbos/status/1737148340322652632

В общем, не переключайтесь. Будет ещё :)

#css #has #future