Ихрь постит в уютный бложик: заметки с тегом javascript

How to inline TailwindCSS styles to SSR NextJS

Wed, 04 Oct 2023 11:54:42 +0300

By default, NextJS may not include Tailwind styles in the SSR build, and with disabled JavaScript, your site may look ugly like pure HTML.

To fix this, you need to install the critters package.

npm install critters

And enable optimizeCss rule in next.config.js.

experimental: {
    optimizeCss: true,
},

Source: next.js#12868.

How to fix unknown fragments types in graphql-codegen?

Wed, 15 Feb 2023 23:05:44 +0300

I spent half of the day setting up graphql-codegen to generate the correct types for fragment queries.

At first, my code looked like this:

// file1
export const DIALOG_FIELDS = gql(`
  fragment DialogFields on Dialog {
    id
    name
  }
`);

// file2
export const GET_DIALOG = gql(`
  ${DIALOG_FIELDS}
  query GetDialog($dialogId: ID!) {
    dialog(id: $dialogId) {
      ...DialogFields
    }
  }
`);

const config: CodegenConfig = {
  schema: CONFIG.apiHost,
  documents: ['src/**/*.{tsx,ts,js,jsx}', '!src/gql/__generated__/*.ts'],
  generates: {
    './src/gql/__generated__/': {
      preset: 'client',
      plugins: [],
      overwrite: true,
      presetConfig: {
        gqlTagName: 'gql'
      }
    }
  },
};

So, with the basic config I did get an unknown type for both the query and the fragment:

I found a simple solution for this — we need to remove the string interpolation for the fragment literal from the query, because graphql-codegen automatically includes fragments.

export const GET_DIALOG = gql(`
  query GetDialog($dialogId: ID!) {
    dialog(id: $dialogId) {
      ...DialogFields
    }
  }
`);

As a result, I did get an not unknown type, but the type with no data from the fragment for the query fragment.

I lost the most time at this stage, eventually finding a solution in the small GitHub thread. We need to disable fragment masking feature.

const config: CodegenConfig = {
  schema: CONFIG.apiHost,
  documents: ['src/**/*.{tsx,ts,js,jsx}', '!src/gql/__generated__/*.ts'],
  generates: {
    './src/gql/__generated__/': {
      preset: 'client',
      plugins: [],
      overwrite: true,
      presetConfig: {
        gqlTagName: 'gql',
        fragmentMasking: false
      }
    }
  },
};

Finally the type contains all the information and it is complete!

Про дебаг в старых Safari

Wed, 01 Feb 2023 18:01:23 +0300

Знаете, что самое веселое в фронтенд-разработке после похорон IE?
Дебажить приложения под Safari старых версий — это просто нереально...

Как я делал с IE? Качал виртуалку с сайта MS с нужной версией IE и спокойно дебажил.

Как я делаю с Safari? Ищу образ виртуалки, их же официально никто не распространяет, а ушлые ребята распространяют образы только через Patreon, WTF?

На ноут я не могу поставить виртуалку со старой Mac OS, потому что у меня ARM процессор. На ПК я не могу поставить потому, что у меня там процессор AMD, а почему-то на новых AMD виртуалки как-то криво инструкции транслируют.

В итоге приходится искать макбуки на Intel, на них ставить виртуалку со старой ОС и там дебажить — во житуха!

Изначально писал в телеге — тык

Как babel-плагин замедлил приложение в 2 раза

Thu, 04 Mar 2021 19:11:13 +0300

TL;DR: в @babel/plugin-transform-classses есть баг, который вызывает падение перформанса.

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

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

С ними в проекте недавно была проведена работа по дедубликации лок-файла и дерева зависимостей, вместе с чем обновились некоторые библиотеки. Минус 7000 строк лока, разбор проблемы обещал быть веселым.

Проблему искал сначала мой коллега, затем я. Не знаю, сколько времени на это было потрачено, но причиной оказался один плагинчик — @babel/plugin-transform-classses. Откатил версию, зафиксировал ее, и все заработало.

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

Как оказалось, с 1 апреля 2020 года в репозитории есть репорт этой проблемы — babel#11356.

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

В нашем случае замедление было в среднем в 2+ раза. Некоторым повезло меньше, после обновления Angular можно поймать и более ощутимые просадки.

В очередной раз поймал себя на мысли, что в 2021 году babel уже не нужен. Пора начать выпиливать его из проектов!

Сейчас придумал теорию заговора, что babel так с адептами ООП борется просто.
Как там было? Если хочешь, чтобы перестали использовать deprecated метод, добавь в него sleep.

Ошибки state-менеджмента React-компонентов

Mon, 15 Jun 2020 19:01:52 +0300

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

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

Это было проблемой, но решалась она быстро. С появлением хуков ситуация ухудшилась.

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

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

const component = ({ prop }) => {
  const [savedProp, setSavedProp] = useState(null);

  useEffect(() => {
    setSavedProp(prop);
  }, [prop]);
};

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

Эффект, который слушает изменения стейта, чтобы… вызвать коллбэк.

const component = ({ prop, onPropChange }) => {
  const [savedProp, setSavedProp] = useState(null);

  useEffect(() => {
    onPropChange(savedProp);
  }, [savedProp]);

  return (
    <Child prop={prop} onPropChange={setSavedProp} />
  )
};

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

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

Проблема FrontOps’а

Sun, 07 Jun 2020 18:59:53 +0300

TL;DR

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

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

Дисклеймер: По теме я не раз говорил на митапах Webpurple, но структурировать все в текст так и не вышло нормально. Пост — просто изливание кучи мыслей, не структурирован, хотя планировалось нечто большое на несколько иную тему, в черновиках лежал больше, чем полгода, но, как говорил Тим, надо признаться, что черновики не допишутся и публиковать как есть, вот публикую. Ниже все исключительно ИМХО.

Повествование я начну как обычно — с небольшого отступления в прошлое. Когда я начинал работать как разработчик, я никогда не был против задач не для разработчика (как сейчас считается): сервер настроить, сконфигурировать прокси, сборщик из пачки sh-скриптов подкрутить, еще что-то. Да, эти задачи я решал постольку-поскольку, не использовал всякие крутые штуки и инструменты, до поры до времени ни про вагрант, ни про ансибл не слышал, но задачи решал и мне в целом нравилось.

Что касается специализаций и развитий навыков, я приверженец T-shape подхода: в основном я фронтендер, но и в DevOps с бэкендом могу. Вот благодаря этому пересечению с девопсом я гордо могу назвать себя FrontOps’ом.

Появление FrontOps

Вторая часть слова — Ops. Когда говорят про Ops, вспоминается DevOps. Несколько обидно, что почему-то в DevOps не всегда включают FrontEnd, ~~шутка про формошлепов~~ на это есть свои причины, но начнем с того, что такое DevOps.

DevOps — методология взаимодействия специалистов по разработке (Dev) со специалистами по информационно-технологическому обслуживанию (Ops) и интеграцию их рабочих процессов друг в друга для обеспечения качества продукта.

Wikipeadia — DevOps

В диалогах я слышал что-то вроде: «Какие еще оперейшены во фронтоне?! Че там оперировать, статика же?», — наверно, поэтому как-то это все в отдельное направление и выделилось местами. Изначально, девопс — это больше про бэкенд и все, что около него, как-то так сложилось исторически, во всяком случая я чаще сталкивался с таким, что в рамках девопс-процессов о фронтенде никто особо не думал, и это как-то само должно было решаться. Ведь что нужно бэкенду? Кластер серверов, лоадбалансинг, умный деплоймент с нулевым даунтаймом, скейлинг и много всего сложного и интересного. А что на фронтенде обычно было? Отдать статику (часто через тот же бэкенд) и все, но сейчас времена другие.

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

Проблема FrontEnd ~ Ops

Create... а дальше?

После того, как код написали, с ним еще много интересного происходит до того, как он начнет решать задачи пользователя и бизнеса, да и в процессе выполнения этих задач интересное не заканчивается. На бэкенде, разработчики в большинстве своем представляют, что с кодом происходит, после того, как он скомпилировался, так как по-другому там жить довольно сложно, надо все-таки понимать, кто там jar’ник запустил и какие и куда пакеты летают, бэкендерам даже надо понимать, что такое TCP, например (!!!).

В мире фронтенда ситуация несколько иная. На один мой комментарий в ревью «этот код не соберется вот по этой причине, вот линк, почитай, интересная штука» мне отвечали «я простой разработчик, это меня не касается» (утрирую, но примерно так было). WTF? В тот момент я понял, что что-то не так.

Откуда растут ноги этой проблемы? Из времен, когда разработка фронтенда заключалась в запуске сервера статики (и то не всегда) и изменения файликов, которые тут же отображаются в браузере, а деплой заключался в том, чтобы отдать файлики бэкендерам, а они там в jsp перегонят и сами разберутся, или загрузить файлики через FTP на другой сервер. Просто, круто, DX на высоте, код написал и все.

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

`git clone` — оп, код у меня;
`npm install` — ну, зависимости у меня, погнали;
`npm start` — ммм, *клик-клац-клик*, все, написал;
`git commit -a && git push` — отлично, таску в резолв.

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

Вроде бы задача понятна, но для многих разработчиков фронтенда она нерешаема по одной простой причине: они слишком отдалились от инструментов разработки и не успели подстроиться под их изменения, да и думать об этом часто не нужно, и «вообще пусть это девопсы делают, оперейшены все-таки». Но откуда девопс-инженерам знать о том, как код должен собираться вебпаком? А тем более о всяких узких местах, типа хранений шрифтов на том же домене, чтобы лишний dns-запрос не делался?

Много разработчиков на C++ вы знаете, которые не понимают, как линкуются библиотеки и не могут написать make-файл? А фронтендеров таких много, и это часто не проблема фронтендера, да и не проблема это, просто у нас много инструментов, которые легко устанавливаются и все делают сами.

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

Решаем проблемы

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

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

Если вы не понимаете этого, изучите проект и инструменты, которые в нем используются, почитайте документацию к ним, спросите более опытных тиммейтов, сделайте собственный стартер или пет-проджект, накрутите там крутой CI/CD, оптимальную сборку.

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

Инструменты, о которых нужно иметь представление

Вебпак, бабел, бандлеры, таск-раннеры (Webpack, Babel, npm-scripts, Gulp) — изучите принцип работы сборщиков и компиляторов JavaScript, TypeScript, CSS, поймите разницу между Rollup и Webpack, изучите возможности npm-scripts и Gulp (хоть его и мало кто использует сейчас).
Форматтеры, линтеры, статические анализаторы (ESlint, Prettier, stylelint, SonarQube) — хватит спорить на ревью о том, где должна стоять запятая, хватит мутировать иммутабельные значения, автоматизируйте проверку этого.
Git и хуки (Husky, lint-staged, Learn Git) — изучите Git, для вас не должны быть проблемой ребейзы, которые заканчиваются конфликтами, используйте хуки для автоматического запуска проверок.
Тестирование (Jest, Mocha, Jasmine, Cypress) — изучите инструменты тестирования, способы их использования, виды тестов.
Дополнительные инструменты для проверок проекта (size-limit, Lighthouse CI) — проверяйте перформанс-метрики вашего проекта прямо на этапе непрерывных интеграций.
CDN, файлы, сервера и прокси (nginx, S3, CloudFront, Cloudinary) — изучите, как файлы могут храниться и раздаваться.
Мониторинг (Amplify, Sentry) — настройте мониторинги, отслеживайте, что происходит с кодом при использовании.
Деплой, сервера, докер (Ansible, Docker, SSH) — изучите подходы к деплою, варианты запуска приложений, научитесь работать с SSH и консолью — это действительно нужный навык.
CI/CD (GitLab CI) — изучите принципы и подходы к организации CI/CD, сделайте полезный пайплайн для своего проекта или оптимизируйте существующий.

UI library based on Chakra-UI bundling

Thu, 09 Apr 2020 18:49:15 +0300

Recently I tried to build some UI components library that based on Chakra-UI. At first my library didn’t contain react components and compiled using typescript and it worked perfectly. But after I added React components based on Chakra-UI and migrated build to webpack, I’ve got the next error from react hooks that were called inside Chakra-UI hooks such as useTheme:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.
By the way, Chakra-UI repository has this issue about this error - ((https://github.com/chakra-ui/chakra-ui/issues/495 #495)).

What is the reason for this error? useTheme hook and Chakra-UI library in whole use react library. As a result library imports react and react-dom. When webpack bundling your library that includes Chakra-UI, it includes react and react-dom to bundle of your library. In brief, you import react to your project, also you import your library with Chakra-UI that contains react too, as a result — you have at least two React copies. And in fact, it’s incorrect hook call.

How to fix it? Use only single react instance in your app. If you’re using webpack you can mark react and react-dom libraries as external libraries for your components library:

externals: {
  // mark "react" and react-dom as external packages that will import using commons
  react: 'commonjs react',
  'react-dom': 'commonjs react-dom'
},
output: {
  path: path.resolve('./'),
  libraryTarget: 'commonjs2', // set library target
  filename: '[name].js',
  library: '',
}

Now bundle of your library doesn’t contain react and react-dom. We marked libraries as external and have pure require calls but doesn’t have library in bundle:

/***/ "react":
/*!************************!*\
  !*** external "react" ***!
  \************************/
/*! no static exports found */
/***/ (function(module, exports) {
  module.exports = require("react");
/***/ }),

/***/ "react-dom":
/*!****************************!*\
  !*** external "react-dom" ***!
  \****************************/
/*! no static exports found */
/***/ (function(module, exports) {
  module.exports = require("react-dom");
/***/ })

This way also can help you if you’re using hooks and creating your own UI library without Chakra-UI.

NextJS, первый взгляд

Fri, 28 Feb 2020 18:45:08 +0300

На днях одно (пока) небольшое приложение перевел на NextJS, ибо нужен качественный SSR для SEO, а самостоятельно писать кучу хелперов слишком дорого по времени.

На первый взгляд все оказалось очень круто, что интересно, почему-то даже некоторые интерактивные элементы начали работать быстрее, не разбирался пока, какая магия их ускорила, но не отметить не мог. Миграция тоже прошла гладко, подключение к проекту было самым крутым из всех инструментов: установить через yarn, удалить конфиг webpack’а, — именно последний пункт больше всего понравился.

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

Казалось бы, роутинг должен быть сильнее всего проработан в фреймворке такого типа, но то ли я не понял, как им правильно пользоваться, то ли оно как-то странно сделано. Ладно, со ссылками пришлось повозиться, ибо в одном случае href — тот url, на который непосредственно идет редирект, а в другом случае — slug страницы, который я определил в роутере, а непосредственно ссылку прокидывать нужно в проп as.

Но вот если пушить что-то в url с динамическим роутом, то получается что-то странное. Пушу не явный конечный url, а slug описанный в роутинге, нужна квери-стринга? Ок, квери можно прокинуть в отдельный объект, они даже до чилда долетят, но вот в url они не попадут, бери ручками и прокидывай.

Тут у меня прямо явный диссонанс:

Ожидание: сейчас я в метод пуш прокину объект квери и текущий адрес — хоба, квери обновлен, строка адреса хранит состояние, все счастливы.
Реальность: прокидываю реальный адрес, прокидываю шаблон адреса, прокидываю квери-объект, новый полный адрес вместе с квери, который сам леплю чем-то, — тоже все счастливы, конечно, но большей ценой.

Действий немного, но хотелось бы каких-то изящных абстракций из коробки, а не руками их делать.

RS Conf 2019

Fri, 13 Sep 2019 18:22:31 +0300

С 9 по 11 августа в Минске проходила конференция ”The Rolling Scopes Conference 2019”, на которой я побывал. Отмечу, что это первая зарубежная конференция, на которой я побывал, хоть и Москва-Минск считается внутренним рейсом.

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

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

https://twitter.com/evoneering/status/1160243552837931008

Оставшиеся два дня были посвящены теме “JS/FrontEnd”, в эти дни мне было уже более комфортно, что слушать доклады, что участвовать в других активностях.

PS ClassicВ частности «Evolution Gaming» проводили челлендж по минификации кода на JS (минифицировать нужно было ручками, да). Смело могу заявить, что это был первый подобный челлендж за все время на всех конференциях, в котором мне было действительно интересно участвовать, да и на стенде были люди, с которыми было просто интересно просто пообщаться.
Интерес к челленджу также подогревался открытой доской с результатами и периодическими сообщениями в чат конференции о том, что кто-то вышел вперед. За первое место полагалась PS Classic, в первый день я ее и забрал, во второй день челлендж был не менее интересным, но я решил уже не участвовать (зачем мне еще одна PS Classic).

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

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

Под приятными впечатлениями от этой конференции решил посетить “HolyJS”, посмотрим, как оно будет.

Почему ломаются React-хуки

Fri, 13 Sep 2019 18:18:37 +0300

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

Без сомнения, идея очень крутая, использовать удобно, можно уходить от классов (я в классах ничего плохого не вижу, но все почему-то это как один из главных пунктов приводят). Но, во-первых, людей надо учить использовать хуки, просто так вот взять и перейти на хуки в production-приложении мне кажется несколько неправильным (какие еще причины, кроме людей, ниже), ибо экспертиза из воздуха не появляется, во-вторых, хуки вносят несколько новых “парадигм”, работу тех же эффектов опять же надо объяснять людям.

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

Втащили библиотеку, заюзали их хуки и… все сломалось, вместо приложения красовалась ошибка:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.

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

Из первого попавшегося react#15315, там виновных нашли сразу кучу, и неправильное использование роутера, и HtmlWebpackPlugin, и вызов в HoC’е, а в react-dropzone#821 вообще оказалось, что все ломали observer’ы из mobx.

Мой случай похож, хуки ломались из-за использования такой утилиты, как why-did-you-update, которая, к слову, довольно долго жила во многих проектах без проблем, а тут вот всплыло. Соответственно, чтобы поправить работу приложения ни осталось ничего, кроме того, что убрать вызов утилиты.

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

circular-dependency-plugin

Sun, 02 Jun 2019 18:12:15 +0300

Было ли у вас такое, что при develop-сборке все отлично работает, а при production-сборке приложение падает с несколько пугающей ошибкой?

TypeError: Super expression must either be null or a function, not undefined

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

О том, в чем вообще проблема и какие есть способы ее решить, можно почитать в посте «How to fix nasty circular dependency issues once and for all in JavaScript & TypeScript», откуда я и взял картинку ниже.

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

Резво ставьте circular-dependency-plugin и подключайте его в конфиг, и будет вам счастье.

// webpack.config.js
const CircularDependencyPlugin = require('circular-dependency-plugin')

module.exports = {
  plugins: [
    new CircularDependencyPlugin({
      exclude: /node_modules/,
      cwd: process.cwd()
    })
  ]
}

Docker’изация JavaScript-приложений

Fri, 30 Nov 2018 18:03:02 +0300

Поучаствовал в IT-Субботнике, рассказал о Docker’изации JavaScript-приложений.

WebPurple Telegram Bot

Thu, 25 Jan 2018 17:39:46 +0300

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

В Рязани наиболее активным и растущим сообществом разработчиков является WebPurple, к которому я себя смело могу отнести, ибо я являюсь активным участником (ну, я так считаю).

Для обсуждения всякого разного был создан чатик в Telegram, ну и чтобы привнести интерактивности, было принято решение сделать какого-нибудь бота, чтоб прямо круто всё было.

Изначально бот предполагался в виде типичного бота из IRC-каналов, но в итоге обсуждения он перешёл в разряд «самостоятельных» ботов. Разработкой решил заниматься я, однако в плане различных особенностей на уровне разработки, языка (NodeJS) и его использования мне помогали коллеги, чему я очень рад и благодаря чему я опять же узнал много нового.

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

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

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

Дабы упростить процесс разработки я, недолго думая, ввёл следующую команду в терминал и был рад.

npm install --save node-telegram-bot-api

Первые сложности возникли, когда я пытался с Long-Pulling соединения всё на WebHook’и переделать, но это я мануалы плохо читал.
По итогу первая версия, которая просто отдавала «статику» завелась за пару часов. А всё просто потому, что надо учитывать всякие слэши и вот это всё, ну и то, что у меня не чисто бот, а Express, «внутри» которого живёт бот.

const TelegramBot = require('node-telegram-bot-api');
const botUrl = `/bot${botToken}`;
const bot = new TelegramBot(botToken, {
  onlyFirstMatch: true,
});

app.post(botUrl, (req, res) => {
  bot.processUpdate(req.body);
  res.sendStatus(200);
});

app.listen(port, () => {
  console.log(`Express server is listening on ${port}`);
  bot.setWebHook(`https://example.com${botUrl}`);
});

Стоит учесть, что мне было лень разбираться с нормальным выстраиванием процессов разработки бота, поэтому всё отлаживал я прямо на Heroku, деплоя туда новую версию, т. к. всё было быстро, неудобств я не испытывал. Но для вероятных контрибьюторов я упростил задачу и сделал Long-Pooling в development-окружении, а WebHook’и только в production:

const TelegramBot = require('node-telegram-bot-api');
const botUrl = `/bot${botToken}`;
const bot = new TelegramBot(botToken, {
  onlyFirstMatch: true,
  polling: !isProduction,
});

app.listen(port, () => {
  console.log(`Express server is listening on ${port}`);
  if (isProduction) {
    bot.setWebHook(`${hookUrl}${botUrl}`);
  }
});

Следющая сложность — многоязычность. Довольно много времени было потрачено на поддержку нескольких языков, чтобы бот, в зависимости от языка, слал то или иное сообщение. Не понятно, зачем оно нужно было, но раз есть, значит есть. Поэтому тексты всех сообщений и регулярных выражений получаются из функции, которая принимает на вход яхык.
Ну, и пару раз я думал, что всё сломал, а это просто Telegram кэширует (или что-то ещё с ними делает) настройки языка.

Затем пришла пора работать с API ВКонтакте, обрабатывать хуки от Callback API и вот это всё. Документацию я опять же читал не совсем внимательно, но когда в ответ на запрос нужно отправлять помимо статуса 200 ещё и текст `ok` именно маленькими буквами было для меня чуть-чуть неожиданно.
А перед этим на этот же запрос нужно отправлять ответ в виде «сколько-то_там_значного» кода. Чтобы не производить деплой пару раз подряд я вынес эту переменную в ENV.

Callback API — лучшая часть VK API, потому что... использовать его ну очень просто. Получить текст записи, только что опубликованной в группе — элементарно! Однако, я хотел дать пользователям возможность получать контент по некоторому набору категорий, которые задавались в постах хэш-тэгами. Несколько реализаций «парсера» были испробованы, в итоге остановился на варианте ниже, т. к. проще, удобнее, теги можно обработать перед отправкой:

const formattedText = text.replace(
  regExp,
  (_, type) => {
    types.push(type);
    return `#${type}`;
  }
);

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

Таким образом получение планируемых эвентов выглядит как-то так:

fetch(/* Получаем 5 групп по определённому названию, с типом "event", старт которых только будет в будущем */)
  .then(r => r.json())
  .then((r) => {
    // Для вязкости добавим проверок
    if (r.response && r.response.items && r.response.items.length) {
      const groups = r.response.items.map(g => g.id);
      fetch(/* О каждой группе получим информацию */)
        .then(res => res.json())
        .then((res) => {
          if (res.response && res.response.length) {
            const processEvent = vkEventProcess(uid, bot);
            res.response
              .sort((a, b) => a.start_date - b.start_date)
              .reduce(
                // Тут "чейним" отправку сообщений, чтобы был точный порядок
                (promise, event) => promise.then(
                  () => processEvent(event),
                  err => console.log(err),
                ),
                Promise.resolve(),
              );
          }
        });
    } else {
      bot.sendMessage(uid, getNoEventsMessage(lang));
    }
  });

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

Описание `member_status`

Потом были этапы отладки, поиска багов и вот этого всего «предрелизного». Затем проведены интеграции, написаны тесты, небольшой README, добавлена возможность нормальной локальной отладки (был бы localetunnel, была б сказка, но там всё от параметров сети сильно зависит), CI, простой деплой на собственный инстанс Heroku и... «релиз».

После релиза я обнаружил, что событие «Репост» у ВКонтакте работает не совсем так, как я ожадал, поэтому пришлось быстренько фиксить, но все подписчики бота тогда уже получили невалидное сообщение.

Пост изначально планировался каким-то более содержательным и интересным, но из-за своей лени я остановился просто на перечислении сложностей, которые возникли в процессе разработки. Это всё-таки просто мой дневник в стиле «а что я вообще тогда делал».

Посмотреть на бота можно здесь: Telegram Bot.
Поучаствовать в разработке, предложить функционал и сообщить о багах можно здесь: GitHub.

Каррирование в JS

Wed, 16 Aug 2017 17:12:37 +0300

Сегодня столкнулся с одной задачкой, которая по своему типу напоминает типичную вайтборд-задачу.
Есть функция:

const add = (a, b, c, d) => a + b + c + d;

Для неё нужно реализовать функцию-обёртку возвращающую соответствующие значения при таких вызовах:

const a = getWrap(add, 1)
console.log(a(2)(4));     // 8
console.log(a(1)(2)(3));  // 9

const b = getWrap(add);
console.log(b(5)(5, 5));  // 15
console.log(b(5, 5)(5));  // 15

Одним из условий является использование каррирования.

Карринг (currying) или каррирование — термин функционального программирования, который означает создание новой функции путём фиксирования аргументов существующей.

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

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

const curried = val ? fn.bind(null, val) : fn;

Если требуется зафиксировать переменную, то каррируем переменную с помощью метода bind(), в который в качестве контекста вызова передаём null, так как в данном случае он нам не важен, а следующим аргументом — фиксируемый аргумент.
Если фиксировать переменную не требуется, то каррированная и каррируемая функции будут одинаковы.

Результатом выполнения каррированной функции будет функция, сохраняющая вычисления в переменную count и возвращающая саму себя, так же следует учесть количество аргументов, передаваемых в эту функцию, так как результатом вызова функции add с аргументами, хотя бы один из которых не задан (является undefined) будет NaN:

const func = function (...par) {
  const params = [...par];
  for (let i = 0; i < curried.length; i++) {
    params[i] = params[i] || 0;
  }
  count += curried(...params);
  return func;
};

Когда в функцию больше не передаётся параметров, нужно возвращать результат, это задачу решим с помощью метода объектов valueOf() (функция является объектом), а так же обнулять сохранённое значение результата, чтобы при следующем вызове вычисления были корректны:

func.valueOf = function () {
  const result = count;
  count = 0;
  return result;
};

В целом моё решение задачи имеет следующий вид:

function getWrap(fn, val = 0) {
  let count = 0;
  const curried = val ? fn.bind(null, val) : fn;

  const func = function (...par) {
    const params = [...par];
    for (let i = 0; i < curried.length; i++) {
      params[i] = params[i] || 0;
    }
    count += curried(...params);
    return func;
  };

  func.valueOf = function () {
    const result = count;
    count = 0;
    return result;
  };

  return func;
}

React Higher-Order Components

Mon, 24 Jul 2017 17:08:24 +0300

Несколько расстраивает, что сюда ничего не пишу, так что буду вкидывать какие-то заметки и кусочки кода.
Начнём с простого и понятного примера Higher-Order Components в React.

Enhance.jsx

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello, World!!!' });
  }
  render() {
    return <ComposedComponent {...this.props} data={this.state.data} />;
  }
};

HigherOrderComponent.jsx

import { Enhance } from "./Enhance";

class MyComponent {
  render() {
    if (!this.data) return <div>React loading...</div>;
    return <div>{this.data}</div>;
  }
}

export default Enhance(MyComponent);

Запуск Karma в Chrome — Travis-CI

Mon, 27 Mar 2017 17:05:37 +0300

Если вы тестируете свой код и используете GitHub, то скорее всего вы уже используете Travis, однако, при тестировании JavaScript в Travis может возникнуть проблема — Travis не умеет запускать тесты в Chrome, но преодолеть её можно всего несколькими строчками config-файлов.

Для начала нам нужно настроить сам travis, в моём случае `.travis.yml` выглядит следующим образом:

language: node_js
node_js:
- '6.2'
before_install:
- export CHROME_BIN=chromium-browser
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start
- sudo apt-get update
- sudo apt-get install -y libappindicator1 fonts-liberation
- wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
- sudo dpkg -i google-chrome*.deb
script:
- npm install
- npm test

Внимание здесь стоит обратить на блок `before_install`.

Для Karma тоже нужно несколько изменить файл настроек — создадим лаунчер, который будет использоваться только в окружении Travis:

module.exports = function (config) {
    var configuration = {
        // configs
        
        browsers: ['Chrome'],
        customLaunchers: {
            Chrome_travis_ci: {
                base: 'Chrome',
                flags: ['--no-sandbox']
            }
        },
      
        // configs
    };

    if (process.env.TRAVIS) {
        configuration.browsers = ['Chrome_travis_ci'];
    }

    config.set(configuration);
}

На этом процедура настройки закончена — пушим изменения на Github и можем наблюдать процесс тестирования в “консоли” Travis соответствующего репозитория.