Question: rationale behind using the prefix in file names? about laravel-scout-settings HOT 5 CLOSED

I opened a PR that simply remove the prefix from the name. It breaks backward compatibility.

If I understood what you mean, you would like to have a simple way to get the settings for a given model, like the following snippet. Today, all the logic is in the command so it's not very usable.

// Somewhere in a controller
$postSettings = Algolia\Settings\Facade\Ressource::getSettings(Post::class);

I called it Resource, since it should manage settings
If you want to open a pull request, I think it will be great to have an AlgoliaSettings class that holds to logic of reading/writing the json files and figuring out the correct name. It would solve the issue for people adding logic to their searchableAs method. And maybe add a nice facade for easy access.

What do you think?

from laravel-scout-settings.

Hi @qrazi,

thanks for the detailed issue. I believe you're right! I have recently redone the Symfony bundle for instance (which is very much inspired by Scout) and I'm not using the prefix, for the same reason you stated: algolia/search-bundle#196

I think it was just a bad idea at the time ^^ I'll release a new version before the weekend :)

Thanks a lot for pointing it out.

from laravel-scout-settings.

Hi @julienbourdeau,

No problem, I'm glad my use case got some validation... 😅 Your solution for the Symfony bundle would definitely solve my problem... 👍

Since ::searchableAs() is specifically mentioned as override-able in the documentation, there might still be some benefit from allowing custom base file names, but might as well put that on the road map until needed?

Thanks in any case for the quick response! Looking forward to the new version 😄

from laravel-scout-settings.

I actually have another use case as well, that sort of intersects with functionality provided by this package. The application is multi-language. The index records contain value for all locales, and the localized properties (i.e. name, summary) are suffixed with the locale. A record would thus have the properties name_nl and name_en.

In our current situation we use the index settings from a model, filter it on the current locale, and pass the set of searchable attributes to the view layer, where the Algolia InstantSearch client will do the actual querying of the index, and add a restrictSearchableAttributes to all queries. This prevents the return of matches in other locales.

The benefit of doing this vs suffixing the locale in JS is less JS logic happening, thus lighter. And for me personally makes more sense that the restrictions are supplied by the backend.

Now to my question; in the Laravel 5.5 + Laravel Scout + Laravel Scout Settings setup, those settings are stored in the json files. Would it make sense that the algolia/algoliasearch-laravel package exposes an API to Laravel for getting those settings, or at least the logic for the file name and path to the settings? Right now I am sort copying logic from the algolia/algoliasearch-laravel package to get to those json files, which will break the moment that logic changes... 😄

Again, I'd be willing to help with implementing something like that, just need a few pointer as to what the implementation would need to look like to be accepted... 👍

from laravel-scout-settings.

I think we are thinking along the same line there for sure. I will try to make the PR this weekend, tnx!

from laravel-scout-settings.