Add configurable view naming rules and fallback resolution to StaticViewLocator#5
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
The fallback helper methods are currently emitted only under if (!buildMethodExists), so any locator that already defines Build(object?) will not receive TryGetFactory*/TryGetMissingView* at all. That makes the new helper-based integration pattern fail to compile for user-authored Build methods and forces consumers to duplicate fallback resolution logic manually. Keep Build conditional, but emit the helper methods unconditionally so custom Build implementations can call into generated fallback behavior.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| continue; | ||
| } | ||
|
|
||
| source.AppendLine($"\t\t[typeof({classNameViewModel})] = () => new {classNameView}(),"); |
There was a problem hiding this comment.
Avoid constructing generic views without type arguments
The mapping code can resolve a generic target view via metadata name (for example when StaticViewLocatorStripGenericArityFromViewName=false and the view type is WidgetView<T>), but the emitted factory always instantiates new {classNameView}() where classNameView has no type arguments. In that configuration the generated source becomes invalid (new WidgetView() for a generic type) and breaks compilation in consumer projects.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Added some fixes
Summary
This expands
StaticViewLocatorso consumers can configure naming and namespace transforms without forking the generator, and it brings the generated runtime behavior much closer to existing reflection-based view locators.Changes
Why
Many Avalonia apps use conventions beyond a fixed
ViewModel -> Viewrename. This makes the generator usable in more real codebases while keeping view lookup static and AOT-friendly.Validation
StaticViewLocator.slntest suite passes