Ботаню реактушку. Написал на React один небольшой проект в прошлом году, но сейчас хочу углубиться. Как изучаю?

1. Читаю книгу. Книга хорошая, хотя перевод неидеальный и в паре мест вижу ошибки/опечатки, но они очевидны и не вводят в заблуждение. Понравилось, что в начале книги есть глава про то, что появилось в ES6. Так-то на JS я и в древнем году 2009м вполне программил, но за новшествами с ES2015=ES6 плотно не следил. Освежить было полезно. Про функциональное программирование, чистые функции, императивный и декларативный подход — написано хорошо.

Принцип выбора книги — ищу то, что есть, смотрю отзывы, смотрю оглавление. В идеале мне нравится поехать в большой книжный и там полистать книгу перед покупкой, чтобы купить то, что понравилось. Эта книга у меня есть в бумаге и я листал её перед покупкой, хотя сейчас читаю с цифры, так как бумажная версия не со мной. Читать с айпада — ок. Но интернет на планшете может отвлекать, иногда стоит отключить.
#IT #frontend #books #javascript #interesting

2. Использую на айпаде приложение GoodNotes для заметок по ходу чтения. PDF с книгой там же подгружен. Удобно. Хотя он по-моему платный и возможно сейчас с продлением будут проблемы, не знаю. Можно писать и на бумаге в блокноте, важно, чтобы самому было приятно вести этот процесс, пусть это будет хороший блокнот или тетрадь и удобная ручка.

Почему пишу от руки, а не набиваю? Есть мнение, что так запоминается лучше, когда ручкой/стилусом пишешь, это как-то иначе воздействует на мозг. Когда изучал Python, вел заметку в Evernote, выписывая основные структуры данных и языковые конструкции.

3. Читаю официальную документацию. У реакта она сейчас а) хороша б) переведена на много языков, в том числе на русский. Действительно отличная документация, во всяком случае для изучения библиотеки.

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

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

По PHP неплохая дока была благодоря тому, что по любой функции можно получить доступ сразу по урлу — например, хочешь посмотреть доку/примеры по функции strip_tags, пишешь php.net/strip_tags и попадаешь сразу на доку по этой функции. Не надо гуглить или пользоваться поиском по сайту. И помимо доки внизу комменты с рейтингом, там многое можно было почерпнуть. Хорошая дока.

И вот по React хорошая дока с точки зрения изучения библиотеки, стоит почитать.

4. Смотрю большой материал на freeCodeCamp. Не уверен, что посмотрю его весь, но смотрю по наличию времени в отрыве от книги и доки, где-то на нормальной скорости, где-то на 2x. Вообще ютуб на 1.5-2x это отличное изобретение.

5. Буду читать чужой код и общаться с коллегами.

Резюмирую — использую все возможные каналы получения информации. Кто-то говорит, что изучить новую технологию это просто вот тут что-то в одном месте почитать и сразу молодец. Я так не думаю. Надо посмотреть/почитать много где, сопоставить полученную информацию, уложить её в голове и на практике. Тогда всё устаканится хорошо и важное отфильтруется от менее важного.
#IT #frontend #books #javascript #interesting #rust

Решали сейчас с коллегой вопрос по интеграции кода в Тильду. Кто не в курсе — это такой SaaS конструктор сайтов, приятный в простом использовании, но в вопросах интеграции чего-то на фронтенде не всегда очевидный. Детали реализации фронта не документированы, сервис не расчитан, что кто-то будет на фронтенде его логику с JS дорабатывать.

Задача была навесить свою JS логику сразу после отправки данных на сервер и отображения некоторого div'а. Этого div'а в момент начальной отрисовки страницы в дереве нет. Когда и кто его добавляет в DOM? Надо изучать их код, чтобы ответить.

Но в качестве быстрого решения можно воспользоваться хаком с MutationObserver. Это способ отслеживать все изменения DOM элементов внутри указанного элемента, которым может быть и body. Когда происходят изменения внутри отслеживаемого элемента — вызывается твоя функция и ты проверяешь в ней, показан ли сейчас нужный тебе элемент. И не надо разбираться с деталями реализации кода сайта, в который ты интегрируешься. Удобно. Минус — на каждое изменение отслеживаемого элемента вызывается твой код. Не стоит отслеживать так изменения больших и часто меняющихся узлов DOM дерева.

Накидал демку

#frontend #javascript #IT

Пришлось поковырять Тильду еще сейчас. Выяснили, что в процессе построения страницы они создают DOM элементы, потом подчистую их удаляют и создают снова.

Тильда, да ты ж моя няшечка, да кто ж тебя научил так делать-то:)

Удаление/добавление элементов в DOM — дорогие операции и современный веб (ну как современный, уже лет ~10 как, наверное) идет в сторону оптимизаций и уменьшения количества таких операций.

Мда. Технологически хороший продукт и коммерчески успешный продукт — это часто совсем не одно и то же. Не то чтобы Тильда технически плохой продукт, но есть куда стремиться. Сидят же там разработчики, денежку получают за JQuery лапшу свою в 2022м-то.
#frontend #IT #javascript #codebetter

Навигация по постам в канале

🍒 #IT — всё, касающееся айтишечки нашей
🍒 #backend — о бэкенде
🍒 #frontend — о фронтенде
🍒 #linux — о Linux, администрировании и смежных темах
🍒 #python — о языке Python
🍒 #javascript — о языке JavaScript
🍒 #typescript — о языке TypeScript
🍒 #css — о CSS
🍒 #rust— о языке Rust
🍒 #db— о СУБД
🍒 #codebetter — о хороших подходах в программировании
🍒 #tools — об инструментах
🍒 #tests — об тестировании ПО

⚡#LMS — о нашей LMS системе для образовательных программ

🌶 #youtube — мои видео на YouTube
🌶 #course — о моём курсе

🍉 #softskills — о софт-скиллах и личной эффективности
🍉 #books — о книгах

🍷 #interview — где-то что-то кому-то комментирую
🍷 #news — что-то касается новинок/новостей
🍷 #interesting — что-то интересное, не обязательно ИТ
🍷 #gg — гыгы

🍓 #management — о менеджменте
🍓 #marketing — о маркетинге

🥝 #soulful — душевное

Ы!

Попиваю свой ночной тегуаньинь и читаю по TypeScript. Понавыдумывали майкрософтовцы, конечно. Но в целом получилось мощно. Костыли, ну или ладно-ладно, особенности JS лезут, разумеется, но от них уже не избавиться, просто надо их иметь в виду. Null, undefined, NaN и прочее.

Что по своему опыту рекомендую прочесть по TS тем, кто хочет начать писать на нём.

Сначала это. Затем это. Затем это. И только потом это.

Прочел ещё треть этой книги. Шутеечки понравились, а по теме не очень. Автор русскоязычный, Борис «бритва» Чёрный:), но писал явно на английском, редактор и переводчик постарались: непереводимое переведено, щедро рассыпаны опечатки, несколько раз перечитываешь, смысл не проясняется. А может и исходник такой. Или, возможно, надо читать, уже поработав с TS, тогда будет понятнее и опечатки бросаться в глаза не будут.

TS хорош. Типизация рулит. Читая, ловил себя на мысли, что вот такое объяснение можно перенести и в мой материал по типизированному Python. Надо обновить:)

#it #backend #frontend #typescript #javascript #books

Господа фронтендеры, используете БЭМ в связке с CSS Modules?

С одной стороны, одной из решаемых БЭМ проблем была изоляция имён CSS-классов во избежание коллизий; и CSS Modules решает эту проблему по умолчанию, т. к. классы каждого компонента изолированы. В таком контексте БЭМ не нужен, если используешь CSS Modules.

К тому же блок в терминологии БЭМ это как правило и есть компонент, а всё, что внутри компонента это как правило элементы с редкими модификаторами. В итоге это приводит к тому, что просто все CSS-классы компонента начинаются с имени этого компонента, что кажется избыточным. Мы и так находимся в отдельном CSS этого компонента, нет смысла каждый его класс начинать с имени компонента, это едва ли положительно сказывается на читаемости CSS.

С другой стороны, в каких-это сценариях БЭМ и в связке с CSS Modules улучшает читаемость и структурированность кода. Модификаторы, например, в этом помогают. Или использование блока как элемента, когда блок=компонент переиспользуется в другом блоке=компоненте и ему задаются отступы и положение на странице как элементу. Улучшает читаемость, думаю.

Отказаться от Б в БЭМ?

А styled components (css in js) мне чёт не нравится. Давайте сюда ещё PHP добавим с SQL, чего по файлам прыгать:)

#IT #frontend #javascript #typescript #css

Понимаю, что здесь в основном backend спецы и вижу, что посты про frontend не заходят, но всё же буду писать и про frontend, потому что занимаюсь им сейчас, да и собственно почему бы и нет:)

Наткнулся на такой прекрасный бенчмарк frontend JS фреймворков. А ещё вот на такой ресурс, собирающий статистику по состоянию JS каждый год.

И вижу (неожиданно для меня) любовь сообщества к библиотекам Svelte и Solid, а также их эффективность. 90% удовлетворённость разработчиков по 2021му году у обоих, для сравнения React 84%, Vue 80%.

Svelte и Solid представляют собой исчезающие фреймворки, то есть в рантайме в браузере нет или почти нет кода самого фреймворка, нет виртуального DOM и вся работа ведётся с DOM реальным. Сколько бы React ни выпендривался этим своим чудодейственно эффективным обновлением DOM дерева и движком Fiber, подходы без виртуального DOM показывают, кто тут батя.

В бенчмарках можно выделить интересующие фреймворки и сравнить в разных сценариях. Выделил Solid, Svelte, React в разных связках, Vue. И чёт React всегда справа и не сильно зелёный:) Vue посередине, Solid всегда слева и зелёный. Svelte тоже слева и тоже почти всегда зеленый. А React чаще желто-красный, то есть его показатели отстают от собратьев.

Доверять бенчмаркам дело, конечно, такое — но всё равно интересно.

Кстати, Solid — практически копия React с его JSX и хуками. Потому вероятно и заходит разработчикам, ибо знакомый и привычный подход, но зато маленький бандл, высокая скорость обновления UI и меньше жрёт RAM (приветы виртуальному DOM).

#IT #frontend #javascript #typescript

Читаю сижу про Solidjs. Бодрая штука. Разрабатываем тут одну хитрую большую систему, о которой расскажу вам позже, по фронтенду готовы несколько первых экранов — и, думаю, днём перетащу их с реакта на Solid🙄

Если всё пройдёт ок, сделаю материал по нему. Кажется, это реакт здорового человека.

#frontend #IT #javascript #typescript

Уууууу что я нашёл!

https://github.com/gothinkster/realworld

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

Например, интересно вам, как выглядит бэкенд такого проекта на Rust'овском Actix с Diesel ORM? Пожалуйста. Или на Rust'овском Rocket? Лови. Или на чистом Go? Есть и такое. FastAPI? Получай. На C++ (стрелять-колотить, почему нет) — на-ка!

Аналогично и по фронтенду. На Solidjs вот, например.

#it #backend #frontend #python #rust #javascript