Теоретически можно и так сделать но вряд ли будет сильно востребовано. Обычно всё-таки ступенчатая система покрывает большинство кейсов.
К тому же её по умолчанию ждут подписчики: подписчику с топовым тиром явно будет неприятно узнать что ему не доступен пост который открыт для более низких уровней.
Кстати, если на то пошло. Какой конкретно функционал хотели бы в API для ботов? Поразмыслив немного, решил, что не настолько всё сложно, т.к. по сути сводится к добавлению доступа по API токену к уже существующим эндпоинтам.
Кстати, имейте в виду, что если вы авторизуете таким образом пользователей у себя на сайте, вы становитесь оператором персональных данных со всем набором потенциальных последствий (необходимость регистрации в РКН, штрафы за утечку и т.д.) Так что на самом деле безопаснее в этом плане пользоваться как раз готовым сервисом, тут мы берём эти риски на себя.
Мы консультировались с юристами по этому вопросу. Сервис по договору выступает в роли агента автора, т.е. действует от его имени. Таким образом по сути происходящего пожертвование (если оно не предусматривает дополнительных преимуществ для жертвователя) это и есть подарок от одного физлица другому.
Ну, возможно, там какой-то самописный редактор, который сложно расширять. Мы сложными путями принципиально нигде не идём, т.к. команда маленькая и на сложности времени и сил нет. Соответственно для нас это – добавить один плагин к редактору.
Форматирование кода, скорее всего, теперь сделаем, т.к. функционал очень простой и добавляется за 15 минут буквально, так что возможно войдёт в ближайший релиз уже. Про доступ к сайту подумаем, тут сильно больше трудозатрат.
Если будет запрос на поле для ввода кода, добавим, никаких особенных проблемы с этим нет. Пока старались не перегружать редактор лишним функционалом.
Пока есть запрос на доступ к закрытым тг-чатам, вот это точно в планах. Если будет запрос от авторов на аналогичную функциональность для собственных сайтов, сделаем и это. Всё будет зависеть от того сколько авторов об этом попросит.
Ну нужен 1) redis 2) скрипты для старта sidekiq при загрузке сервера. Последние постоянно приходится писать вручную, что в общем немного каменный век с учётом того что по факту sidekiq уже давно часть стандартного комплекта Rails.
Спасибо, как ни странно простых решений действительно не хватает, а необходимость каждый раз вручную прописывать одни и те же скрипты слегка достаёт.
Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.
Ну я примерно понимаю за что вам предыдущий аккаунт забанили.
Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
Ну я это предложил именно как относительно простой в реализации способ расширять почти произвольным образом UI, возможности чего я так понимаю сейчас нет.
Ну то есть это концепция системы плагинов именно для фронтенд-части.
Ну вот гляньте мой комментарий к ветке ниже, не знаю насколько будет полезно в вашем конкретном случае, но в теории проблем с такой реализацией не вижу.
3. Много думаем над этим, но пока не очень понятно, как это сделать универсально.
В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.
Ну то есть модульность планируется всё-таки? Боюсь даже спрашивать когда и в каком объёме, чтобы не перевести снова разговор на вопрос о том насколько я увлечённый разработчик и сколько могу платить.
Да, возможно сделаем, но тут надо хорошо подумать т.к. это дополнительный способ выстрелить в ногу.
Теоретически можно и так сделать но вряд ли будет сильно востребовано. Обычно всё-таки ступенчатая система покрывает большинство кейсов.
К тому же её по умолчанию ждут подписчики: подписчику с топовым тиром явно будет неприятно узнать что ему не доступен пост который открыт для более низких уровней.
Да, спасибо, многое из этого уже запланировано на самом деле.
Сделали микрорелиз специально под ввод кода.
Теперь можно вставлять блоки с кодом в посты, работает подсветка синтаксиса.
Кстати, если на то пошло. Какой конкретно функционал хотели бы в API для ботов? Поразмыслив немного, решил, что не настолько всё сложно, т.к. по сути сводится к добавлению доступа по API токену к уже существующим эндпоинтам.
Кстати, имейте в виду, что если вы авторизуете таким образом пользователей у себя на сайте, вы становитесь оператором персональных данных со всем набором потенциальных последствий (необходимость регистрации в РКН, штрафы за утечку и т.д.) Так что на самом деле безопаснее в этом плане пользоваться как раз готовым сервисом, тут мы берём эти риски на себя.
Вот, кстати, по такому же принципу скорее всего действуют сервисы для перечисления чаевых:
https://www.sberbank.com/ru/s_m_business/nbs/sbertips
Это же такое же промежуточное звено.
Надо смотреть текст договора но скорее всего там та же история.
Мы консультировались с юристами по этому вопросу. Сервис по договору выступает в роли агента автора, т.е. действует от его имени. Таким образом по сути происходящего пожертвование (если оно не предусматривает дополнительных преимуществ для жертвователя) это и есть подарок от одного физлица другому.
Да, спасибо.
Для форматирования текста есть wysiwyg (нужно выделить текст), про markdown подумаем, возможно добавим, если найдём относительно простой способ
Да, если такой запрос есть, то сделаем. Не были уверены насколько это нужно.
Тут всё-таки всё несколько субъективно, но постараемся лучше работать над понятностью UI.
Для техподдержки пока есть email support@gapi.ru Ну или можете хоть сюда писать. Отвечать стараемся оперативно.
Самый затратный вопрос, но, возможно, сделаем в итоге.
Ну, возможно, там какой-то самописный редактор, который сложно расширять. Мы сложными путями принципиально нигде не идём, т.к. команда маленькая и на сложности времени и сил нет. Соответственно для нас это – добавить один плагин к редактору.
Форматирование кода, скорее всего, теперь сделаем, т.к. функционал очень простой и добавляется за 15 минут буквально, так что возможно войдёт в ближайший релиз уже. Про доступ к сайту подумаем, тут сильно больше трудозатрат.
Спасибо большое!
Если будет запрос на поле для ввода кода, добавим, никаких особенных проблемы с этим нет. Пока старались не перегружать редактор лишним функционалом.
Пока есть запрос на доступ к закрытым тг-чатам, вот это точно в планах. Если будет запрос от авторов на аналогичную функциональность для собственных сайтов, сделаем и это. Всё будет зависеть от того сколько авторов об этом попросит.
Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.
Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
Ну то есть это концепция системы плагинов именно для фронтенд-части.
В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.