Move component configuration parameters to end of constructor

[RahmiTufanoglu]

This change moves the specific component configuration parameters (e.g., cardConfiguration, applePayConfiguration) to the end of their respective component configuration class constructors.

Simplified the constructor by making a configuration parameter non-nullable and providing a direct default. This ensures the component always starts with a valid configuration, reducing boilerplate and potential null pointer issues.

This improves consistency and readability of the constructor signatures.

[gemini-code-assist]

Summary of Changes

Hello @RahmiTufanoglu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the structure of several component configuration classes by relocating their specific configuration parameters. The change moves these parameters from being directly within the constructor's initial declaration to being defined as final fields after the constructor. This modification aims to enhance the overall consistency and readability of the constructor signatures across the affected classes, making the code easier to understand and maintain.

Highlights

• Constructor Signature Consistency: Configuration parameters within several component configuration classes have been reordered to appear after the constructor definition, improving consistency and readability of constructor signatures.
• Field Relocation: Specific configuration fields such as applePayConfiguration, cardConfiguration, googlePayConfiguration, and others in DropInConfiguration are now declared as final fields after their respective class constructors.
• Constructor Initialization Update: The initialization of cardConfiguration in CardComponentConfiguration and skipListWhenSinglePaymentMethod in DropInConfiguration has been updated to align with the new parameter placement and improve clarity.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors several configuration classes to improve consistency in constructor signatures. The changes are generally good, especially the move to use default parameter values. However, the change to move field declarations after the constructor goes against the recommended Dart style of declaring fields at the top of a class. My review includes suggestions to revert this specific stylistic change while keeping the other improvements, to align with the Effective Dart style guide for better readability.

[gemini-code-assist]

While I see the intent for consistency, moving field declarations after the constructor goes against the common Dart convention of declaring fields at the top of the class. The Effective Dart style guide recommends this for better readability, as it allows developers to see all of a class's fields in one place.¹

The change to use a default value for the cardConfiguration parameter is a great improvement. I suggest we keep that part and move the field declaration back to the top of the class.

Suggested change

	final class CardComponentConfiguration extends BaseConfiguration {
	final CardConfiguration cardConfiguration;
	CardComponentConfiguration({
	required super.environment,
	required super.clientKey,
	required super.countryCode,
	super.amount,
	super.shopperLocale,
	super.analyticsOptions,
	CardConfiguration? cardConfiguration,
	}) : cardConfiguration = cardConfiguration ?? const CardConfiguration();
	this.cardConfiguration = const CardConfiguration(),
	});
	final CardConfiguration cardConfiguration;
	final class CardComponentConfiguration extends BaseConfiguration {
	final CardConfiguration cardConfiguration;
	CardComponentConfiguration({
	required super.environment,
	required super.clientKey,
	required super.countryCode,
	super.amount,
	super.shopperLocale,
	super.analyticsOptions,
	this.cardConfiguration = const CardConfiguration(),
	});

Style Guide References

Footnotes

1. The Effective Dart style guide recommends placing field declarations at the top of a class, before any constructors or methods, to improve readability by grouping all instance variables together. ↩

[RahmiTufanoglu]

I refactored based on the official style guide https://dart.dev/tools/linter-rules/sort_constructors_first

[Robert-SD]

Hi @RahmiTufanoglu,
thanks for your adjustment and the recommendation of rearranging the constructor. I found this guideline in the Flutter style guide. So indeed we should think about adjusting the entire project and adopt this guideline.