Nayro TV, ну так остался открытым вопрос, каким образом сам слик узнает что есть изменения, если инициализация идёт до изменений.
Значит делайте реиницилизацию. Он же сам по себе не реактивный и тп. Те не будет знать что есть изменения, если его тыкнуть тем или иным способом.
scottparker, вы правы немного неудачно выразился, я у себя в уме вообще ещё проговорил много другое) Написалось почему-то меньше :)
PS ну в любом случае в данном контексте так наверное делать не стоит, тут и слишком много волшебства и и мало проверок было.
bouslayeff, в яндекс вебмастере, выбираете ваш сайт, там раздел Индексирование -> скорость обхода.
По умолчанию типа Яндекс сам определяет насколько вас можно максимально раз в секунду опрашивать.
Но можно задать в ручную от 0,2 до 20 раз в секунду. Это не гарантированное значение, а ограничение верхнего порога.
BEKa T, нет, менять так не нужно. Так вы меняете будто бы те символы это utf8.
Если не верите можете скопировать те кракозябры(без смены ) и проверить например здесь https://www.online-decoder.com/ru
Видимо придётся по особому извращаться.
PS кстати вот похожий вопрос https://qna.habr.com/q/582990 , его решение с конвертация бинарника я видел, но не пробовал
Я не работал таким образом, но через POST запрос он будет же в любом случае сохранять в тот или иной temp , пусть даже придумать его сделать виртуальный диском в ОЗУ.
Но есть способ работы через PUT запрос, я не пробовал в таком ключе, можете поэксперементировать.
Эмм.. а код, телепатически сложно решить.
Вам нужно дебажить.
Где у вас вызывается addAll()?
проверьте каждый из них и разберите массив параметров requests, наверно в одном из них где-то что-то вылетает?
Может даже вместо addAll, использовать .add чтобы вычислить конкретный забагованный.
Но это так, пока теории
А что не так, вас не устраивает версия?
если что команда npm audit fix - пытается обновить пакеты, без замены на новую версию с потенциально несовместимыми изменениями. С ключом --force : npm audit fix --force - все потенциально опасные пакеты будут обновлены, даже если ломается обратная совместимость.
Так вот, версия tailwindcss@3.3.1 - вас не устраивает?
Griboks, о боже. Ну вы серьезно. Причем тут домену управления, это напрямую не связано с вопросом.
Вопрос сови костыли - рост издержек и подводных камней на будущее, готов вкладываться в команду внутри компании которая будет её поддерживать или нет? Ведь бизнес растёт, развивает, и маленькая фигня будет больше требовать всяких интеграций и вместо того чтобы развивать и растить самую базовую бизнес логику мы будем с правильными папочками пилить свое решение, а зарплатки откуда?
И естественно, важен здравый смысл, иногда полезно и нужно свой интструмент пилить, по причинам допустим критичности безопасности(но тут снова это часть ядра основного бизнеса тогда), либо это важно для бизнес/продаж, а может и в опенсурс потом самим выкатить и тоже определенные плюшки получить.
Вы даёте примеры, даже выше, которые легко разбить будет при росте и началу усложнения требваний/изменения апи стороннего сервиса и тд и тп. Это всё нужно поддерживать.
Вопрос а есть ли на это бюджеты? Не будем ли проедать относительно главной цели?
Не выстрелим ли себе в ногу просто проходя сами тот путь, который уже другие прошли отточили и тп.
И таких но много.
Каждый раз нужно принимать решения конкретно.
Если вам показалось что я за безумно бездумные фреймоворки везде и всегда, то абсолютно нет.
Но и из принципа "потому что бла бла" отказываться от них не буду.
А уж если прогер одиночка, фрилансер - то тут тупо подстава для маленького бизнеса. Он уйдёт, а его гениальные костыли никто не захочет поддерживать, либо возьмёт за это дополнительные деньги. Это уже все тысячи раз проходили. Но все равно эти вопросы возникают.
Поэтому ответ по умолчанию - изучить что сделано, возможно есть хорошие решения и их можно использовать, планирование, разработка.
Зачем тогда Яндекс использует Реакт и ко? Та ведь ещё костыльная технология. Но зато много чего на ней уже есть, много хороших(правда и не хороших тоже) спецов.
Так и живём.
Нужен здравый смысл и адекватное отношение к требованиям и реальным целям стейкхолдеров(и не важно кто это бизнес, общественная организация и тп). Лишний раз удорожать не стоит.
Ярослав, эмм. а в чем здесь не юникс вей?
У dovecot кстати есть HTTP API. dovecot кстати та ещё фигня в контексте юниксвея в некоторых моментах, хотя в целом мне нравится тоже пользуюсь.
А вам все же советую вспомнить или подучить, что такое протоклы и тп.
Вы поймите, сам браузер работает по HTTP протоколу, IMAP будет поддерживать если есть плагин для него.
Если вы хотите REST API - те запросы по HTTP к IMAP, то естественно нужна прослойка или IMAP сервер где уже эта прослойка реализована.
Ну а остальное вы сами в своем комментарии написали. Значит ваш поиск будет на веб морде, может быть даже типа хедлесс(headless без фронта, но с API) к почтовым сервисам на сервере.
Меньше философии, больше логики. Это кстати про юникс вей ;-)
Griboks, вы не путайте конкретную задачу, где условный тяжёлый груз не нужно нести, и общий подход для сложных сервисов.
Понятное дело ко всему нужный здравый подход, логика и тп. Это рабочие моменты. Не вижу противоречий.
Griboks, это уже другая проблема.И совсем не иголка. К чему профи будет городить свои костыли, если есть уже проверенные готовые решения - когда будет быстрее, безопаснее и надежнее в плане поддержки.
Конечно есть исключения, есть специфики, особые случаи и ид и тп. Я безусловно обобщил.
Но в общем случае, вся эта возня со своим всем своим кончается плохо, при прочих равных
Значит делайте реиницилизацию. Он же сам по себе не реактивный и тп. Те не будет знать что есть изменения, если его тыкнуть тем или иным способом.