Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Consider avoid using base Use Case classes to avoid redundant code

Abierto
  • ¿Algo no está bien?
#60 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
dart
Área
tooling

Línea de trabajo

Localiza las clases base de los casos de uso y sus implementaciones, y después revisa custom_lint y los ejemplos de validadores enlazados. La tarea estaría completada al eliminar la herencia sin perder un método público run coherente y añadir validación visible en el IDE; no se indican archivos ni pruebas específicos, por lo que es necesario investigar el alcance.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The problem

The base use case classes like UseCase, StreamUseCase etc bring us only one benefit: they keep the use cases interface consistent. They force us to use the run method.

But we never operate with use cases using their base classes, e.g. you will never see

final UseCase<int, int> _calculateSomethingUseCase = injector<CalculateSomethingUsecase>();

It will always be:

final CalculateSomethingUseCase _calculateSomethingUseCase = injector<CalculateSomethingUseCase>();

But by using the base class we are forced to always have a single parameter in the run method. If we'd need two or more parameters, we would be forced to create an Input class. This is:

  • Not convenient
  • Expands our code base for no reason
// Bad
_myUseCase.run(MyInput(param1: 0, param2: 1));

// Good
_myUseCase.run(param1: 0, param2: 1);
The solution

Remove the inheritance from all the use cases. But then we will have to somehow ensure that all the use cases follow the same interface, having a public run method.

We could use this GitHub action to validate our pull requests to have the same use case structure. You can find an example here, it has a valid PR and an invalid PR.

But it is less convenient than a linter rule that could highlight the error in our IDE right when we code, not when we submit a PR.

So... We can create a linter rule that would validate our use case classes. custom_lint could be used for this purpose — but it needs investigation.

Lenguaje dominante
Dart
Estrellas
36
Forks
23
Sin PR fusionados en 30 d

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ml-opensource/flutter-template

Todos los issues de ml-opensource/flutter-template

Issues similares

Más issues de Dart

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.