fix: improve places screen sorting

[lorux0]

What does this PR change?

We need to prioritize places with people in it, and align with website results. Sets the default sorting option to most active.

Test Instructions

1. Go to https://decentraland.org/discover
2. Check how places are sorted out in the grid
3. Open the explorer
4. Go to places screen
5. Check the results are the same
6. Check the active number of people in the place makes sense

[github-actions]

🚦 CI Status

Windows and Mac build successful in Unity Cloud! You can find a link to the downloadable artifact below.

Name	Link
Commit	cab0af9
Logs	https://github.com/decentraland/unity-explorer/actions/runs/33107135580
Download Windows	https://github.com/decentraland/unity-explorer/suites/89711633092/artifacts/9663034800
Download Windows S3	https://explorer-artifacts.decentraland.org/@dcl/unity-explorer/branch/fix/places-sorting/pr-25614-cab0af9/Decentraland_windows64.zip
Download Mac	https://github.com/decentraland/unity-explorer/suites/89711633092/artifacts/9662104716
Download Mac S3	https://explorer-artifacts.decentraland.org/@dcl/unity-explorer/branch/fix/places-sorting/pr-25614-cab0af9/Decentraland_macos.zip
Built on	2026-08-27T20:15:50Z

Warnings not reduced: 12543 => 12543 — remove at least 1 warning to merge.

Warnings/errors in files changed by this PR (4)

Assets/DCL/Places/PlacesView.cs:57  UnusedMember.Local  Method 'Awake' is never used
Assets/DCL/Places/PlacesFilterSelectorView.cs:35  UnusedMember.Local  Method 'OnDestroy' is never used
Assets/DCL/Places/PlacesView.cs:87  UnusedMember.Local  Method 'OnDestroy' is never used
Assets/DCL/Places/PlacesFilterSelectorView.cs:23  UnusedMember.Local  Method 'Start' is never used

⚠️ EditMode produced no results — the run likely crashed or timed out before finishing. Check the Unity Test / Test (editmode) job.

TESTS SUITE	Result	Passed	Failed	Skipped
EditMode	⚠️ No results	—	—	—
PlayMode	✅ Passed	243	0	37

[decentraland-bot]

Review Summary

What the PR changes: Switches the default places-screen sorting from 'Best Rated' (LIKE_SCORE) to 'Most Active' (MOST_ACTIVE) across UI, data model, and prefab initialization to align with the website and prioritize places with active users.

Root-cause assessment: The PR addresses the product requirement directly — changing the default value at the source (reset filters flow) rather than masking a symptom. The changes are coordinated across three touch points:

1. PlacesFilterSelectorView.cs (lines 50, 55): UI toggle state now defaults to sortByMostActive instead of sortByBestRated in the reset flow, using both event-firing and silent variants correctly
2. PlacesView.cs (line 199): Data model default updated from LIKE_SCORE to MOST_ACTIVE
3. Places_FilterSelector.prefab: Toggle initial states swapped (m_IsOn: 0→1, m_IsOn: 1→0) to match code defaults

Design & integration: No new systems, lifecycle owners, or persistent collections introduced. The change is a pure configuration default, integrated into existing reset-filters flows. All three points are properly coordinated — no inconsistencies detected.

Code quality: Changes comply with CLAUDE.md standards:

• No LINQ, no persistent collections
• Proper use of SetIsOnWithoutNotify() for silent state changes (correct pattern for avoiding event cascades during reset)
• Simple enum replacement (no deeper logic refactoring needed)
• Consistent enum naming across files

CI status: Semantic PR title check passing (fix: improve places screen sorting). Build and test workflows in progress. Approval checks show expected status (QA/DEV reviews not yet assigned).

---

REVIEW_RESULT: PASS ✅
COMPLEXITY: SIMPLE
COMPLEXITY_REASON: Configuration-only change (default sort order) affecting UI state and data model; no systems, async, or structural ECS changes
QA_REQUIRED: YES

[github-actions]

Auto-approved based on Jarvis review — simple fix/chore with no blocking issues. QA approval is still required.

[decentraland-bot]

Design Patterns & Code Quality Review

STEP 1 — Load context & set scope

✓ Loaded CLAUDE.md and review instructions
✓ Analyzed changed files and diff
✓ Scope: Configuration change to default Places sorting behavior

STEP 2 — Root-cause check

✓ PASS — PR directly fixes the root cause. The requirement is to prioritize active places and align with website sorting. This change updates the default sort order from LIKE_SCORE (Best Rated) to MOST_ACTIVE across all three files. Not a workaround or symptom fix.

STEP 3 — Design & integration

✓ PASS — No new long-lived units introduced. Changes are purely configuration within existing Places filter/view system:

• PlacesFilterSelectorView: Changes which toggle initializes as selected (sortByBestRated → sortByMostActive)
• PlacesView: Changes default enum value in ResetCurrentFilters()
• Prefab: Swaps toggle enabled states to match

No lifecycle ownership issues. No per-frame reconciliation. Changes are consistent across all three files.

STEP 4 — Member audit

No new public properties or accessors added. Only existing toggle fields and enum values are modified. The null! declarations on serialized Toggle fields are appropriate — they must be assigned in the editor.

✓ PASS

STEP 5 — Line-level review

Consistency check

All three files consistently switch from BestRated/LIKE_SCORE to MostActive/MOST_ACTIVE:

• PlacesFilterSelectorView.cs (line 50, 54): Sets sortByMostActive.isOn instead of sortByBestRated.isOn
• PlacesView.cs (line 199): Sets IPlacesAPIService.SortBy.MOST_ACTIVE instead of LIKE_SCORE
• Prefab: Toggle states swap—MostActive becomes default (m_IsOn: 1), BestRated becomes secondary (m_IsOn: 0)

✓ PASS — Changes are internally consistent.

Anti-pattern check

Bridge/wrapper classes: None introduced ✓
Defensive null-checks against non-null declarations: None found ✓
Extracting when should merge: None ✓
Per-frame logic in presenter/controller: None — ResetFilters() is called explicitly, not every frame ✓
Comments narrating caller behavior: None ✓

✓ PASS — No anti-patterns detected.

STEP 6 — Complexity assessment

• 3 files, ~7 lines of meaningful changes
• Straightforward toggle/enum configuration update
• No ECS systems touched
• No async/UniTask changes
• No new dependencies or lifecycle management

COMPLEXITY: SIMPLE

STEP 7 — QA assessment

• Changes affect user-facing behavior (Places default sort order)
• Runtime code (Explorer player build)
• User will see different places listed when Places screen first loads

QA_REQUIRED: YES — Manual testing required to confirm sort order matches website and displays active places prominently.

STEP 8 — Non-blocking warnings

None.

---

STEP 9 — Verdict

REVIEW_RESULT: PASS ✅
COMPLEXITY: SIMPLE
COMPLEXITY_REASON: Configuration change updating default sort order in Places UI without ECS or async modifications
QA_REQUIRED: YES

[decentraland-bot]

Review — PR #9891: fix: improve places screen sorting

STEP 2 — Root-cause check: PASS

Problem: The Places screen default sorting ("Best Rated" / LIKE_SCORE) does not prioritize places with active users and does not align with the website's sort order at decentraland.org/discover.

Fix: The diff changes the default sort to "Most Active" (MOST_ACTIVE) — this addresses the cause directly by aligning the explorer's default with the website. Not a workaround or symptom suppression.

STEP 3 — Design & integration: PASS

No new long-lived units (systems, plugins, managers, controllers) are introduced. The change modifies only default values in three coordinated locations:

1. PlacesFilterSelectorView.ResetFilters() — UI toggle default switched from sortByBestRated → sortByMostActive (both with-events and without-notify paths)
2. PlacesView.ResetCurrentFilters() — data model default switched from SortBy.LIKE_SCORE → SortBy.MOST_ACTIVE
3. Places_FilterSelector.prefab — serialized m_IsOn states swapped between the two toggle MonoBehaviours

All three are consistent — the UI toggle state, the data model default, and the prefab initial state agree on "Most Active".

No new subscriptions, event hookups, connections, buffers, or measurements added. No teardown concerns.

STEP 4 — Member audit: PASS

No new public properties or accessors added or changed. Only the internal default values within existing method bodies are modified.

STEP 5 — Line-level review: PASS

Two passes over the changed lines found no issues:

• No bugs, logic errors, or potential runtime errors
• No security vulnerabilities
• No performance issues (no allocations, no LINQ)
• No resource/subscription leaks introduced
• No missing error handling
• No nullability violations
• No detached async or unconsumed infrastructure
• No CLAUDE.md anti-patterns introduced
• No naming or encapsulation issues
• No magic values (uses existing enum constants)

Security review: No security issues found

Purely a UI default value change — no input validation, auth, secrets, or data exposure concerns.

STEP 6 — Complexity: SIMPLE

Touches 3 files with ~6 lines of meaningful changes. Straightforward configuration/default value swap. No ECS, async, networking, or architectural modifications.

STEP 7 — QA assessment: YES

Changes default sorting behavior in the Places UI — affects what the user sees when opening the Places screen. Manual verification needed to confirm results match decentraland.org/discover.

STEP 8 — Non-blocking warnings: None

Main scene not modified. No warnings.

Git conventions (ADR-6): PASS

• PR title fix: improve places screen sorting follows semantic commit format ✅
• Branch name fix/places-sorting follows <type>/<summary> convention ✅

---

REVIEW_RESULT: PASS ✅
COMPLEXITY: SIMPLE
COMPLEXITY_REASON: Changes only default filter/sort values in UI view classes and a prefab — no ECS, async, or architectural modifications.
QA_REQUIRED: YES

---

Reviewed by Jarvis 🤖 · Requested by decentraland-bot via GitHub

[decentraland-bot]

PR #9891, run #33112512195

Overall: ✅ no significant changes

Builds: Windows change, Windows baseline, macOS change, macOS baseline

How to read this table

• Each build is measured 3 times, interleaved with the other build (change, baseline, change, baseline, ...) in the same session, so both see the same world content and machine state. The values are the median, and (min–max) is the lowest and highest of those runs.
• Δ is Change minus Baseline (a negative Δ means Change is faster).
• 🟢 faster / 🔴 slower — a difference that passed every check: the runs are fully separated (every run of one build faster than every run of the other), and the median difference is at least 3% and at least 0.5 ms.
• ⚪ within noise — the builds' runs overlap, or the difference is tiny; it cannot be told apart from random variation. Treat it as no change.
• — informational — the 0.1% worst metrics average only the few worst frames of a run, so a single OS hiccup swings them by a lot; they are shown for context and never earn a verdict.
• ⚠️ no verdict — the two builds' sessions were not comparable (very different sample counts, or too few usable runs), so no conclusion is drawn from them.
• Exceptions per run — the average number of exceptions in a run's log, not counting teardown ones logged while the app quits. Flagged only on a difference of at least 2 per run and 1.5× the other build; exception kinds the baseline never threw are called out under the table. The Exception breakdown groups all of them by the explorer's report category and exception type (as totals across the runs).
• A run that logged unusually many exceptions (at least 10 and 5× the median of its build's runs — e.g. a service was down during it) is excluded from all numbers and called out under the table.
• The Overall line at the top only reacts to a metric that moved on two or more machines, or by 10% or more on one — a single modest 🟢/🔴 cell can still be a statistical fluke.

Intel Core i5

Metric	Baseline	Change	Δ	Result
Samples	2374 (×3)	2362 (×3)
CPU average	37.7 ms (35.8–37.9)	37.9 ms (36.5–38.0)	0.2 ms	⚪ within noise
CPU 1% worst	305.8 ms (282.3–324.0)	306.6 ms (296.6–325.9)	0.8 ms	⚪ within noise
CPU 0.1% worst	345.7 ms (324.9–364.7)	325.2 ms (311.6–339.1)	-20.4 ms	— informational
GPU average	23.6 ms (22.4–23.9)	23.7 ms (22.3–23.9)	0.1 ms	⚪ within noise
GPU 1% worst	312.0 ms (265.9–330.4)	311.2 ms (301.4–331.3)	-0.8 ms	⚪ within noise
GPU 0.1% worst	354.9 ms (334.1–365.2)	331.0 ms (321.0–347.0)	-23.9 ms	— informational
Exceptions per run	0	0	0	⚪ no significant change

Apple M1

Metric	Baseline	Change	Δ	Result
Samples	3322 (×3)	3391 (×3)
CPU average	26.9 ms (26.7–27.1)	26.3 ms (25.7–26.9)	-0.6 ms	⚪ within noise
CPU 1% worst	224.5 ms (222.1–225.8)	221.2 ms (220.5–228.3)	-3.4 ms	⚪ within noise
CPU 0.1% worst	233.5 ms (233.4–235.5)	234.8 ms (231.9–235.2)	1.3 ms	— informational
GPU average	19.0 ms (18.5–21.7)	20.8 ms (20.5–21.3)	1.7 ms	⚪ within noise
GPU 1% worst	55.9 ms (44.3–55.9)	51.4 ms (49.0–53.0)	-4.5 ms	⚪ within noise
GPU 0.1% worst	59.7 ms (56.6–60.3)	56.9 ms (55.6–57.3)	-2.8 ms	— informational
Exceptions per run	0	0	0	⚪ no significant change