Skip to content

Fix #294#301

Open
alterphp wants to merge 1 commit into
masterfrom
fix/294
Open

Fix #294#301
alterphp wants to merge 1 commit into
masterfrom
fix/294

Conversation

@alterphp
Copy link
Copy Markdown
Collaborator

@alterphp alterphp commented Dec 10, 2025

Fix #294

Summary by CodeRabbit

  • Refactor
    • Improved locale configuration handling in search functionality to use centralized configuration lookup instead of direct string references.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Dec 10, 2025

Walkthrough

The PR modifies WikiClient initialization in SearchStructure to fetch locale configuration from a LocalesConfig lookup instead of using the user's default locale string directly, passing the configuration as an array to WikiClient while preserving the search result fetching flow.

Changes

Cohort / File(s) Change Summary
WikiClient initialization refactoring
app/Src/UseCases/Domain/Context/Queries/SearchStructure.php
Changed WikiClient instantiation to fetch locale configuration via LocalesConfig::whereCode(Auth::user()->default_locale)->first() and pass $localeConfig->toArray() instead of passing the locale string directly.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

  • Single file modification with straightforward dependency initialization change
  • No alterations to public API signatures
  • Overall control flow and functionality remain unchanged

Poem

🐰 A locale lookup, neat and clean,
No more strings where configs should gleam,
From direct to config, the path takes flight,
WikiClient now initialized just right! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check ❓ Inconclusive The title 'Fix #294' is vague and does not clearly describe what was actually changed in the code, such as the LocaleConfig implementation modification. Replace with a more descriptive title like 'Use LocaleConfig lookup instead of direct locale string in WikiClient initialization' to clearly communicate the main change.
✅ Passed checks (1 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/294

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
app/Src/UseCases/Domain/Context/Queries/SearchStructure.php (1)

7-7: Use LocalesConfig::getLocaleFromCode (and optionally guard Auth::user()) to avoid null cases

The change to pass a config array into WikiClient is the right direction and matches the WikiClient constructor. However, this lookup is a bit brittle:

  • LocalesConfig::whereCode(Auth::user()->default_locale)->first() will return null if:
    • the user’s default_locale includes a country suffix (e.g. fr_FR) while LocalesConfig.code stores only fr, or
    • no row exists yet for that code.
  • Calling $localeConfig->toArray() on null will then trigger a fatal error.

Since LocalesConfig already exposes getLocaleFromCode() with logic to:

  • strip the country part from the code,
  • choose a sensible default (and even prefer English), and
  • throw a clear exception if the table is empty,

it’s safer to reuse that here. You may also want to defensively handle unauthenticated use (if this use case can ever be hit without a logged-in user).

For example:

 use App\LocalesConfig;
 use App\Src\WikiClient;
 use Illuminate\Support\Facades\Auth;

 class SearchStructure
 {
     public function execute(string $search): array
     {
-        $localeConfig = LocalesConfig::whereCode(Auth::user()->default_locale)->first();
-        $client = new WikiClient($localeConfig->toArray());
+        $user = Auth::user();
+        $preferredLocale = $user ? $user->default_locale : '';
+        // Falls back and handles codes like "fr_FR"
+        $localeConfig = LocalesConfig::getLocaleFromCode($preferredLocale);
+
+        $client = new WikiClient($localeConfig->toArray());

If you’re certain that default_locale is always a bare code present in locales_config and that this use case is only ever called for authenticated users, then the current implementation is acceptable but more fragile than it needs to be. Please confirm those assumptions or consider the above refactor.

Also applies to: 18-20

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6f49c41 and 70b3a4b.

📒 Files selected for processing (1)
  • app/Src/UseCases/Domain/Context/Queries/SearchStructure.php (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
app/Src/UseCases/Domain/Context/Queries/SearchStructure.php (2)
app/LocalesConfig.php (1)
  • LocalesConfig (11-73)
app/Src/WikiClient.php (1)
  • WikiClient (10-103)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Sentry - TypeError App\Src\WikiClient::__construct(): Argument #1 ($configs) must be of type array, string given

1 participant