Should I merge it now? Yes.
No blocking findings.
All ten deleted components were already absent from the base compilation. None leaves a reference in the remaining application source. All 646 active component dependency lists match, and fresh TopFans and generated ajwhite QA builds pass.
I would merge ad0fff9aaf. The main benefit is removing code that no page uses. The bundle savings are small.
What gets deleted
- ProfileDetailComponent, SubscriptionSelectModalComponent, SubscriptionPlanDurationModalComponent and the old typeahead SearchBarComponent.
- SeoLandingComponent, SeoLandingCreatorCardComponent and SelectInterestsAccordionComponent.
- The portfolio, feed-content and event-ticket store-item components, plus their private constants and portfolio interface.
The PR deletes 33 files and edits three. The edited files remove a commented profile search block, its unused fields and methods, and two store-item CSS selectors.
Code review
No active component loses a dependency
I searched the remaining application TypeScript, templates, SCSS and JSON for every deleted component class, selector, exported constant and interface. There are no remaining references. All ten component classes are also absent from the saved base compiler output.
Fresh Angular compilation still emits 646 components. Their resolved template dependency lists match the base exactly. This checks the active component graph as well as the source references.
The live search bar stays
The deleted SearchBarComponent uses app-search-bar-typeahead. The active search component in src/app/components/search-bar/ uses app-search-bar and remains unchanged. Wallet, resources, insights and other pages still use it.
The profile's removed typeahead markup was entirely inside an HTML comment. After stripping comments and normalizing whitespace, the old and new profile templates match. See the retained search component.
The profile cleanup has no remaining caller
The removed isSearchBarOpen and searchClass fields, addClass and closeSearch methods, and Renderer2 and ElementRef constructor parameters belonged to the commented search block. The remaining profile code and template do not reference them.
ElementRef remains imported because other profile view queries still use its type. There is no change to the active profile routes, subscriptions or payment flow.
Shared types and the current store card remain
The PR keeps seo-landing.model.ts. Its Creator type still has three consumers, including the featured-creator picker and cover-page editor.
StoreLayoutItemCardComponent remains imported by both the store-item and store-items-grid layouts. The store-item template already uses that card for non-merchandise items. Merchandise still uses the share-details preview. The removed feed-content and portfolio selectors have no matching elements in the remaining source.
One existing lint warning remains
ESLint reports that ProfileComponent defines ngOnChanges without implementing OnChanges. I reproduced the same warning on the base. There are no lint errors in my run, and this PR does not introduce the warning.
Independent bundle measurements
| Entry | Base bytes | PR bytes | Bytes saved |
|---|---|---|---|
| Initial JavaScript | 7,127,756 | 7,127,756 | 0 |
| Profile | 1,850,789 | 1,850,356 | 433 |
| Marketing | 1,225,948 | 1,225,681 | 267 |
| Comparison | 1,226,687 | 1,226,420 | 267 |
| Dashboard | 5,090,126 | 5,090,126 | 0 |
These figures come from fresh TopFans QA builds of the PR and an identical source tree to its base. They are uncompressed JavaScript sizes. Lazy entries include static dependencies beyond the initial load; the rows overlap and must not be added together.
Removing the dead component files contributes no direct runtime saving because the compiler already excluded them. The small reductions come from the remaining profile code and unused styles removed by this PR.
Checks run for this review
| Check | Result |
|---|---|
| TopFans QA client and server build | Pass. 42 warning groups. |
| Base TopFans QA build | Pass. 42 warning groups. |
| Generated ajwhite QA client and server build | Pass. 42 warning groups. |
| Angular compilation and dependency comparison | Pass. All 646 component lists match. |
| Deleted symbol and selector search | No remaining application references. |
| Profile template comparison | Identical after removing comments and normalizing whitespace. |
| ESLint on the surviving changed TypeScript | Zero errors. One existing lifecycle-interface warning on both base and head. |
| Git whitespace check | Pass. |
Builds used isolated checkouts, a 10 GB Node heap limit and disabled prerendering. White-label configuration came from the QA generator. The compiler baseline is the saved PR 10842 output; its source tree is identical to 8e2432612f.
GitHub reported the PR open and mergeable, with no status checks listed. An empty check list is not a CI pass.
Runtime coverage limits
I did not independently rerun development builds, SSR response comparisons, hydration or signed-in browser flows. My checks cover the final PR head, not each intermediate commit.
The author reports QA and development builds, unchanged component dependencies for both commits and matching server rendering over 145 URLs. They did not run a signed-in white-label sweep because the deleted components were already outside the compilation. Those are author-reported results.
The source references, template comparison and fresh builds give me no specific regression to hold this cleanup for. A successful build still does not prove every signed-in interaction works.