-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InstantSearch migration #706
base: master
Are you sure you want to change the base?
Conversation
// TODO: Not sure if this is the right place, | ||
// the autocomplete also needs this but | ||
// we don't want to load everything | ||
// directly due the JS size |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest creating another js file with exports to import in the listing and autocomplete for the basic functionality needed everywhere.
If you look at the current situation we also have a similar file for the base of reactivesearch.
If you open the autocomplete you'll see it also downloads a "Container" js file
This also happens when you open a category page:
Vite will automatically recognise and create a separate bundle if it notices multiple other bundles require it.
TODO: Double check this, the data updates, | ||
but the component doesn't. Tried to | ||
make everything working recursive | ||
plus keep it renderless. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This usually is solved by adding a :key
that will change depending on the data so the element is forcibly rerendered: https://vuejs.org/api/built-in-special-attributes#key
src/Models/Product.php
Outdated
// will be used resulting in all attrs. | ||
|
||
// Customize the data array... | ||
// cast to the correct types! (int), etc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Casting to the correct types should already be handled by the $casts right?
I do agree that it might be a good idea to pass the data through an eventy filter(?) so it can be changed as desired.
ReactiveSearch is within Rapidez from day 1, but the current status is unclear and there isn't much activity on Github. We choose this as Magento requires Elasticsearch / OpenSearch, so no additional requirements.
In the past we've worked with InstantSearch from Algolia which supports more search engines which is a good alternative and it integrates with multiple search engines:
With this migration; we could migrate to Laravel Scout so we can get rid of our custom indexer, use a first party Laravel package, get batch imports out-of-the-box and more advantages. Laravel Scout also supports multiple search engines; Algolia, Meilisearch and Typesense out-of-the-box. There are some custom drivers for Elasticsearch:
This current proof of concept is using Meilisearch, but I'm not yet convinced as locally (on a M1) I can't get it faster than 300ms where Elasticsearch responds within 50ms. Not sure yet how easy it is to switch between engines; maybe it will be configurable with Elasticsearch as default; so you can use the same infrastructure.
To be continued 🚀
Oh and yes; we're also going to migrate to Vue 3; but after this within a separated PR.
Update: Switched to Elasticsearch using Searchkit. Performance is back to what we're used to and within the core (but also within some projects) custom query DSL is used; so sticking to Elasticsearch is preferred.