Фронтенд — это то, что видит и с чем взаимодействует каждый пользователь интернета, но как он работает на самом деле?

Одной из самых важных теоретических тем, понимание которой облегчает работу с библиотекой React является процесс рендеринга компонентов. Как React понимает, что пора обновить DOM-дерево? Как ререндеринг влияет на производительность и как ее улучшить? Что происходит под капотом React, когда мы решаем отобразить компонент на странице? Какую роль в этом всем играют хуки? Чтобы ответить на эти вопросы необходимо разобраться с такими понятиями, как рендеринг, жизненный цикл компонента, реконциляция, побочные эффекты и с некоторыми другими.

План статьи:

1) Рендеринг в контексте React

2) Жизненный цикл компонента

2.1) Mounting компонента

2.2) Update компонента

2.3) Unmounting компонента

3) Некоторые вопросы для самопроверки

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

Что же меня побудило перейти на Golang? В то время я сидел на Python ещё версии 2.7.9 — это примерно 2017 год. Потом вышла версия Python 3. Оказалось, что несмотря на множество обещаний, что теперь всё будет работать из коробки, начались дикие конфликты при переходе с 2.7 на новую третью версию. Я тогда немного разочаровался и начал смотреть, что ещё есть интересное, чтобы поработать с сетями. 

Под мои задачи всегда подходил Python. И в работе с Python я себя чувствовал примерно так: это огромная, очень добрая, очень хорошая, почти пушистая черепаха, но при этом ужасно неповоротливая. Очень тяжело с ней путешествовать, очень тяжело порой заставить её сделать то, что мне нужно. В то же время расширение PyPy разгоняло её очень сильно — условно, с 9 до 0,2 секунд.

Недавно я увидел вот этот трёхствольный колесцовый дротикомёт, который мюнхенский мастер Петер Пек изготовил в середине XVI века для Карла V. Под постом возникли характерные вопросы о практическом применении... Конкретно с этим предметом всё ясно, но пишу я не то чтобы ради него.

Привет, хабровчане!

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

А сейчас вот появилось -- решил демонстрации ради запилить Notion из рельсов и шпалок.

К постановке вопроса зачем мы вернемся, как это принято тут и у всех айтишников -- в самом конце, а сейчас к конкретике и без воды.

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

Однажды я выгорела. В пепел. В пыль. В труху. Степень выгорания Well Done. Сначала винила себя. Было стыдно за то, что не могу работать. Потом я пыталась найти решение проблемы. Пересмотрела, наверное, 100 видосов. Но все предлагали какую-то нерабочую фигню. В итоге помог мне один простой алгоритм.

Сейчас разберу его по полочкам :)

Если вам лень читать, можете посмотреть мой видосик на эту тему

В девятнадцатом веке миниатюрные водяные турбины были подключены к крану, и могли приводить в действие любую машину, которая сейчас приводится в действие электричеством.

Что такое One Million Checkboxes?

_{Этот пост в оригинале (eng) https://www.setproduct.com/blog/dark-side-of-figmas-updates}

Глава 1: В какой‑то момент всё пошло не так

Смотря недавнюю конференцию CONFIG24, я не мог избавиться от неприятного зуда.

Чем сильнее зуд одолевал меня, тем больше приходило осознание – приоритеты Figma сместились с улучшения сервиса на увеличение прибыли.

Я неустанно задавал вопросы:

Что произошло с Figma, которую мы все так горячо любили?
Почему в приоритете деньги, а не список фич от пользователей, которые мы просим?
И если Фигма - ФСЁ, то что это сулит дизайн-инструментам в будущем?

Провал сделки с Adobe, похоже, стал переломным моментом.

Фокус Figma на создании функций с использованием искусственного интеллекта для увеличения количества пользователей - крутой поворот от первоначальной концепции сервиса.

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

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

Почему-то про эту «фичу» не любят распространяться опытные коллеги, а первая встреча с таким в вашем проекте гарантирует бессонные ночи и разбитые об стенку лбы и клавиатуры. Читайте и берегите нервы, говорят они не восстанавливаются.

Как я познакомился с Мурмулятором? Я искал какой-то недорогой одноплатный компьютер для запуска эмуляторов ретро-компов.Чем меня не устраивало использование эмуляторов на "настоящем" компьютере? Ничем. Просто хотелось отдельное устройство. Я рассматривал вариант покупки старого ноута специально под эту задачу, потом смотрел на Raspberry Pi 400, Orange Pi и на прочие одноплатники. В процессе поисков я наткнулся на видео самостоятельной сборки оригинального одноплатника с бюджетом в $5. Понятно, что впоследствии я в эту сумму и близко не вложился, но данное изделие меня всё-таки зацепило. Вот так у меня и появился первый ZX Murmulator.

После нескольких лет веб разработки хочу поделиться с вами историями и своим опытом, делая при этом полезные (или не очень) выводы.

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

Шоколад, разработанный в престижном Федеральном технологическом институте Цюриха учёным Кимом Мишрой и его командой, включает в себя мякоть плодов какао, сок и шелуху, или эндокарпий. Этот процесс уже привлёк внимание компаний, производящих экологически чистые продукты питания.

▍ Если ты (или твоя команда) постоянно стреляешь себе в ногу, то почини ружьё

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

Неважно, верстаете ли вы сайт для малого бизнеса или создаёте супермодное React приложение. Они поддерживаются большинством браузеров. Отдельно отмечу, что я не считаю IE11 современным браузером. По этой причине я не учитывал его.

Сегодня мы рассмотрим:

• сброс стилей до значений, взятых из веб-стандартов;
• возврат значений свойств, установленных в браузере;
• что можно сделать с прыжками контента при открытии и закрытии модального окна;
• возможность отобразить текст «красиво» с помощью ключевого слова system-ui;
• способ стилизации элементов на языке, отличающимся от основного.

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

Хочется вспомнить SOLID принципы и рассмотреть, как можно их применять в разработке интерфейсов на примере React компонентов.

S: Single Responsibility Principle (Принцип единственной ответственности). Означает, что каждый класс/функция/компонент должны выполнять только одну конкретную задачу.

На примере React компонента: компонент, который отрисовывает пользовательский интерфейс, не должен содержать в себе логику авторизации этого пользователя.

O: Open-Closed Principle (Принцип открытости-закрытости). Означает, что класс/функция/компонент должны быть открыты для расширения, но закрыты для модификации. Чтобы их можно было расширять новым функционалом, не изменяя при этом исходный код.

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

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

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

Начитавшись некоторых книг, у меня начал немного проясняться сюжет игры. Сначала я хотел сделать игру про 80-е в Америке. Для этого я задумал сделать свою операционную систему, компилятор и разные программы. Уже насоздавал некоторые модели в blender, скачал документацию по i386, распечатал, и начал изучать. В этой документации ещё предлагалось почитать руководство по системному программированию для i386. Я скачал, сходил в салон, мне сделали книгу-брошуру.

Первоначальная цель была делать ОС, эмулятор и компилятор. Я понимал, что просто так сложно будет за это взяться, так как эмоциональный интеллект у взрослого человека требует какое разумное объяснение тому, чем ты должен заниматься. Поэтому создание ОС, эмулятора и компилятора я решил делать в рамках игры. Так общественность бы не сильно давило вопросами, - зачем это нужно. Да и мне эмоции подсказывают, что это правильное решение.