pub package Codemagic build astatus codecov

Adds ability to specify used BLoCs on the widget level.


Specify wanted blocs per screen in YAML file, like so:

  widget: FancyWidget
    - BlocA : 12 # provide config for bloc after :
    - BlocB :
        - field1: "hello"
        - field2: "world"
    - BlocC@foo : "enemy" # use @ to provide named blocs
    - BlocC@bar : "friend"

Use BlocPluginBuilder to provide mappings for your blocs:

  .addBaseBloc<BlocA>((routeContext, config, repository) => /* return BlocA here */)

where repository gives you access to other blocs from your the scope of your page.

Class Hierarchy & Bloc Plugin Builder

Flutter Dart has no reflection and runtimeType doesn't contain information about parent classes, therefore voyager bloc plugin builder has specific API to address this issue:

If your bloc class (e.g. ParentBloc) is extending directly from Bloc use:

addBaseBloc<ParentBloc>((routeContext, config, repository) {
    return ParentBloc();

If your bloc doesn't extend directly from Bloc but e.g. from ParentBloc you will want to use:

addBloc<ChildBloc, ParentBloc>((routeContext, config, repository) {
    return ChildBloc();

Schema Validator

If you're using schema validation with voyager:codegen you can add the following to cover basics

  output: BlocRepository
  import: 'package:voyager_bloc/voyager_bloc.dart'
    type: array

Accessing Blocs

Once you are working in the buildContext of Widget you can obtain BlocRepository

final repo = Provider.of<Voyager>(context)["blocs"];

or if you use generated strong types:

final repo = VoyagerProvider.of(context).blocs;

From there you can find blocs by type, e.g.:

final blocA = repo.find<BlocA>();

...and if your bloc was given a specific name, then supply name parameter:

final fooBlocC = repo.find<BlocC>(name: "foo");





Foreign Function Interface for interoperability with the C programming language. [...]


HTML elements and other resources for web-based applications that need to interact with the browser and the DOM (Document Object Model). [...]
Low-level support for interoperating with JavaScript. [...]
Utility methods to efficiently manipulate typed JSInterop objects in cases where the name to call is not known at runtime. You should only use these methods when the same effect cannot be achieved with @JS annotations. These methods would be extension methods on JSObject if Dart supported extension methods.