Слишком много обощенных данных, что значит лагало и тп.
Может соберёте на codepen своё "плохое" решение. Мы посмотрим, может что придумаем)
А 60 fps это иногда путь, а не цель)
Nayro TV, После получения данных нужно вначале его уничтожить( slick('unslick')) + возможно удаление слайдов, после добавляете html, а затем заново создать как вы создавали изначально.
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, это уже другая проблема.И совсем не иголка. К чему профи будет городить свои костыли, если есть уже проверенные готовые решения - когда будет быстрее, безопаснее и надежнее в плане поддержки.
Конечно есть исключения, есть специфики, особые случаи и ид и тп. Я безусловно обобщил.
Но в общем случае, вся эта возня со своим всем своим кончается плохо, при прочих равных
Может соберёте на codepen своё "плохое" решение. Мы посмотрим, может что придумаем)
А 60 fps это иногда путь, а не цель)