JavaScript *

Технология css-in-js существует уже довольно давно. Ещё в начале своего профессионального опыта я встречал подходы, в которых стайлинг локальных частей интерфейса пробрасывался в html через javascript в виде css директив. Иногда это необходимая мера, хотя необходимой она случается изредка, но раз в год, как говорится, и палка стреляет. У меня на опыте был пример построения раздела интерфейса, в котором устанавливаемое на сайт пользователя модальное окно можно рестайлить через кодовый редактор с live preview. css-in-js бывает оправдан, поэтому хочу сразу оговориться - хоронить никакой подход не стоит. Но и идеализировать его как универсальную пилюлю тоже не надо. Рендер стилей, привязанный к логике рендера компонентов в контексте всего проекта - это просто свой путь со своими приключениями, появившийся на мой взгляд в общей психопатии привязывать к state всё что только можно. Что если посмотреть - откуда взялась эта техногогия? На сегодняшний день на рынке проектирования интерфейсов сложился монополист react, диктующий программистам свои правила игры, и который даже без использования styled модуля имеет в себе простейщую инверсию управления cssInJs.
React - важный персонаж в этой теме. Он, словно useEffect всего современного front-end - стал центром силы, средоточием зла в виде голого state management, не предусматривающего из коробки ничего иного.

Как мы все знаем, в React есть функциональные и классовые компоненты. Каждый вид имеет свои плюсы и минусы.

Классовые компоненты имеют меньшую производительность по сравнению с функциональными и вызывают некоторые сложности в переиспользовании одинаковой логики.

Node.js это кроссплатформенная среда выполнения JavaScript с открытым исходным кодом для выполнения JavaScript вне браузера. Он поддерживается движком Google V8, что делает его чрезвычайно производительным.

Асинхронная среда выполнения, управляемая событиями

Одно из наиболее распространенных утверждений, с которым мы сталкиваемся при знакомстве с Node, заключается в том, что он выполняется в одном потоке. Тем не менее каждый может задаться вопросом, как это возможно, что Node является одним из самых популярных инструментов для создания быстрых и масштабируемых API?

Технически, тот факт, что Node.js использует один поток не на 100% верно. Node.js на самом деле использует много потоков, но цикл событий (Event Loop - о котором мы упомянем позже), и пользовательский код выполняются в одном потоке. Если мы ознакомимся с документацией, то увидим, что Node.js использует управляемым событиями неблокирующую модель ввода-вывода (event-driven, non-blocking I/O model), которая делает его легким и эффективным.

Что такое управляемая событиями неблокирующая модель ввода-вывода?

Согласно руководству по Node.js, блокирующие методы выполняются синхронно, а неблокирующие методы выполняются асинхронно. Предположим, что нам нужно написать некоторый код, чтобы прочитать содержимое файла и распечатать его в консоли. Есть два способа сделать это в узле: синхронно и асинхронно.

Давайте сначала посмотрим синхронную версию:

В приведённом ниже коде происходит следующее: во-первых, нужно подключить модуль FS. Во второй строке вызывается метод readFileSync, и результат сохраняется в переменной data. Основной поток Node.js блокирует эту строку до тех пор, пока не будет прочитано все содержимое файла. Затем содержимое выводиться в консоль, и, в самом конце будет выведено в консоль “Done”.

Когда нужно делить фронтенд-часть приложения на микросервисы? Какой стек использовать? И какие стандарты использовать, чтобы не выстрелить себе же в ногу при переходе на микрофронты? Михаил Трифонов (Lead Frontend в компании Cloud) ранее уже выступал с докладами о микросервисах, получил фидбек от сообщества и с его учётом сделал новый доклад на HolyJS. А теперь мы (организаторы HolyJS) сделали для Хабра текстовую версию этого выступления.

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

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

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

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

В данной статье мы рассмотрим настройку ESLint и Prettier для JavaScript, TypeScript и в частности для Vue.js, покажем какими правилами мы руководствуемся в проекте Shtab и почему.

Всем привет! Меня зовут Аня Ланда, я фронтенд-разработчик в Самокате. В компании я больше двух лет, общий стаж во фронтенде – 6 лет и всё это время я делаю таблицы. В этом посте расскажу про эволюцию подходов к работе с ними, что меняется на пути от нескольких сотен до сотен тысяч элементов в таблице.

На примере простой задачи клонирования ключей объекта посмотрим, есть ли реальные альтернативы по производительности столь презираемой JavaScript-разработчиками функции eval().

Подобная задача возникает, если оригинальное значение ключа надо оставить у объекта, а как-то обработанное - положить рядом в новый соответствующий ключ. То есть, для начала, из {"a" : 1, "b" : 2} надо получить {"a" : 1, "a-copy" : 1, "b" : 2, "b-copy" : 2}.

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

И трам-парам как по-фолшебству, как в новогоднюю ночь, проявился код. Я подумал ведь можно же управлять состоянием приложения на React используя всего один дополнительный хук!

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

По сути в этой публикации речь пойдет о функции done() в jest. Функция очень полезная, так как позволяет разработчику решать в какой момент будет закончен тест. Бывают ситуации, когда это действительно очень нужно. В новом проекте я столкнулся с такой задачей и решил просто описать то, как я её решил.

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

Я дергаю ChatGPT так часто, что меня стало раздражать копировать текст, который я хочу отредактировать, открывать новую страницу chat.openai.com и вставлять его туда, писать свой запрос, получать ответ модели, а затем копировать и вставлять его обратно туда, где он был мне нужен изначально. Именно поэтому мы с друзьями сделали расширение для Chrome, которое позволяет решать задачи без лишних действий и переключений вкладок.

Кому интересны детали, прошу следовать за мной!

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

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

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

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

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

Речь не идет о каком-либо виде "взлома" или о создании повышенной нагрузки на сайт. Мы будем автоматизировать то, что и так можно сделать вручную.

Продолжим строить подобие JSON-RPC сервера, начатого в части 1 и анализировать его плюсы и минусы. В прошлой статье был описан механизм отделения бизнес логики бэкенда от транспортного протокола (HTTP) через шаблон проектирования "Front Controller", роль которого исполняет в нашем случае JsonRpcController.

Бэкенд API до передачи запроса в код, отвечающий за бизнес логику, обычно предоставляет частичный функционал API шлюза (API gateway) - он может делать аутентификацию, авторизацию, роутинг, валидацию данных, логгирование, кэширование, обеспечивать меры безопасности и другое.

Идея этой демонстрации пришла из игры Session Skate. В начальных титрах «SESSION» каждая буква быстро исчезает. Это выглядело довольно круто, и я сразу понял, что могу сделать это с помощью view-transition, setInterval() и .textContent. Итак, я завёл себе задачу в todo, чтобы сделать это, потому что пришло время заняться фигнёй, а не работой.

Привет, друзья!

В этой статья я немного расскажу вам о Bun — новой среде выполнения JavaScript-кода.

Обратите внимание: Bun — это экспериментальная штуковина, поэтому использовать ее для разработки производственных приложений пока не рекомендуется.

К слову, в рейтинге "Восходящие звезды JavaScript 2022" Bun стал победителем в номинации "Самые популярные проекты".

Интересно? Тогда прошу под кат.

В прошлой заметке я представил общественности шаблон проектирования Мейоз, как способ управления состоянием одностраничного javascript приложения. Шаблон не связан с конкретной библиотекой рендеринга, и опирается исключительно на небольшую функцию stream и нативную реализацию объекта Array в javascript.

Идея шаблона заключается в использовании streams (потоков) для хранения состояния приложения, глобального или локального (например состояния html формы), связывания, свертки и комбинации потоков в функциональном стиле. Шаблон предлагает использовать определенные реактивные структуры данных, но не обязательно буквально так как это делает автор. В рамках шаблона можно реализовать любое удобное и понятное поведение приложения.

В этой заметке я перепишу небольшое приложение "Кубики", и вместо библиотеки mithril для рендеринга будем пользоваться reactjs. Будем использовать потоки для управления глобальным и локальным состоянием, а так же, сервисы — объекты, определяющие функции, которые выполняются всякий раз, когда изменяется состояние.

Всем привет!

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

А что если я расскажу как это можно сделать быстро и просто?

Однажды я захотел создать небольшую NPM библиотеку по всем “best practices” - с покрытием тестами, написанием документации, ведением нормального версионирования и changelog'а и т.п. Даже написал пару статей, которые в деталях описали, какие вопросы решает библиотека и как её использовать. И одной из интересных для меня меня задач при создании библиотеки была задача по максимальному уменьшению размера выходного NPM пакета - того, что в конечном итоге в теории будет использовать другой программист. И в этой статье я бы хотел описать, к каким методам я прибегал для того, чтобы достигнуть желанной цели.