'1 bloc emitting a List of states vs many blocs are emitting their own state

Let's pretend we are drawing a chess table. We have a gameboard and 64 cells. We are smart enough to not build a whole board for a single move. I found 2 solutions for this situation.

  1. Create a GameBoard bloc that emits a cell state list that had 64 cell states. And listen every cell's state with "context.select" inside a Builder widget.
class Example1 extends StatelessWidget {
  const Example1({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    double size = MediaQuery.of(context).size.width / 8;
    return Scaffold(
      body: BlocProvider<GameBoardCubit>(
        create: (_) => GameBoardCubit(),
        child: Column(mainAxisAlignment: MainAxisAlignment.center,
          children: List.generate(
            8,
            (index1) => Row(
              children: List.generate(
                8,
                (index2) => Builder(
                  builder: (context) {
                    //Just for example
                    final state = context.select<GameBoardCubit, CellState>(
                        (value) => value.state[index1 * 8 + index2]);
                    return Container(
                      color: Colors.black,
                      margin: EdgeInsets.all(1),
                      height: size - 2,
                      width: size - 2,
                    );
                  },
                ),
              ),
            ),
          ),
        ),
      ),
    );
  }
}
class GameBoardCubit extends Cubit<List<CellState>> {
  GameBoardCubit() : super(List.generate(64, (index) => CellInitial()));

  void newState() => emit(List.generate(
      64, (index) => index % 2 == 0 ? CellNewState() : CellInitial()));
}

@immutable
abstract class CellState {}

class CellInitial extends CellState {}

class CellNewState extends CellState {}
  1. Create 64 blocs and every Builder listens to its own bloc.
class Example2 extends StatelessWidget {
  const Example2({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final blocList = List.generate(64, (index) => CellCubit());
    double size = MediaQuery.of(context).size.width / 8;
    return Scaffold(
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: List.generate(
          8,
          (index1) => Row(
            children: List.generate(
              8,
              (index2) => BlocProvider.value(
                value: blocList[index1 * 8 + index2],
                child: Builder(
                  builder: (context) {
                    //Just for example
                    final state = context.watch<CellCubit>();
                    // Accessing bloc
                    // blocList[15].newState();
                    return Container(
                      color: Colors.black,
                      margin: EdgeInsets.all(1),
                      height: size - 2,
                      width: size - 2,
                    );
                  },
                ),
              ),
            ),
          ),
        ),
      ),
    );
  }
}
class CellCubit extends Cubit<CellState> {
  CellCubit() : super(CellInitial());
  int counter = 0;
  void newState() {
    emit(counter % 2 == 0 ? CellNewState() : CellInitial());
    counter++;
  }
}

@immutable
abstract class CellState {}

class CellInitial extends CellState {}

class CellNewState extends CellState {}

Here is the question. Which way is more performant?

You could say it doesn't matter you will not notice any difference between them. Let's say it will gonna make 10 moves in a second.

The first one emits 10 new List that has 64 CellState, every second. This means there is always gonna be created a new CellState for non-changed states too.

The second one has 64 blocs which means 64 different streams.

Note: newState() is only for example. We don't know how many cells' states will be changed every move. And it's not for a chess game. Just a theoretical question.



Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source