Bloc generator. Request for creating more detailed template of the bloc.

[1g0rrr]

The generator is useful, but users need to write a lot of code on top of it. My suggestions:

1. Create basic states: We only have 4 states in every bloc: Initial, Success, Failure, InProgress. Why not create it immediately? Or at least a couple of them.

class BlocNameInProgress extends BlocNameState {
  const BlocNameInProgress ();
}

2. Create a sample event. It will be easier to copy or change it, instead of writing from scratch:

class SampleActionHandled extends BlocNameEvent {
  const SampleActionHandled();
}

3. Create sample conversion from event to state. It will be easier to copy existing code and cause fewer errors in the conversion function. (I had problems with all this yields, in process of learning BLoC).

  @override
  Stream<BlocNameState> mapEventToState(
    BlocNameEvent event,
  ) async* {
    if (event is SampleActionHandled) {
      yield* _mapSampleActionHandledToState(event, state);
    }
  }

  Stream<BlocNameState> _mapSampleActionHandledToState(
    SampleActionHandled event,
    BlocNameState state,
  ) async* {
    yield BlocNameSuccess();
  }

4. Set Equatable checked by default or remove this checkbox. BlocBuilder without Equatable just rebuilds everything every time. For a better understanding of the whole reactive programming concept, it's a good idea to learn equatable from the start. I know it could cause problems when people forget to override "props", but now as I can see, there is another problem, newbies just omit this checkbox. Maybe we can describe Equatable and 'props' more in comments in code to prevent its misuse?

5. Create a folder for the bloc It's useful to have a folder with the bloc name. Could be a checkbox in dialog.

[LeonIPierre]

1. I have a code snippet that this based on the 5 product states (empty, partial, loading, ideal, error here's a good read on each https://www.scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack/) below is an example output. I added a message at the top for new users to have a better understanding on how states are handled. @felangel do you think it would be better served to have the states in separate files via an extension?

///Basic application states. By default Bloc only updates when the incoming
///and previous state difer(see https://bloclibrary.dev/#/faqs?id=state-not-updating) so change the 'props' property
///to ensure the states are different
abstract class TestState extends Equatable {}

class TestIdealState extends TestState {
  final TestResult result;
  TestIdealState(this.result);
  @override
  List<Object> get props => [result];
}

class TestEmptyState extends TestState {
  @override
  List<Object> get props => [];
}

class TestErrorState extends TestState {
  final String message;
  TestErrorState(this.message);

  @override
  List<Object> get props => [message];
}

class TestLoadingState extends TestState {
  final int progress;
  TestLoadingState({this.progress});

  @override
  List<Object> get props => [progress];
}

2, 3. This is an interesting one. Events tend vary a lot based on the context of the app. Maybe just add a comment to the current snippet that points the user to the current tutorial example? 4. Agree :) 5. The VSCode extension (see here: https://github.com/felangel/bloc/tree/master/extensions/vscode) are you referring to something different?

[mikededo]

Would it be possible to create the different events and then, the generator would create all _mapEventNameToState in the mapEventToStare function? Or to create an option that would build so. I have no experience in building vscode extensions, but I will give it a look.

[tenhobi]

Over the years, these things have already evolved in some way. Since there has been no update for 3 years, I am closing this issue.