не забывайте отвязывать события, навешанные на кнопки с помощью метода offClick, чтобы при нажатии вы не вызвали все её предыдущие функции
Чтобы так не заморачиваться можно навесить на кнопку только один onClick - и далее в своем коде подменять функцию которая вызывается внутри, примерно так
let tgMainButtonActionFn = () => {}
window.Telegram?.WebApp.MainButton.onClick(() => {
if (typeof tgMainButtonActionFn === 'function') {
tgMainButtonActionFn()
}
})
function MainButtonOnClick(actionFn) {
tgMainButtonActionFn = actionFn
}
// Использование
MainButtonOnClick(()=> console.log('action 1') )
// затирает предыдущий экшн
MainButtonOnClick(()=>console.log('action 2') )
Ну а если где-то еще зачем-то понадобится слушать клики по этой кнопке то там уже использовать .onEvent('mainButtonClicked', ...)
В процессе разработки telegram mini web app столкнулся с тем что очень желателен туннель с https и фиксированным доменом, остановился на self-hosted решении - sish
"Я так долго все обдумываю что не важно что и остальное не быстро делаю" - что это за аргумент вообще?
Вы пользуетесь ide с автодополнеием и подсветкой синтаксиса, не в блокноте код набираете(а чего нет? там же незначительное совсем время на него нужно), пользуетесь git а не по email изменения отправляете. То есть используете инструменты ускоряющие вашу работу, но обесцениваете попытки автора пойти чуть дальше и просто немного лучше использовать те же инструменты.
Простите подгорело, под каждой статьей про эффективность есть комментарий типа вашего в стиле - долго думать, а код писать быстро - нет , не быстро, было бы быстро не выстрелил бы тот же copilot.
Неплохо! Хоть и можно было в данном случае информацию об отеле просто в "модалке" выводить и не рендерить каждый раз страницу результатов поиска при смене роута, а просто переключать свойство display, а для остального service-worker.
Но за статью спасибо, не знал о таких возможностях tanstack , надо будет доку получше почитать.
Нет проектов которые легко поддерживать спустя годы, потому что с годами меняются люди и подходы в разработке. Об этом косвенно свидетельствует опыт многолетней работы программистов на каком-нибудь одном предприятии, где они как специалисты "консервируются" и у них нет проблем с поддержкой проекта который работает уже 10 лет, но есть проблемы с трудоустройством в другие компании работающие уже на современном стеке. Если же они параллельно с работой развиваются , то у них регулярно чешутся руки всё переписать.
И наоборот, специалист с современными стеком вынужден ломать свои представления о разработке чтобы понять ту старую логику и те старые инструменты, которые в общем-то были хуже, труднее в использовании и т п
То есть поддержка старого кода всегда будет тяжёлой задачей, смиритесь с этим, тут либо стагнация, либо боль от встречи даже с самим собой из прошлого выраженного в том "бывшем" коде.
Cпасибо за подробный ответ! Я понял что нужно все что я описал реализовывать в модели, а статья у вас не про её внутренности, согласен. Мне тяжело вот так в уме представить всё это, я не видел подобных реализаций и вот показалось что это превратится в неповоротливого монстра если добавить всё что вы описали для работы с данными, будет огромное количество экшенов, частично или полностью дублирующих друг друга, раздутый стэйт и т п. но да - наверно это можно сделать более-менее красиво всё
Фронтендеры с этими многочисленными стейт-менеджерами из пустого в порожнее уже лет 15 переливают... и везде в примерах плохо работающая тудушка...
Минусы? Пока не обнаружены.
Минус вашего и многочисленных других подходов например в отсутствии синхронизации стейта между вкладками. Открыл пользователь пару вкладок с приложением - в одной например задачу добавил в тудушку - закрыл - в соседней вкладке все по старому. Если где-то какие-то данные регулярно обновляются тащатся с сервера через long-pooling например - то сколько вкладок открыто - столько запросов и будет отправляться. Какой-то недоглобальный стейт получается. Тут sharedWorker в помощь и слушатели изменения localStorage. Данные скорее всего одни и те же вытаскиваются по сто раз, не предусмотрено никакого кэширования. А что если еще и данных прям много? Нужна поддержка OPFS или может indexedDB. И как чистить стейт в таком случае от данных которые уже не нужны / не рендерятся больше?
Нет поддержки offline-mode - что если я хочу сидя в самолете набросать себе задач в туду-лист и чтобы они потом когда появится интернет отправились на сервер, а пока я бы мог их редактировать, может что-то бы уже отметил как выполненное пока летел.
Ну и пуш данных с сервера - чтобы если я с телефона что-то добавил - то оно в открытом сайте на компе отобразилось, опять же одного только сообщения через websocket тут не достаточно - крышка ноута то закрыта и он спит - нужно чтобы когда я открою ноут - сайт полез за обновлениями, а заодно отправил свои(ну те, из самолета).
Вот это всё сложные вопросы, не ясно как это лучше организовать, решений хороших и доступных просто нет, что-то платное(rxdb) или c vendor-lock(firebase) и еще с кучей своих ограничений. И если это все внедрять, то есть делать просто нормальное приложение которое не вводит в ступор пользователя, все подобные подходы превращаются в запутанного монстра, они не масштабируются нормально до такого уровня. А если не делать - то простите, но просто забрать фетчем json с сервака и не запутаться в том в какую переменную его засунул ума много не надо так что и проблем требующих какого-то решения и особенного подхода тоже нет.
То есть основной минус - невозможность масштабировать данный подход до уровня нормального приложения с синхронизацией большим объемом данных итп.
Думается мне, уволенные просто пойдут заниматься другим булшитом .
Нейросети не заменяют, а делают эффективнее людей. Потому освободившиеся люди просто займутся чем-то ещё. Ну то есть грубо, если раньше в геймдев компании было 10 художников, а теперь остался один+нейросеть , то вот эти 9 оставшихся уйдут в 9 новых компаний, которые появятся благодаря тому что на рынке появились свободные руки, благодаря тому что с нейросетями вход и конкуренция с крупными игроками стали дешевле. То есть мы как и весь последний век наращиванием обороты производства, больше освободившихся людей - больше новых производств
Отвечать пользователю и видеть переписку с ним, может кто угодно из команды - кто приглашен в группу c этими топиками. То есть не надо этот анонимный аккаунт каждому подключать. - просто пригласил в чат всех операторов и все.
Смотрите - юзер общается с ботом и понимает это, это важно - он не знает прочитано ли его сообщение например, юзер воспринимает иначе общение с ботом нежели чем с человеком.
Юзер не может удалить у вас переписку.
Можно создать много групп для разных приложений или даже разных тем обращений и пригласить в них разных или одних и тех же операторов тех-поддержки. Количество подключаемых аккаунтов все-таки ограничено в отличии от количества групп где вы можете быть участником.
Ради интереса по отдельности женой ответили на все вопросы - у нас совместимость 68% и нет критичных противоречий, что самое главное если посмотреть отдельно по категориям - то очень похоже на правду. Ваш алгоритм оценки действительно очень эффективен.
Классный лайфхак садится работать сразу как проснулся! Спасибо! Вспомнил сейчас, было несколько раз что работал сразу после пробуждения , действительно концентрация лучше, и время гораздо полезнее тратится, иначе лично я всё равно час раскачиваюсь и ничего полезного не делаю и никакой "магии утра". Попробую это внедрить на регулярной основе!
Чтобы так не заморачиваться можно навесить на кнопку только один onClick - и далее в своем коде подменять функцию которая вызывается внутри, примерно так
Ну а если где-то еще зачем-то понадобится слушать клики по этой кнопке то там уже использовать
.onEvent('mainButtonClicked', ...)То есть факт наличия переменных с именами вас смутил, а переменная _ используемая только для export default норм? )
В процессе разработки telegram mini web app столкнулся с тем что очень желателен туннель с https и фиксированным доменом, остановился на self-hosted решении - sish
Hidden text
на локальной машине еще autossh использую чтобы само переподключалось при разрыве соединения
Спасибо за статью!
Обратите внимание на raycast для macos и его плагины , сильно ускоряет типовые действия
Может вы просто очень медленно думаете?
"Я так долго все обдумываю что не важно что и остальное не быстро делаю" - что это за аргумент вообще?
Вы пользуетесь ide с автодополнеием и подсветкой синтаксиса, не в блокноте код набираете(а чего нет? там же незначительное совсем время на него нужно), пользуетесь git а не по email изменения отправляете. То есть используете инструменты ускоряющие вашу работу, но обесцениваете попытки автора пойти чуть дальше и просто немного лучше использовать те же инструменты.
Простите подгорело, под каждой статьей про эффективность есть комментарий типа вашего в стиле - долго думать, а код писать быстро - нет , не быстро, было бы быстро не выстрелил бы тот же copilot.
Неплохо! Хоть и можно было в данном случае информацию об отеле просто в "модалке" выводить и не рендерить каждый раз страницу результатов поиска при смене роута, а просто переключать свойство display, а для остального service-worker.
Но за статью спасибо, не знал о таких возможностях tanstack , надо будет доку получше почитать.
Сама постановка задачи некорректная.
Нет проектов которые легко поддерживать спустя годы, потому что с годами меняются люди и подходы в разработке. Об этом косвенно свидетельствует опыт многолетней работы программистов на каком-нибудь одном предприятии, где они как специалисты "консервируются" и у них нет проблем с поддержкой проекта который работает уже 10 лет, но есть проблемы с трудоустройством в другие компании работающие уже на современном стеке. Если же они параллельно с работой развиваются , то у них регулярно чешутся руки всё переписать.
И наоборот, специалист с современными стеком вынужден ломать свои представления о разработке чтобы понять ту старую логику и те старые инструменты, которые в общем-то были хуже, труднее в использовании и т п
То есть поддержка старого кода всегда будет тяжёлой задачей, смиритесь с этим, тут либо стагнация, либо боль от встречи даже с самим собой из прошлого выраженного в том "бывшем" коде.
Cпасибо за подробный ответ! Я понял что нужно все что я описал реализовывать в модели, а статья у вас не про её внутренности, согласен.
Мне тяжело вот так в уме представить всё это, я не видел подобных реализаций и вот показалось что это превратится в неповоротливого монстра если добавить всё что вы описали для работы с данными, будет огромное количество экшенов, частично или полностью дублирующих друг друга, раздутый стэйт и т п. но да - наверно это можно сделать более-менее красиво всё
Фронтендеры с этими многочисленными стейт-менеджерами из пустого в порожнее уже лет 15 переливают... и везде в примерах плохо работающая тудушка...
Минус вашего и многочисленных других подходов например в отсутствии синхронизации стейта между вкладками. Открыл пользователь пару вкладок с приложением - в одной например задачу добавил в тудушку - закрыл - в соседней вкладке все по старому. Если где-то какие-то данные регулярно обновляются тащатся с сервера через long-pooling например - то сколько вкладок открыто - столько запросов и будет отправляться. Какой-то недоглобальный стейт получается. Тут sharedWorker в помощь и слушатели изменения localStorage.
Данные скорее всего одни и те же вытаскиваются по сто раз, не предусмотрено никакого кэширования. А что если еще и данных прям много? Нужна поддержка OPFS или может indexedDB. И как чистить стейт в таком случае от данных которые уже не нужны / не рендерятся больше?
Нет поддержки offline-mode - что если я хочу сидя в самолете набросать себе задач в туду-лист и чтобы они потом когда появится интернет отправились на сервер, а пока я бы мог их редактировать, может что-то бы уже отметил как выполненное пока летел.
Ну и пуш данных с сервера - чтобы если я с телефона что-то добавил - то оно в открытом сайте на компе отобразилось, опять же одного только сообщения через websocket тут не достаточно - крышка ноута то закрыта и он спит - нужно чтобы когда я открою ноут - сайт полез за обновлениями, а заодно отправил свои(ну те, из самолета).
Вот это всё сложные вопросы, не ясно как это лучше организовать, решений хороших и доступных просто нет, что-то платное(rxdb) или c vendor-lock(firebase) и еще с кучей своих ограничений.
И если это все внедрять, то есть делать просто нормальное приложение которое не вводит в ступор пользователя, все подобные подходы превращаются в запутанного монстра, они не масштабируются нормально до такого уровня. А если не делать - то простите, но просто забрать фетчем json с сервака и не запутаться в том в какую переменную его засунул ума много не надо так что и проблем требующих какого-то решения и особенного подхода тоже нет.
То есть основной минус - невозможность масштабировать данный подход до уровня нормального приложения с синхронизацией большим объемом данных итп.
Думается мне, уволенные просто пойдут заниматься другим булшитом .
Нейросети не заменяют, а делают эффективнее людей. Потому освободившиеся люди просто займутся чем-то ещё. Ну то есть грубо, если раньше в геймдев компании было 10 художников, а теперь остался один+нейросеть , то вот эти 9 оставшихся уйдут в 9 новых компаний, которые появятся благодаря тому что на рынке появились свободные руки, благодаря тому что с нейросетями вход и конкуренция с крупными игроками стали дешевле. То есть мы как и весь последний век наращиванием обороты производства, больше освободившихся людей - больше новых производств
так вот чья поделка звонит мне 24/7 с вопросом мечтал ли я когда-нибудь играть в группе )))
Cмысл есть и задумка очень классная!
Отвечать пользователю и видеть переписку с ним, может кто угодно из команды - кто приглашен в группу c этими топиками. То есть не надо этот анонимный аккаунт каждому подключать. - просто пригласил в чат всех операторов и все.
Смотрите - юзер общается с ботом и понимает это, это важно - он не знает прочитано ли его сообщение например, юзер воспринимает иначе общение с ботом нежели чем с человеком.
Юзер не может удалить у вас переписку.
Можно создать много групп для разных приложений или даже разных тем обращений и пригласить в них разных или одних и тех же операторов тех-поддержки. Количество подключаемых аккаунтов все-таки ограничено в отличии от количества групп где вы можете быть участником.
Почти все те же самые приёмы использую, но вот "оставить на 90% готовое" это что-то новое, попробую!
Блин, это что получается, у меня тоже СДВГ? o_O
Ради интереса по отдельности женой ответили на все вопросы - у нас совместимость 68% и нет критичных противоречий, что самое главное если посмотреть отдельно по категориям - то очень похоже на правду. Ваш алгоритм оценки действительно очень эффективен.
Что-то как-то тяжеловато заново ответить на 200 вопросов...
Есть такие женщины как вы описали, есть не такие но пытающиеся под них косить, но есть и другие и их много - просто они не такие заметные
https://www.youtube.com/watch?v=TapOBkAu0vU
Классный лайфхак садится работать сразу как проснулся! Спасибо! Вспомнил сейчас, было несколько раз что работал сразу после пробуждения , действительно концентрация лучше, и время гораздо полезнее тратится, иначе лично я всё равно час раскачиваюсь и ничего полезного не делаю и никакой "магии утра". Попробую это внедрить на регулярной основе!
Зачёт! ))) да $mol я не знаю, как и svelte например и ember и еще кучу других, а про некоторые js-фреймворки наверно даже не знаю что они существуют )