Is StoreConnector<T, Tuple2<T,T>> an anti-pattern?

[seddonm1]

Coming from a ReduxJS/React background it is very common to pass multiple items from a redux store to a child component (e.g. using both mapStateToProps and mapDispatchToProps).

I have not seen in any example where you may want to pass both a state and a dispatcher to the same child component.

Is it considered correct to returning a tuple from a StoreConnector?

          // Connect the Store to a FloatingActionButton. In this case, we'll
          // use the Store to build a callback that with dispatch an Increment
          // Action.
          //
          // Then, we'll pass this callback to the button's `onPressed` handler.
          floatingActionButton:
              new StoreConnector<int, Tuple2<int, VoidCallback>>(
            converter: (store) {
              // Return a Tuple2 - one like mapStateToProps and one mapDispatchToProps
              // Return a `VoidCallback`, which is a fancy name for a function
              // with no parameters. It only dispatches an Increment action.
              return new Tuple2(
                  store.state, () => store.dispatch(Actions.Increment));
            },
            builder: (context, tuple) {
              return new FloatingActionButton(
                  // Attach the `callback` to the `onPressed` attribute
                  onPressed: tuple.item2,
                  tooltip:
                      tuple.item1.isOdd ? 'Increment_ODD' : 'Increment_EVEN',
                  child: new Icon(Icons.add));
            },
          ),
        ),

[brianegan]

Not at all! In fact, that's exactly what the ViewModel should be! A combination of State and Dispatchers.

You can see an example of this pattern here: https://github.com/brianegan/flutter_architecture_samples/blob/master/example/redux/lib/containers/todo_details.dart#L14

I generally prefer creating my own ViewModel classes instead of using Tuples, but that's just a matter of personal style.

[seddonm1]

Thanks for a very fast response Brian.

I have read through that code again and it makes a lot of sense. I think a model object for its readability over TupleN is worth it alone.