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

Такс, почти неделю ничего не писал, исправляюсь.

Когда мы говорим про React и стейт-менеджмент почти всегда мы думаем про Redux и это не значит, что других нет, просто это уже такой стандарт и все им пользуются (и не всегда оправданно), что я как-то и не следил, что нового в этой теме появляется.

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

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

import { create } from 'zustand'

const useBearStore = create((set) => ({
bears: 0,
increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
removeAllBears: () => set({ bears: 0 }),
}))

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

function BearCounter() {
const bears = useBearStore((state) => state.bears)
return <h1>{bears} around here ...</h1>
}

Либа небольшая по размеру, имеет 30к звезд на гитхабе, решает многие дефолтные проблемы гонок, потери контекста и тд. Ну и посмотрите какой параллакс из 2013 у них на сайте.

Когда в начале 2022 года после всем известных событий на vc всплывали посты об импортозамещении Figma ничего кроме улыбки у меня это не вызывало и все вот почему.

Принес вам ссылку на пост кофаундера и CTO фигмы, где в 2015 году он рассказывает, что фигма это как бы уже тогда и не совсем веб-приложение. Да, вы запускаете его через браузер, но что там под капотом?

Реализовано это счастье на C++ с использованием в 2015 asm.js, а в 2017 WebAssembly. Если у вас вопрос почему, то в тексте есть все ответы, но вот несколько важных поинтов:

– на стороне C++ они полностью управляют памятью без использования JavaScript Garbage Collector, который тоже конкурирует за ресурсы в main треде приложения и влияет на отзывчивость интерфейса, и в целом такой подход с использованием прекомпилированного кода на C++ позволяет иметь от 2x увеличения производительности в том числе, что браузер не занимается работой по интерпретации его в рантайме;

– html и svg дают много оверхеда и для задач фигмы чаще всего намного более медленные, чем 2D Canvas;

– всякие эффекты типа блюра, blend modes и масок, актуальные для графических приложений, реализованы по-разному между браузерами;

– также как и рендеринг текстов, который отличается между браузерами и операционными системами, в этом мы и сами (как любители пиксель-перфекта) не раз убеждались в своей практике, но там есть пара ссылок, где можно почитать подробнее (ссылки старые, но заверяю, что ничего за эти годы не поменялось);

– собственно, сами браузеры тоже проблема - каждый реализует разный набор возможностей, где-то что-то поддерживается, где-то что-то нет, в статье говорится про кастомные курсоры, которые в каждом браузере работают через разные форматы (SVG for Firefox, -webkit-image-set for Chrome and WebKit, and the ancient .cur format for IE).

И все это значит, что нельзя обучить чела на курсе по React-разработке за пару месяцев и пустить его пилить фичи в продукт. Поэтому и в никакое импортозамещение таких сложных продуктов я не верю, тем более что из-за сложности в опенсорсе ничего похожего не найти. Это все-таки не Rocket.Chat форкнуть, налепить свой логотип и сказать, что мы запустили аналог Slack.

Scroll anchoring

Короче, погрузился я тут в одну тему и решил, что можно про нее даже написать сюда.

Когда мы делаем какие-то chat-подобные приложения, когда при подгрузке контента надо актуализировать позицию скролла мы это обычно делаем так:
– получаем scrollHeight до изменения контента;
– производим манипуляции по изменению;
– получаем scrollHeight после изменений;
– считаем дельту и на эту дельту смещаем скролл.

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

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

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

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

.scroller {
overflow-anchor: none;
}

И будет вам одинаковое поведение для всех браузеров без танцев с бубном.

webpack в amoCRM

Есть у меня статья двухлетней давности, про начало сборки фронта в amoCRM. Можно найти по тегу #amocrmbundling, а можно и долистать вверх, я не сказать, что очень много написал за эти два года, а сейчас будет пост на целых 2 сообщения 😅

В общем в итоге я выбрал require.js. Изначально, исходя из ее популярности на тот момент, и что она покрывала наши собственные потребности. Она позволяла в дев режиме собирать фронт в рантайме, подгружая файлики по сети, а в продакшене подгружать уже собранные чанки, чтобы количество запросов на статику в продакшене не было таким диким. Плюс разработка у нас построена через дев-сервер, на котором крутятся все сервисы и фронт загружался тоже с хоста разработчика. Сейчас уже смешно, а когда мы в Сан-Франциско проводили конфу и мне надо было оттуда прогать конструктор ботов - было не смешно, когда пинг оттуда до дев-сервера, находящегося в Мск доходил до 2 секунд на статичный файл. Приходилось один раз загружать фронт, выключать disable cache в хроме и вручную прописывать пути файлов, которые я редактировал, и которым при загрузке надо подставить рандомный хеш, чтобы именно для них кеш сбросился, иначе загрузку страницы можно было ждать пару минут.

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

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

Вот с переходом на webpack получилась ровно такая история. Первый раз не получилось потому что у меня не было решения как встроить сборку webpack в наш монолит, я сконвертил конфиг require.js в конфиг webpack, довел до плюс/минус заводимого состояния, но дальше было две проблемы:

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

2. У нас оставалась система виджетов, которая работает на require.js и использует наши модули в рандомном количестве, поэтому надо было оставить возможность использования наших модулей для виджетов.

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

Продолжение поста выше... #amocrmbundling

Как в итоге решились оба вопроса?

Во-первых, я завел куку для дев-окружения, что-то типа use-localhost со значением Number, с помощью которого можно указать порт, на котором крутится webpack-dev-server. При получении запроса бекенд смотрит, если мы в дев-окружении и есть эта кука, то хост статики выставляется localhost с номером порта из значения куки. Таким образом теперь фронт грузится с локальной машины, проблемы Сан-Франциско теперь быть не может.

Во-вторых, написал плагин для webpack, который при сборке продакшен билда для каждого модуля, который нужно экспортировать, добавляет строки вида:

window.define('${requirejsModuleName}', function(){
return module.exports;
});
window.require(['${requirejsModuleName}']);

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

Если модуль не был загружен, то require.js сходит за ним в сеть на наш сервер, так как конфиг и структура файловой системы для require.js не изменились. Проблема была только с вендорными либами, которые лежат в папке node_modules, которая в свою очередь на продакшен не деплоится, но для этих модулей я прописал в конфиге пути на cdnjs. Поэтому если какая-то вендорная либа, которую захочет подгрузить виджет не загружена в рантайме, то виджет подгрузит ее с cdnjs.

Наверное, были еще какие-то проблемы, которые менее существенны и их получилось решить быстрее, но эти две мне показались самыми интересными и про них можно было написать. Так мы перешли на webpack, стали быстрее собирать фронт, сильно быстрее работать в дев-режиме, не зааффектив при этом производительность итак не самого быстрого дев-сервера.

Дальше был такой же долгий процесс перехода на es6, но это уже, как говорится, другая история.

Всем привет, начало будет странным, но потом все будет понятно.

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

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

В общем так в отпуске родился мой небольшой пэт-проект, который я решил сделать полностью бесплатным без какой-либо рекламы и опен-сорсным. Пока готова версия для iOS, но скоро приедет и андроид.

Ссылка на AppStore.

P. S. Если под постом наберется какое-то количество реакций, то запилю пост о том, как оно работает.

Как и обещал пишу о том, что под капотом у How Much In. Начнем с не менее важной части, чем само приложение - откуда данные?

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

Поэтому первым решением было сделать кеширующую API-прослойку. Если посчитать, что обновление мы будем делать раз в час, то 24 * 30 = 720. То есть даже укладываемся в бесплатный лимит, но все-таки я больше про интерфейсы, чем пилить какую-то апишку. Конечно, лезть в весь этот бекенд мне не хотелось, поэтому, еще немного поискав, я нашел вот эту репу https://github.com/fawazahmed0/currency-api

Какой-то хороший человек делает выгрузки курсов раз в день и кладет результаты в свой публичный репозиторий. А дальше красиво, не многие знают, но есть такой публичный CDN - JSDelivr. Он кроме хостинга всяких публичных библиотек занимается зеркалированием публичных GitHub-репозиториев размер которых до 50 МБ. Сам я нашел это когда мы делали сайт-визитку в amoCRM и оказалось, что Taplink, например, использует такой подход для раздачи статики на своем продакшене. Просто деплоят фронт в публичную репу на гитхабе, а в продакшене ссылки на статику ведут на эту репу через jsdelivr.

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

Это было просто, пришел на помощь Yandex.Cloud с их API Gateway и решилось все одним YAML файлом примерно следующего содержания:

paths:
/{path+}:
get:
parameters:
- name: path
in: path
required: false
schema:
type: string
responses:
'200':
description: API endpoint
content:
'application/json':
schema:
type: "string"
x-yc-apigateway-integration:
type: http
url: https://cdn.jsdelivr.net/gh/fawazahmed0/{path}.min.json

Таким образом мой эндпоинт сейчас просто проксирует запрос на jsdelivr и эту публичную апишку: https://api.how-much.in/currency-api@1/latest/currencies

Вопросы? Откуда берутся данные? Честно - сам толком не понял, в issues чувак не отвечает, но вроде плюс/минус курс совпадает. Обновление раз в день? Да, но цель была не потухнуть на этапе разработки бекенда, а выпустить приложение, поэтому пока пусть будет так - для ознакомительных целей, чтобы примерно перевести сумму в другую валюту достаточно - эталонной точности нет, но и не надо пока. Если интерес останется, то сделаю currency-api@2 и оно будет обновляться чаще и показывать более точно.

На этом пока все, итак вроде много получилось, про интерфейс и react-native в следующих сериях.

Ура! Гугл наконец-то промодерировали андроид-версию спустя неделю!

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

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

Итак, в приложении используется FlatList для вывода списка валют. Каждая валюта под названием имеет фиолетовый прямоугольник, который является и выводом значения и полем ввода одновременно. При выводе значения в текст число форматируется в соответствии с локалью пользователя через ReactIntl, отбивает тысячные, десятичные доли и тд. При этом инпут ввода - стандарный TextInput. Если мы заводим стейт и перерисовываем по клику то текст, то инпут - уже здесь у react-native начинаются затупы, подлагивания при появлении клавиатуры и ты чувствуешь, что что-то не то. React может и чувствуется, а вот native как-то не очень. Поэтому делаем хитро.

<View style={tw`relative`}>
 <TextInput
  ref={inputRef}
  defaultValue={valueRef.current}
  style={tw`opacity-0`}
  onChangeText={v => {
   setValues(currency, parseFloat(v));
  }}
  onFocus={() => {
   inputRef.current?.setNativeProps({
    style: { opacity: 1, zIndex: 1 },
   });
  }}
  onBlur={() => {
   inputRef.current?.setNativeProps({
    style: { opacity: 0, zIndex: -1 },
   });
  }}
  onEndEditing={e => {
   const v = e.nativeEvent.text;

   if (initialValueRef.current !== v) {
    setTimeout(
     () => setValues(currency, parseFloat(v), true),
     500,
    );
   }
  }}
 />

 <View
  pointerEvents="none"
  style={tw`absolute`}
 >
  <Text>
   <FormattedNumber
    value={value}
    style="currency"
    currency={currency.toUpperCase()}
   />
  </Text>
 </View>
</View>

У нас есть оберточный View, внутри которого с абсолютным позиционированием лежит Text с отформатированным значением, для его родителя указан pointerEvents="none", то есть клик по нему не обрабатывается. Под ним лежит прозрачный TextInput и когда мы кликаем на сумму валюты мы на самом деле ставим курсор в инпут, который на фокус становится непрозрачным и начинает нормально отображаться, а по блюру, соответственно, скрывается. Такой подход позволяет иметь полностью нативное ощущение при постановке курсора в инпут в списке неограниченного размера.

Следующая оптимизация начинается, когда мы вводим значение. Если мы сразу пересчитаем значение для всех валют (а их может быть выведено более 150), то опять же получим дерганье как в эпилептическом припадке, а не ощущение летающего нативного приложения. Поэтому в коде выше setValues вызывается 2 раза. Первый раз на onChangeText и тут мы берем индекс изменяемой валюты и пересчитываем только 10 сверху и снизу, чтобы перерисовка по мере ввода требовалась только 20 элементам списка максимум (тем, которые точно видит пользователь). Так мы получаем близкую к идеальной работу пересчета по мере ввода. А уже на onEditingEnd пересчитываем для всех и там добавим небольшой таймаут 500мс, чтобы клавиатура скрылась без тормозов.

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

Сегодня утром я за один час сделал лендинг для прилы How Much In. Пока это самый крутой экспириенс по no-code запускам, что я пробовал. И это Framer.

Для начала тебя просят ввести словесное описание того, что ты хочешь наклепать. Мой финальный вариант был: landing page about free currency converter mobile app even without ads that called "How Much In" in white/violet color scheme without pricing section

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

Сгенерив несколько вариантов, я получил практически то, что финально вы видите на лендосе. Был немного другой фиолетовый, я руками поправил на цвета из моей иконки. Изначально был выбран другой шрифт заголовков, это можно тоже менять руками. Эта штука сгенерила булщит тексты, которые я частично самостоятельно скорректировал через ChatGPT, частично оставил прям то, что сгенерил AI Framer'а.

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

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

Вот так вот выглядит интерфейс самого Framer

Впервые пробую запустить кампанию на Product Hunt для How Much In. Если не сложно поставьте плюсик.

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

Жизнь никогда не будет прежней, проверяйте

Как найти крутого дизайнера на проект?

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

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

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

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

В итоге я прошерстил все доступные макеты из старого контеста на прилу для винды. Написал 10 дизайнерам, получил 1 ответ и с этим человеком мы в итоге сделали дизайн для проекта (на данный момент уже мертвого, к сожалению, но история ведь сейчас не об этом).

Главное запуск

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

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

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

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

Собственно, касаемо переписывания кода. Наконец-то можно констатировать, что вся кодовая база amoCRM теперь полностью в ES6 со всеми современным плюшками языка.

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

Так что параллельно с разработкой других фич постепенно, папка за папкой, я переводил код (по паре папок так же помогли ребята из команды), мердж реквесты на 200, 300 и даже 600 файлов это норма для данного тикета. Но теперь ура, все получилось.

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

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

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

Так появился Perf Ninja, который будет представлять из себя one-button-deploy сервис на NextJS. Выполняет только нашу простую задачу, данные хранит в вашей Supabase, а код крутится в вашем Vercel.

Такой коммитмент, чтобы не слиться.

Я тут сделал калькулятор для How Much In и по этому делу решил запоститься на HackerNews.

Если у кого есть там аккаунт, буду рад лишнему плюсику, хотелось бы вылезти в основную категорию show.

И кстати дизреспект Framer, пришлось съехать с него. Я ж там оплатил на год подписку на минимальный тариф, потом гугл меня выкинули из play store из-за того, что не было страницы privacy, а когда я захотел создать ее, то фрэймер сказал, что за твои жалкие 60 долларов в год ты можешь опубликовать только 1 страницу и экспортировать тоже ничего не дадим.

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