->with(['orders' => static function ($query) {
$query->cost(100);
})
? А вообще нихрена не понятно, в чем вопрос и в чем задача. ... и мы получаем 15 элементов после группировки на клиенте вместо 20, потому что 5 дней не было никаких событий. Проблема в том, что клиент не знает количество элементов после группировки пока не сгруппирует.
Какая разница, SPA это или нет? Из таких вот моментов и раздувается приложение на ровном месте.
И перенос подобной логики на сервер поможет с этим справиться.
Если предполгается, что даты могут приходить в разных таймзонах, то да, необходимо дать возможность указания таймзоны для каждой даты. Впрочем, вы углубляетеся в дебри сослагательного наклонения. Тут нам уже необходим конкретный пример с конкретной проблемой. Опишите предполагаемую архитектуру приложения и какой функционал необходимо добавить, а я могу подготовить вам решения и уточнить их плюсы и минусы если реализация будет вынесена на серверную сторону.
Слышал про преждевременную оптимизацию. Очень вредная штука.
На мелких проектах - никому. Пустая трата денег заказчика.
Разница в том что при серверной группировке нет необходимости отдавать все 100000 записей клиенту. Достаточно отдать одну страницу - например, сгруппированные записи за 20 дней.
Опять данные кому-то должны, эх. Задача в том, чтобы у пользователя максимально быстро открылся сайт. Плюс предварительной обработки данных на сервере в том, что, во-первых, пользователю не придется скачивать js-код, который будет заниматься обработкой на его стороне, а, во-вторых, клиентскому устройству не придется этот код исполнять.
можно будет определить часовое смещение пользователя
Приведу примеры, когда эти рекомендации спокойно можно игнорировать. Или даже нужно.
Если не планируется мультиязычности, то никакой разницы.
Вредный overhead на мелких проектах. Не нужен.
Аннотации для переменных при наличии тайпхинтинга