Если посмотреть на генерируемый запрос, то это не совсем то. Eloquent использует подзапрос для подсчета количества связанных записей, удовлетворяющих условию, соответственно с загрузкой это ничего общего не имеет. То есть по сути будет произведено целых два с половиной запроса (основной, в котором будет подзапрос считающий количество по фильтру, и запрос на загрузку связанных данных).
В моем же случае все это укладывается в один запрос, плюс на мой взгляд код чище.
где category — BelongsTo связь и будет загружена через джоин, options — HasMany связь и будет загружена отдельными запросами
То есть в запросе вы сможете опираться на поля продукта и категории, но не опций.
Я сделал так намеренно для удобства сортировки и фильтрации в небольших таблицах. В dev-ветке ведется разработка асинхронного вывода таблицы, для использования в конфиге модели нужно дописать ->async(), на данный момент асинхронно работают постраничная навигация и сортировки только по полям таблицы из этой модели.
Основная цель была директивы класса и атрибутов, так как стандартными средствами реализовать тэг, у которого может быть несколько классов, а может и не быть совсем — непростая задача.
Теперь я и сам вижу недостаток в расширяемости, буду развивать проект и постараюсь учесть комментарии. Коллбэки были в первоначальном варианте, но показались мне слишком громоздкими в описании и метод начинал превращаться в нечитаемую кашу. Попробую поискать достойное решение, чтобы и функционал не страдал, и удобство в использовании и поддержке тоже. Хттп-ошибки возвращают результат всегда одного вида (в документации есть пример) с урлом и статусом ошибки.
Запросы к апи в большинстве случаев не стоит делать в основном потоке, а выполнять в фоне и кэшировать. Поэтому для меня производительность не так важна, как удобство использования. А производительность у symfony/dom-crawler не хуже других php-парсеров, посколько все они основаны на трансляции css-селектора в xpath и в конечном итоге используют одни и те же методы.
Тут используется еще один уровень абстракции над dom-документом, который при этом не запрещает вам получить DomNode объект. Но для меня использование стандартных объектов для парсинга html выливается в десятки строк кода и сложную поддержку. Dom-crawler же позиционирует себя как некий аналог jQuery на php и намного проще позволяет модифицировать документ, а также получить полный html обратно. Я не пропагандирую, что это единственно верное решение, оно превносит ограничения в работу, но для большинства задач, с которыми я сталкивался, серьезно упрощает жизнь.
Для выбора элемента из dom-дерева используется «symfony/dom-crawler» и трансляцией css-селектора в xpath и выборкой элементов занимается эта библиотека. Моя же библиотека с dom-документом ни одной строкой кода не связана, основной целью имеет объединение этих селекторов в структуру, которую нужно получить на выходе.
В данном случае хабр — всего лишь пример. Я использовал его как всем вам известный ресурс. В большинстве случаев библиотеку я использую для доступа к данным на маленьких локальных сайтах, которые были бы плохим примером.
На данный момент реализован весь базовый функционал, который я использую в моих обычных проектах, поэтому пока нет ясного представления в какую сторону дальше двигаться. Я открыт для пожеланий и критики. Самое очевидное направление развития — это реализация большего количества элементов формы и типов столбцов, я некоторые в паблик версию не стал вносить, как например выбор координат с помощью карты 2гис, потому что это более локальная вещь и не хотелось бы плодить ненужный функционал.
Спасибо, что обнаружили такой досадный баг. Я его исправил, теперь этот тип поля должен валидироваться корректно. В погоне за поддержкой различных форматов ввода даты упустил из виду.
Это было сделано сразу после первого коммита на гитхаб. В документации раздел про установку содержит информацию только как ставить через composer. В современных реалиях по-другому делать и смысла-то нет.
В моем же случае все это укладывается в один запрос, плюс на мой взгляд код чище.
где category — BelongsTo связь и будет загружена через джоин, options — HasMany связь и будет загружена отдельными запросами
То есть в запросе вы сможете опираться на поля продукта и категории, но не опций.