Например, есть плашка для товара какая-нибудь. Её надо повесить на товар. А условия, от свойства пользователя зависит, их приличное количество. Если получать их до вызова компонента и через $arParams, то это по идее кеш раздует сильно, ради плашки, т.к. вариантов у свойства много.
Я такое всегда делаю на фронте
это ведь странно на фронте делать, разве нет? Это же не для фронта вещь. Например, плашка новинки, акции, распродажа и т.п. Я понимаю, когда речь про корзину идет, это уже фронтовая вещь и индивидуальная для каждого.
Какие аргументы кроме "странно"? Если эти данные зависят от пользователя - не вижу ничего криминального здесь. Плюс вариантов "на фронте" может быть много. Например можно к html считанному из кэша добавить инлайн скрипт за пределами кэшируемой области (скажем в component_epilog), который набросит/сделает видимыми ваши плашки.
потому что это обычная информации из базы по сути, а не динамический функционал страницы и в данном случае, js это как костыль выглядит, который будет в будущем плодить баги.
В таком случае только вариант с разделением кэша. Ко всем остальным решениям, в т.ч. с отложенными функциями, можно применить те же самые аргументы.
js он в браузере приведет страницу к нужному хтмл, хотя нужный хтмл должен отдать бек, а не js исправлять то, что бек не смог из-за архитектуры фреймворка отдать. Что и является по сути костылем. Отложенные функции, это механизм бека, что уже нормально будет. А как разделить кеш у каталожных компонентов адекватно? Может есть варианты, о которых я не знаю. А то я смотрю из новых вещей(за последние лет 5) в документации вообще пусто.
Так же как и раньше - генерируемые данные компонентом должны просто зависеть от входящих параметров. Передавайте в arParams группы пользователя например, или от чего там у вас зависят эти плашки
а другого способа нет? Допустим, для каждой области свои варианты распродаж, акций и т.п. будет. так же есть ещё несколько параметров других у пользователя, что вызовет перемножение вариантов. В итоге, на одну страницу catalog.section в данном разделе будет 300-400 комбинаций. Это нормально, если у catalog.section столько будет?
Обсуждают сегодня