ui: Lazy-load samples through generated catalog#1807
Merged
Conversation
Add a Roslyn source generator that emits an ISampleCatalogProvider with
sample metadata and sample factories at build time. The generated provider
lets startup build the category shell and Featured list without reflecting
over every sample type or constructing every SampleInfo up front. This
reduces launch work and helps avoid the iOS watchdog as the sample set grows.
Generated catalog shape:
```csharp
public sealed class GeneratedSampleCatalog : ISampleCatalogProvider
{
public IReadOnlyList<string> GetCategories() => Categories;
public IReadOnlyList<string> GetSampleNames() => SampleNames;
public SampleInfo CreateSampleInfo(string formalName)
{
switch (formalName)
{
case "DisplayMap":
return new SampleInfo(
formalName: "DisplayMap",
sampleName: "Display map",
category: "Map",
sampleType: typeof(DisplayMap));
default:
throw new ArgumentException(...);
}
}
public object CreateSample(string formalName)
{
switch (formalName)
{
case "DisplayMap":
return new DisplayMap();
default:
throw new ArgumentException(...);
}
}
}
```
Old startup flow:
```text
AppShell / flyout start
|
v
SampleManager.Initialize()
|
v
Assembly.GetTypes()
|
v
Read attributes and create every SampleInfo
|
v
Build full tree, Featured, Favorites
|
v
First page can render
```
New startup flow:
```text
AppShell / flyout start
|
v
SampleManager.Initialize()
|
v
GeneratedSampleCatalog via partial hook
|
v
Load sample names and category names only
|
v
Build category shell and materialize Featured
|
v
First page can render
|
v
Category, search, offline data, and samples load on demand
```
Route SampleManager through the catalog provider API for sample lookup,
category loading, all-sample materialization, and sample creation. Search,
offline data, and full sample lists still materialize on demand when those
flows need them instead of during boot.
Keep ReflectionSampleCatalogProvider as a plan B for consumers or targets
that do not wire in the generator. The fallback preserves the old
reflection-based discovery behavior behind the same ISampleCatalogProvider
contract while normal app builds use the generated catalog and avoid startup
reflection.
Add generator to sln
imalcolm1
approved these changes
May 21, 2026
imalcolm1
left a comment
Collaborator
There was a problem hiding this comment.
Looks good, loading is much faster everywhere now!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add a Roslyn source generator that emits an ISampleCatalogProvider with sample metadata and sample factories at build time. The generated provider lets startup build the category shell and Featured list without reflecting over every sample type or constructing every SampleInfo up front. This reduces launch work and helps avoid the iOS watchdog as the sample set grows.
Generated catalog shape:
Old startup flow:
New startup flow:
Route SampleManager through the catalog provider API for sample lookup, category loading, all-sample materialization, and sample creation. Search, offline data, and full sample lists still materialize on demand when those flows need them instead of during boot.
Keep ReflectionSampleCatalogProvider as a plan B for consumers or targets that do not wire in the generator. The fallback preserves the old reflection-based discovery behavior behind the same ISampleCatalogProvider contract while normal app builds use the generated catalog and avoid startup reflection.
Type of change
Platforms tested on
Checklist