-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add FLLUseDependencyInjection property group & Move all constants to Shared project #18
Conversation
📝 WalkthroughWalkthroughThis pull request introduces a new shared project for localization, adding centralized constants and helper methods while updating analyzer and source generator projects to reference this shared project. The changes refactor hardcoded strings to use a new Changes
Sequence Diagram(s)sequenceDiagram
participant Analyzer
participant Config as AnalyzerConfigOptionsProvider
Analyzer->>Config: Retrieve "FLLUseDependencyInjection" value
alt DI Enabled
Analyzer-->>Analyzer: Exit early (skip further context analysis)
else DI Disabled
Analyzer->>Analyzer: Continue checking context properties using Constants
end
sequenceDiagram
participant Generator
participant Config as AnalyzerConfigOptionsProvider
Generator->>Config: Retrieve "FLLUseDependencyInjection" value
alt DI Enabled
Generator-->>Generator: Use DI configuration to generate localization methods
else DI Disabled
Generator->>Generator: Retrieve pluginInfo and generate methods with Constants
end
Possibly related PRs
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this 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 (2)
Flow.Launcher.Localization.SourceGenerators/Localize/LocalizeSourceGenerator.cs (2)
79-83
: Nested tuple complexity
Deeply nested tuples can harm readability. A small record or class might be more maintainable for passing multiple elements.
693-693
: Negated condition readability
Consider simplifyingif (!(string.IsNullOrEmpty(getTranslation)))
to the more typical form below.-if (!(string.IsNullOrEmpty(getTranslation))) +if (!string.IsNullOrEmpty(getTranslation))
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
Flow.Launcher.Localization.Analyzers/Flow.Launcher.Localization.Analyzers.csproj
(1 hunks)Flow.Launcher.Localization.Analyzers/Localize/ContextAvailabilityAnalyzer.cs
(5 hunks)Flow.Launcher.Localization.Analyzers/Localize/OldGetTranslateAnalyzerCodeFixProvider.cs
(0 hunks)Flow.Launcher.Localization.Shared/Constants.cs
(1 hunks)Flow.Launcher.Localization.Shared/Flow.Launcher.Localization.Shared.csproj
(1 hunks)Flow.Launcher.Localization.Shared/Helper.cs
(1 hunks)Flow.Launcher.Localization.SourceGenerators/Flow.Launcher.Localization.SourceGenerators.csproj
(1 hunks)Flow.Launcher.Localization.SourceGenerators/Localize/LocalizeSourceGenerator.cs
(14 hunks)Flow.Launcher.Localization.slnx
(1 hunks)Flow.Launcher.Localization/Flow.Launcher.Localization.csproj
(1 hunks)
💤 Files with no reviewable changes (1)
- Flow.Launcher.Localization.Analyzers/Localize/OldGetTranslateAnalyzerCodeFixProvider.cs
🔇 Additional comments (27)
Flow.Launcher.Localization.slnx (1)
3-3
: Solution structure correctly updated to include new Shared project.The addition of the Shared project to the solution file aligns with the PR objectives to centralize constants and facilitate dependency injection configuration.
Flow.Launcher.Localization.SourceGenerators/Flow.Launcher.Localization.SourceGenerators.csproj (1)
18-20
: Project reference to Shared project correctly added.The Source Generators project now properly references the Shared project, allowing access to centralized constants and the dependency injection configuration helper.
Flow.Launcher.Localization.Analyzers/Flow.Launcher.Localization.Analyzers.csproj (1)
19-21
: Project reference to Shared project correctly added.The Analyzers project now properly references the Shared project, allowing access to centralized constants and the dependency injection configuration helper.
Flow.Launcher.Localization.Shared/Helper.cs (1)
1-17
: Helper extension method implemented correctly.The implementation of
GetFLLUseDependencyInjection
extension method forAnalyzerConfigOptionsProvider
correctly retrieves the configuration property and defaults tofalse
when not specified. This facilitates the transition fromInternationalizationManager.Instance
to dependency injection as outlined in the PR objectives.Flow.Launcher.Localization.Shared/Flow.Launcher.Localization.Shared.csproj (1)
1-14
: Well-structured shared project configurationThe new shared project is properly configured with appropriate settings for a .NET Standard 2.0 library that will be referenced by analyzer projects. The use of
EnforceExtendedAnalyzerRules
property is good practice for Roslyn-related components.Flow.Launcher.Localization/Flow.Launcher.Localization.csproj (2)
19-21
: Correctly added reference to the new shared projectThe project reference to the new Shared project has been added with appropriate
PrivateAssets
configuration, which is consistent with the other project references.
33-37
: Properly including the shared DLL in the packageThe shared DLL is correctly added to the package with the same configuration as the other DLLs, ensuring it will be available to consumers of the package.
Flow.Launcher.Localization.Shared/Constants.cs (1)
1-18
: Good centralization of constantsMoving these constants to a shared project improves maintainability and reduces duplication across the codebase. The organization of constants is clean and well-structured.
One note: the regex for
LanguagesXamlRegex
is using a compiled pattern which is generally good for performance since this regex will likely be used repeatedly.Flow.Launcher.Localization.Analyzers/Localize/ContextAvailabilityAnalyzer.cs (5)
3-3
: Appropriate usage of the shared namespaceThe addition of the
using
statement for the shared namespace allows clean access to the centralized constants.
30-34
: Well-implemented dependency injection checkThis code correctly implements the PR objective to add dependency injection support. The early return pattern is efficient and prevents unnecessary processing when dependency injection is enabled.
44-44
: Replaced hardcoded string with constant referenceGood refactoring to use the constant from the shared project instead of a hardcoded string.
73-73
: Replaced hardcoded string with constant referenceGood refactoring to use the constant from the shared project instead of a hardcoded string.
95-95
: Replaced hardcoded string with constant referenceGood refactoring to use the constant from the shared project instead of a hardcoded string.
Flow.Launcher.Localization.SourceGenerators/Localize/LocalizeSourceGenerator.cs (14)
8-8
: Centralized dependencies
Referencing the shared localization library is a good step towards removing magic strings in this generator.
12-12
: New reference for analyzer diagnostics
Addingusing Microsoft.CodeAnalysis.Diagnostics;
appears valid and aligns with incremental generator requirements.
41-41
: Use of a centralized regex
Replacing the inline pattern withConstants.LanguagesXamlRegex
improves maintainability and consistency.
66-68
: Loading analyzer config
IntroducingAnalyzerConfigOptionsProvider
into the pipeline is a fine approach. Consider how the code behaves if the config is missing or returns unexpected values.Would you like a script to check code references for fallback logic to handle missing config?
104-105
: Dependency injection flag
RetrievingFLLUseDependencyInjection
from AnalyzerConfig ensures the default value is used correctly. Please verify the fallback scenario remains as intended.
106-111
: Conditional plugin info retrieval
Bypassing plugin info when using DI fits your design goals, avoiding unnecessary property checks.
154-158
: Centralized URIs
SubstitutingConstants.SystemPrefixUri
andConstants.XamlPrefixUri
removes hardcoded strings for clarity and consistency.
178-185
: UsingConstants.XamlTag
andConstants.KeyTag
Referring to these constants avoids string typos and promotes consistent usage across the project.
423-423
: Class name check
Checking whetherparts[0]
equalsConstants.ClassName
helps ensure the generator only processes valid calls.
439-439
: Plugin interface name
UtilizingConstants.PluginInterfaceName
instead of a raw string is safer and more coherent.
447-447
: Context type name
The move toConstants.PluginContextTypeName
helps avoid mistakes and aligns with the broader constants-based strategy.
600-613
: StaticApi
property with DI
AcquiringIPublicAPI
via dependency injection is neatly implemented. If multiple threads access this static property in parallel, consider verifying thread safety.Would you like a script to check for parallel usage references of this property?
624-625
: Doc comments and translation method
These lines neatly tie in the new translation approach while generating doc comments.
630-630
: Constant-based output file name
Using${Constants.ClassName}.{assemblyName}.g.cs
for your generated source is an excellent way to unify naming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a few comments and also added a file. With that file, there's no need for the users of this package to manually specify
<CompilerVisibleProperty Include="FLLUseDependencyInjection" />
in their projects, it will be available by default. Please check out the comments and verify that on your end it also now works without manually specifying CompilerVisibleProperty
.
var configOptions = data.Item1.Item1.ConfigOptionsProvider; | ||
var pluginClasses = data.Item1.Item1.Item1.PluginClassInfos; | ||
var usedKeys = data.Item1.Item1.Item1.Item1.InvocationKeys; | ||
var localizedStrings = data.Item1.Item1.Item1.Item1.LocalizableStrings; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think those Item1
are getting out of hand. Isn't there a way to access them by their actual names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really do not know how to name those things, like ((((ImmutableArray<LocalizableString> LocalizableStrings, ImmutableHashSet<string> InvocationKeys), ImmutableArray<PluginClassInfo> PluginClassInfos), AnalyzerConfigOptionsProvider ConfigOptionsProvider), Compilation Compilation)
such type.
Use Others
or Left
? I have no idea. If you have any good name for me, please let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just curious if it's possible to avoid using tuples altogether and just use a record:
private void Execute(SourceProductionContext context, GeneratorInputs data)
{
I don't have in-depth knowledge about source generators, so I don't know if it's possible or not. Let's leave it as is for now, and just remember that this is something that should probably change in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that .NetCore2.0 cannot support record
....
It works well on my device. |
Do you think we also need to add Developers do not need to add this file manually since this is the default place for xaml language file. |
Are we assuming that English is always going to be the default language? I think it's a pretty safe assumption to have, so yeah, we should add it to the .props file. |
IIRC, FL sets English as the default language. So all plugins should provide English strings. |
@Yusyuriv Or, one more thing. Because I config ![]() I have tried to add I have also checked this configuration:
And it cannot work either. |
I don't think it being added as an analyzer is a problem. It doesn't actually contain any analyzers, so it doesn't do anything, and this project will be installed as a dependency only during development of plugins, it won't get published alongside the plugin. |
There was a problem hiding this 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 (3)
Flow.Launcher.Localization/build/Flow.Launcher.Localization.props (3)
3-3
: Consider adding a comment explaining the property's purpose.While the implementation is correct, adding a comment explaining that
FLLUseDependencyInjection
controls whether to use dependency injection or the static instance would improve maintainability and help future developers understand the purpose of this property.- <CompilerVisibleProperty Include="FLLUseDependencyInjection" /> + <!-- Controls whether to use Ioc.Default.GetRequiredService (true) or InternationalizationManager.Instance (false) --> + <CompilerVisibleProperty Include="FLLUseDependencyInjection" />
4-4
: Consider documenting the expected file path structure.The hardcoded path
Languages\en.xaml
assumes a specific project structure. Consider adding documentation or a comment to clarify this assumption for users of the package.- <AdditionalFiles Include="Languages\en.xaml" /> + <!-- Default English language file - place your localization files in a "Languages" folder at your project root --> + <AdditionalFiles Include="Languages\en.xaml" />
2-5
: Consider adding a PropertyGroup for the default property value.The PR objectives mention that
FLLUseDependencyInjection
has a default value offalse
, but this isn't explicitly set in the file. Consider adding a PropertyGroup to define this default value.<Project> + <PropertyGroup> + <FLLUseDependencyInjection>false</FLLUseDependencyInjection> + </PropertyGroup> <ItemGroup> <CompilerVisibleProperty Include="FLLUseDependencyInjection" /> <AdditionalFiles Include="Languages\en.xaml" /> </ItemGroup> </Project>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Flow.Launcher.Localization/build/Flow.Launcher.Localization.props
(1 hunks)
🔇 Additional comments (1)
Flow.Launcher.Localization/build/Flow.Launcher.Localization.props (1)
1-6
: Good implementation of automatic property configuration.This props file effectively adds the
FLLUseDependencyInjection
compiler visible property and sets up the default English language file, which aligns well with the PR objectives to simplify adoption of dependency injection and standardize localization across projects.
Thanks for your quick review👍 |
Add FLLUseDependencyInjection property group
Since
InternationalizationManager.Instance
is on the way to be deprecated (Flow-Launcher/Flow.Launcher#3276), we should move toIoc.Default.GetRequiredService
.To let this can be used for not only core project, we should use property
FLLUseDependencyInjection
instead of core assembly check. The default value isfalse
.Move all constants to Shared project
Improve code quality.
Test
When we add these in the project
Source generator will use dependency injection to get translation
And you do not need to have
public static Context
in your main class. (Tested with no build issue & No warning)