purplenoodlesoop / purple-starter Goto Github PK

I discover this project and found this extension.

extension BuildContextX on BuildContext {
  IEnvironmentStorage get environment => EnvironmentScope.of(this);
  IDependenciesStorage get dependencies => DependenciesScope.of(this);
  Dio get dio => dependencies.dio;
  AppDatabase get database => dependencies.database;
  SharedPreferences get sharedPreferences => dependencies.sharedPreferences;

  IRepositoryStorage get repository => RepositoryScope.of(this);

  // ignore: avoid-non-null-assertion
  AppLocalizations get localized => AppLocalizations.of(this)!;

  MediaQueryData get mediaQuery => MediaQuery.of(this);
  Size get screenSize => mediaQuery.size;

  ThemeData get theme => Theme.of(this);
  TextTheme get textTheme => theme.textTheme;
}

It't interesting shortcuts for stateless widgets, but I suppose that I could have another variation for stateful widgets

mixin MediaQueryAccessMixin<SW extends StatefulWidget> on State<SW> {
  late MediaQueryData _mediaQueryData;

  MediaQueryData get mediaQuery => _mediaQueryData;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    _mediaQueryData = MediaQuery.of(context);
  }
}

When we use this mixin on state, we can asses to sync context
https://www.youtube.com/watch?v=bzWaMpD1LHY
And it will be little bit faster. I know that it's not main argument, but why not
For example,

class ExampleWidget extends StatelessWidget {
  const ExampleWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text(localized.title),   // In your variant we access to context 3 times
        Text(localized.subtitle),// It has complexity O(1), 
        Text(localized.author),  // but access to simple field would be faster
      ],
    );
  }
}

Also we can create variations for another things which we can get from context, for example Theme, Localization, ScaffoldMessanger, etc.

It should automate: caching, late initialization, disposing of instances, storage instance-level singletones, and factories

Could be nice to remove android & ios folders from the repository.
Android, ios, web, windows and etc folders could be created by the flutter create command.
So user will have actual content version for the certain framework version and only folders needed for the user project.

Could be nice to implement basic restoration for the navigation and maybe some other simple cases.

Possibly integrate Melos

This field should be named progress

https://pub.dev/packages/typed_preferences

I discover this project and find interesting idea, but I suppose we can do it little be better.

abstract class IEnvironmentStorage {
  Environment get environment;
  String get sentryDsn;
}

class EnvironmentStorage implements IEnvironmentStorage {
  const EnvironmentStorage();

  @override
  Environment get environment => Environment.values.byName(
        const String.fromEnvironment('ENVIRONMENT'),
      );

  @override
  String get sentryDsn => const String.fromEnvironment('SENTRY_DSN');
}

Firstly, property environment, would be compute every time when we access to it, because byName is not constant expression.
I propose use another variant.

class Environment {
  const Environment._();
  static const _flavor = String.fromEnvironment(
    'flavor',
    defaultValue: 'dev',
  );
  static const isDevMode = _flavor == 'dev';
  static const isProdMode = _flavor == 'prod';
  static const isDemoMode = _flavor == 'demo';
  static const flavor = isDevMode
      ? Flavor.dev
      : isProdMode
          ? Flavor.prod
          : Flavor.demo;
}

Yes, here we use static fields. I understand that in this case we can't create different implementations, but I think we don't need it here. We don't need abstractions for abstractions. But we achieve compile time optimizations,

class Example extends StatelessWidget {
  const Example({super.key});

  @override
  Widget build(BuildContext context) {
    return Environment.isAndroid ? const AndroidStyledWidgets() : const IosStyledWidgets();
  }
}

In this example, we cut of all IosStyled widgets from app, when we provide variable platform=android. But with current approach in this project this feature is unused.

Could be nice to use common style for the *.mk files
for example:
flutter = (fvm flutter || flutter)
instead of
fvm flutter

Similar to this

Reference

Could be nice to add Environment Scope - default and loaded from the environment variables.

final env = const String.fromEnvironment('env', defaultValue: '').toLowerCase();

There is comment before ScopeDelegate implementation

/// instead of the [build] method. Class that extends [ScopeDelegate] should
/// **NEVER OVERRIDE THE BUILD METHOD**. It will break things.
abstract class ScopeDelegate<S extends Scope> extends State<S> {

But you can add @nonvirtual annotation from meta/meta.dart, and linter will prompt programmer that he can't override it

src/feature/app/logic/runner

Could be nice to move code-generated \src\core* into sub-folder \src\core\gen*
For example

\core\gen\const
\core\gen\localization
\core\gen\resource

Could be nice to make Makefile multi-platform

Currently Windows fire exceptions for the time and rm commands:

time : The term 'time' is not recognized as the name of a cmdlet, function, script file, or operable program

Remove-Item : A parameter cannot be found that matches parameter name 'rf'.
At line:1 char:4
+ rm -rf build .flutter-plugins .flutter-plugins-dependencies coverage  ...

Why is auto_route package required? I suppose, that would be better, when this project just use Navigator 2.0 approach without any of third party packages.

Possibly automate that task

Could be nice to replace AppTheme enum with sdk (dart:ui) Brightness.

Refactor EnvironmentStorage into EnvironmentDao that will be imported by ConfigurationRepository

AppLifecycleScope should mix in WidgetsBindingObserver with pre-defined, decompositioned stubs.

Uses rn

It is soon to be discounted, so it should be removed

Could be nice to reorganize App Scopes

DependenciesScope(child: RepositoryScope( - all this scopes data quite internal and could be nice to hide it from the below levels.
For example they could be joined into AppScope that will share only interfaces that could be visible below.

Could be nice to organize Scopes in more structured way, for example:
RootRestorationScope(restorationId: 'id', child:
AppEnvironmentScope(
child: AppInitScope(
child: AppAuthScope(
child: AppScope(
child: AppRouterScope(),

• without unneeded DependenciesScope.of(context).database visible everywhere and etc

Could be nice to place *Scope.dart in one place instead spread them into feature, core... folders

Could be nice to implement adaptive theme changes depend on screen width / etc
It could be small/medium/large presets for the

maxContentWidth
textStyles
colors
spacing
insets
borderRadius
* * * 

it could be common theme parameters as well

brightness
durations
* * *

For example, in apps with encryption, this scope will provide a shared instance of EncryptionService that will be used across different BLoCs.

Could be nice to move all initialization to the initialization BLoC.
App loading progress could be displayed better in this case.

await SentryInit.init(shouldSend: shouldSend);
await asyncDependencies();

Could be nice to add basic interface and scope to manage application user
Current/selected user could be optional - so starter could work without required login or user selection