Skip to content

Removing unnecessary comments #5

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.

Sign up for GitHub

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

Open
PaRaDoX50 wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Removing unnecessary comments #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 1 addition & 17 deletions lib/main.dart
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -637,17 +637,6 @@ class _MainScreenState extends State<MainScreen> {
@override
Widget build(BuildContext context) {
return
// UpgradeAlert(
// debugLogging: true,
// canDismissDialog: false,
// countryCode: 'in',

// // durationToAlertAgain: Duration(seconds: 1),
// showIgnore: false,
// showLater: false,
// // debugAlwaysUpgrade: true,
// // debugDisplayOnce: false,
// child:
BlocListener<GlobalAuthBloc, GlobalAuthState>(
bloc: widget.globalAuthBloc,
listener: (context, state) {
Comment on lines 637 to 642
Copy link

@coderabbitai coderabbitai bot Jan 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-649]

Several TODO comments are present in the code, which may indicate incomplete features or areas that require further development. It is recommended to either address these TODOs or track them as issues in the project's issue tracker to ensure they are not forgotten.

Would you like me to open GitHub issues for each TODO found in the code to ensure they are tracked and addressed appropriately?

📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-649]

The main function and MyApp class contain a significant amount of initialization logic. Consider refactoring this code to improve readability and maintainability. For example, you could encapsulate the initialization logic into separate functions or classes.

📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-649]

The build method in the _MyAppState class is extensive and handles various cases, which could make it difficult to maintain. Consider breaking it down into smaller, more focused methods to improve readability and maintainability.

📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-649]

There are blocks of commented-out code within the file. If this code is no longer needed, it should be removed to clean up the codebase. Commented-out code can lead to confusion and clutter if left in the codebase.

Copy link
Contributor Author

@PaRaDoX50 PaRaDoX50 Jan 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure. what part of the code can be separated out?

Copy link

@coderabbitai coderabbitai bot Jan 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build method in the _MyAppState class could be refactored to improve readability and maintainability. Here are some suggestions:

  1. Initialization Logic: The code that performs various initializations (e.g., setting up Firebase, configuring local notifications, etc.) could be moved to a separate method or even a separate class dedicated to initialization.

  2. System UI Overlay Style: The SystemChrome.setSystemUIOverlayStyle call can be extracted into a method that configures the UI overlay.

  3. MultiBlocProvider and MultiRepositoryProvider Configuration: The setup of MultiBlocProvider and MultiRepositoryProvider is quite extensive and could be moved to a separate method or class that is responsible for creating and providing these dependencies.

  4. MaterialApp Builder: The MaterialApp builder function is complex and handles different breakpoints for responsive design. This could be refactored into a separate method or widget that handles the responsiveness of the app.

  5. Routing Logic: The onGenerateRoute method within MaterialApp is responsible for navigation and routing. This could be refactored into a separate Router class.

  6. FutureBuilder Logic: The FutureBuilder within the home property of MaterialApp is responsible for determining the initial screen based on certain conditions. This logic could be extracted into a method that decides the initial screen.

By refactoring these parts of the code, the build method would become more focused and easier to understand, with each separate method or class handling a specific aspect of the app's setup.

@PaRaDoX50 Would you like more detailed examples on how to refactor any of these parts?

Expand All @@ -657,12 +646,7 @@ class _MainScreenState extends State<MainScreen> {
widget.cartFunctionBloc.add(GetCart());
}
},
// listenWhen: (previous, current) {
// if (previous is Unauthenticated && current is Unauthenticated) {
// return false;
// }
// return true;
// },

child: FutureBuilder<AuthTokensModel>(
future: LocalDataService().getAuthTokens(),
builder: (ctx, snapshot) {
Expand Down