Comments 30
Всё бы ничего, но постепенно стала накапливаться усталость из-за невозможности нормально печатать на физической клавиатуре.
Первый вариант меня не устраивал из-за принципиального превосходства реальной клавиатуры над экранной.
А вообще в курсе, что в 2017-м к любому смартфону и планшету можно подключить клавиатуру по bluetooth?
И через OTG.
и по юсб. лет 5 назад тоже работало с андроидом...
Да и чего уж там, писать это приложение было довольно весело :)
На самом деле подошёл период защиты диплома, сессия, сбор документов для магистратуры, военные сборы, и переезд в другую страну.
Какая у вас интересная судьба
Спасибо, очень понравилась статья. Единственное, что не дает покоя — размер программы в 150 мегабайт.
Это бич приложений на Electron — там вместе с приложением упаковывается хром и node.js, если я правильно понимаю. Есть экспериментальные проекты типа Electrino, но по-моему там всё ещё в статусе беты.
Вопрос из чистого любопытства — как много времени ушло на реализацию?
П.С. Согласен с предыдущим комментатором,
Какая у вас интересная судьба
Сейчас приложение эмулирует официальное приложения Тиндера на андроиде, браузерный JS в целях безопасности не позволяет устанавливать некоторые заголовки запроса, так что сервер в любом случае был бы нужен. Конечно, можно было бы делать запросы на сервере и просто отображать данные в браузере, но для меня клиент для чатов всё-таки ассоциируется с отдельным приложением, да и просто было интересно поработать с Electron. В принципе сейчас рендеринг и логика практически не связаны друг с другом, так что перенести это в чистый веб должно быть довольно просто.
А redux в зависимостях зачем остался?
jquery тащит за собой emojionearea, если подскажете другой способ реализации формы ввода со смайликами, то я буду очень рад, самому это не очень нравится
redux нужен как зависимость react-apollo, они используют его для хранилища
А зачем у вас в package.json jquery?
Автор emojionearea в любой момент мог поместить jquery в peerDependencies (где этой библиотеке, кстати, и место), я хотел быть уверенным, что ничего не сломается при обновлении + с переходом на electron-forge потерялась возможность использовать webpack.ProvidePlugin и самым простым оказалось объявить jQuery глобальной переменной
На мой взгляд, если уж импортировать библиотеку в своём коде, то она должна быть явно прописана в зависимостях.
Не совсем. Они патчат механизм загрузки модулей, при загрузке модуля проверяя, есть ли он в кэше. Когда приложение собирается, все модули транспилируются. Они тащат исходники, потому что для ноды нужно чтобы при импорте файла он существовал в файловой системе, но в целях оптимизации можно все исходники при финальной сборке делать файлами нулевого размера.
- Необходимость наличия файлов сорцов, пусть даже и пустых. Как минимум странно. Причем этот косяк был подтвержден еще в январе 2016 с фразой «будет исправлено в следующей версии». Воз и ныне там.
- react-typescript темплейт мертвый — не собирается конечное приложение, проблема в неправильном использовании пакетов разработки в dependencies, да и вообще — куча лишнего. После выкидывания половины пакетов и реорганизации зависимостей — рабочий, но отношение к официальным темплейтам настораживает.
- Тайпинги мертвые. @types/electron устарел, теперь они идут вместе с пакетом electron, т.е. приходится лезть во внутренности electron-prebuilt-compile/node_modules/electron за актуальными тайпингами и пришивать их через reference path. Ставить оригинальный electron нельзя — будет конфликт с патченным electron-compile.
- Требование electron-compile даже если все было транспилировано в кеш, а это сразу +5мб.
- Странаня привязка к фиксированной версии electron-compile / electron-prebuilt-compile, неудобно апдейтить автоматом.
В результате проще иметь 3 зависимости в devDependencies: electron, typescript, electron-packager и прикрутить в скрипты вызов tsc и electron-packager. Что я делаю не так?
В целом вы правы, возможно мне хотелось большей лаконичности после electron-react-boilerplate. С electron-forge удобно что они берут на себя не только транспиляцию, но и создание установщиков, их подпись и даже релиз на гитхабе.
В планах попробовать fuse-box, чистый typescript не очень удобен, поскольку я ещё импортирую .graphql файлы (хотя, конечно, их не так много и можно перегнать их в .ts)
wasd171
Возможно, я просто туплю — но я не понял, а кто реализует graphql-сервер в вашем подходе для преобразования клиентских запросов к виду, понятному для Tinder API? Или Tinder уже предоставляет api в формате graphql?
В Electron есть 2 типа процессов — main (node.js) и renderer (Chrome). В main процессе реализован GraphQL API, который транслируется в запросы, понятные Tinder API при помощи tinder-modern
Использую gunjs + leveldb. Gun поднимает веб-сокет на бакенде и клиент к нему подключается. Этот подход понравился тем что можно без труда перенести приложение в веб, т.к. там не юзается ipc и вообще ничего что как-то может зависеть от electron. Т.е. у меня сейчас оно так и билдится, есть билд для веб, клиент + сервер, есть всё вместе внутри electron.
Тут ipc используется чисто как транспорт, будет легко поменять на websockets, например. А внутри электрона вы поднимаете локальный сервер? Можно было бы конечно прикрутить koa/express и слушать запросы как обычно, но я испытываю внутренний дискомфорт при идее, что это забивает локальные порты типа localhost:5000.
Не заметил в статье мотивации писать именно под Electron. Что Вас сподвигло на такие подвиги и почему не использовали родной GUI, например, на Java?
Ненормальный GraphQL в Electron или как я писал десктопный клиент для Tinder