flutter_modular

Feature modules can now consume shared/core dependencies

A feature module's module-level bind (addSingleton, add, addLazySingleton) now resolves dependencies registered in a root-owned shared/core module (a path-less module(...)). Previously only page-scoped provide binds could reach the core; a feature's module-level binds ran in a leaf injector blind to root-owned binds, forcing shared deps to be threaded in by hand.

A core consumer can now be a provide, the core itself, or a feature module-level bind — all alike. A feature's own bind still shadows a same-typed core bind (local wins; core is the fallback).

Requires auto_injector >= 2.2.0

Adds the opt-in upward resolution (addInjector(child, resolveUpward: true)) this builds on, fixes a dispose-listener accumulation in its layer graph, and adds an UpwardResolutionCycle guard against mutual upward links.

Docs

New dependency-injection.md sections: cross-module resolution and the async bootstrap idiom (await once in a Future<Module> builder so main stays thin and features take no parameters).

Full changelog: https://pub.dev/packages/flutter_modular/versions/7.1.0/changelog

• Feature modules can now consume shared/core dependencies directly. A module-level bind inside a feature (a module with a path) — addSingleton, add, addLazySingleton — now resolves dependencies registered in a root-owned shared module (a path-less module(...), the "core"). Previously only page-scoped provide binds could reach the core; a feature's module-level binds ran in a leaf injector that couldn't see root-owned binds, forcing shared deps to be threaded in by hand. This removes that asymmetry: a core consumer can be a provide, the core itself, OR a feature module-level bind — all alike. A feature's own bind still shadows a same-typed core bind (local wins; core is the fallback).
• Requires auto_injector >= 2.2.0, which adds the opt-in upward resolution (addInjector(child, resolveUpward: true)) this builds on, fixes a dispose-listener accumulation in its layer graph, and adds an UpwardResolutionCycle guard against mutual upward links.

• Customizable route transitions. route(transition:) and the new app-wide ModularApp(defaultTransition:) now accept any PageTransition, an open contract that builds the route's Page. Three ways to supply one:
  • the TransitionType presets (material, fade, none) — each value now is a PageTransition, so existing transition: TransitionType.fade keeps working;
  • CustomTransition — the inline convenience: pass a transitionsBuilder (same signature as PageRouteBuilder) and optionally tune duration/reverseDuration/opaque/barrierColor/ barrierDismissible/fullscreenDialog; Modular still owns the Page;
  • implement PageTransition yourself for full control of the Page (e.g. a CupertinoPage with swipe-back, a fullscreenDialog, shared-axis from the animations package).
• App-wide default. ModularApp.defaultTransition (default TransitionType.material) applies to every route that doesn't declare its own. Precedence: route-local → app default → material. route(transition:) now defaults to null (inherit the app default) instead of forcing material.

• context.select<T, R>(selector) — the method-based twin of the Selector widget. Reads a value derived from a page-scoped T and rebuilds the calling widget only when the selected value changes (==). Mirrors context.select from provider to ease migration; call it from build.

📦 Published on pub.dev: https://pub.dev/packages/flutter_modular/versions/7.0.1

Page-scoped BLoC/Cubit support

• Scoped.addStreamable<T>(ctor, (t) => t.stream, (t) => t.close()) — exposes the object itself via context.watch<T>() (read its synchronous state, call its methods) while rebuilds are driven by its stream. flutter_modular keeps no dependency on the bloc package (stream/close are caller callbacks). See the docs for a suggested addBloc extension covering both BLoC and Cubit.
• addListenable<T>(ctor, (t) => t.listenable, (t) => t.dispose()) — for objects whose reactivity is a Listenable property.

Simpler non-reactive registration

• add<T>(ctor) — non-reactive page-scoped object, readable via context.read/watch, disposed on unmount when it implements Disposable. Breaking: replaces addDisposable (removed; the Disposable interface is retained).

Internals

• addChangeNotifier reexpressed over addListenable; watch/read/Consumer/Selector now accept any Object (not just Listenable), so a non-Listenable reactive object can be exposed. Fully backward compatible.

Full Changelog: https://github.com/Flutterando/modular/blob/master/CHANGELOG.md

• Page-scoped BLoC/Cubit support. New Scoped.addStreamable<T>(ctor, (t) => t.stream, (t) => t.close()) exposes the object itself via context.watch<T>() (read its synchronous state, call its methods) while rebuilds are driven by its stream — flutter_modular keeps no dependency on the bloc package (stream/close are caller callbacks). Companion addListenable<T>(ctor, (t) => t.listenable, (t) => t.dispose()) for objects whose reactivity is a Listenable property. See the docs for a suggested addBloc extension covering both BLoC and Cubit.
• add<T>(ctor) — non-reactive page-scoped object, readable via context.read/watch and disposed on unmount when it implements Disposable. Breaking: replaces addDisposable, which is removed (the Disposable interface is retained).
• addChangeNotifier reexpressed over addListenable; watch/read/Consumer/Selector now accept any Object (not just Listenable), so a non-Listenable reactive object can be exposed.

• Fix #713
• Fix #676
• Fix #632

• Fix: Parse params in RouteOutlet

• Support Cubit

• Support Flutter 3.0.0
• [BREAK CHANGE]: Removed MaterialApp.modular() and Cupertino().modular().
  Use instead:

    return MaterialApp.router(
      routeInformationParser: Modular.routeInformationParser,
      routerDelegate: Modular.routerDelegate,
    );
  

This modification aims to keep Modular support independent of WidgetApp updates, and can be used in other bootstraps such as FluentApp [fluent_ui].

• [BREAK CHANGE]: New auto-dispose configuration.
  Previously Modular had automatic closing or destruction calls for objects of type ChangeNotifier/ValueNotifier, Stream and Triple`s Stores.
  Starting with version 5.0, Modular will provide the Bind.onDispose property for calls to destroy, close or dispose methods FOR EACH BIND. This will make the dispose settings more straightforward and less universal. Therefore, Modular will manage the destruction of Binds that implement Disposable only. This is the new configuration:

@override
final List<Bind> binds = [
  Bind.singleton((i) => MyBloc(), onDispose: (bloc) => bloc.close()),
];

The Bind.onDispose CANNOT be used in Bind type factory.
You can choose to use Bind.onDispose or implement the Disposable class.

• Added Bind.selector. Generates a reactivity (Listenable/Stream) to be listened to when context.watch() is called.

@override
final List<Bind> binds = [
  //notifier return stream or listenable to use context.watch()
  Bind.singleton((i) => MyBloc(), onDispose: (bloc) => bloc.close(), selector: (bloc) => bloc.stream),
];

• [BREAK CHANGE]: As already described above, the reactivities worked externally to Modular, providing a
  longer life to the project. For this reason, BLoC or Triple users should use special Bind's in order to use the context.watch() and auto dispose functionality. They are: BlocBind() and TripleBind(), which are available through external packages.
  modular_bloc_bind -> BlocBind
  
  modular_triple_bind -> TripleBind

Example:

@override
final List<Bind> binds = [
  BlocBind.singleton((i) => MyBloc()),
];

• [BREAK CHANGE] Bind.export works only after imported.

• @deprecated ModularState.
  A few months of research showed us that ModularState caused unnecessary coupling with the view and made it difficult for those who used it to understand. For this reason, we decided to deprecate it to ensure code congruence for all professionals who use Modular.

• Removed triple dependency.

• Simplify docs.

• Added Modular.setArguments.

Modular.setArguments('cody1024d');

// get
Modular.args.data; // -> cody1024d
//or
Bind((i) => MyClass(i.args.data));

Issues

• Fix #615
• Fix #643
• Fix #644
• Fix #666
• Fix #668
• Fix #681
• Fix #694