Las 2 claves en la Modularización en Flutter, Clases y Métodos por parámetro

Quiero darte una clase que creo que vas a considerar muy interesante ya que cuando nosotras estamos desarrollando en Flurer ya que es fuertemente modular ya que todo en Flurer es un bendito widget podemos como quien dice dar por hecho de que nuestra aplicación que vayamos a crear aunque sea pequeña y mediana va a estar modularizada simplemente por eso pues no es más bien todo lo contrario según mi juicio por la facilidad que tenemos de empezar a agregar códigos con el Viso del Studio Code que fácilmente podemos empezar a agregar widget podemos caer como quien dice en esa falsa bueno en eso rompemos la modularización de nuestra aplicación y por lo tanto ya tú sabes perdemos que cabilidad mantenimiento un código peor bueno lo que tú entiendes obviamente si esto es para un cliente final y va a querer como quien dice luego seguir avanzando en la aplicación y le quiere presentar otro desarrollador obviamente el otro desarrollador no va a entender ni media papa de lo que estamos haciendo aquí porque es muy complicado código espaguete un poquito entonces como te digo eh ahí te di un pequeño ejemplo de eso.

Primer consejo, Métodos para desarrollos pequeños y clases para lo demás

Ya te dije el por qué ese es el como quien dice el contexto de todo esto entonces aquí yo te voy a dar solamente dos dos consejos el primero te lo va a dar justamente ahora cuándo emplear métodos o cuando emplear clases por ejemplo un state less widget que viene siendo las formas en las cuales tenemos para devolver un contenido en este caso por ejemplo suponte aquí el de las publicaciones que tenemos aquí un sencillo componente como este entonces yo emplearía ya para darte el primer consejo de ya yo emplearía los métodos para devolver un widget justamente si es algo extremadamente sencillo como esto aquí tenemos una imagen tenemos un texto por aquí tenemos el título y ya yo ahí emplaría perfectamente un método para reutilizar fácilmente.

Modularización de clases

El widget que vamos a analizar, es el visor web de la app de Academia para Flutter/Android, la cual tiene los siguientes elementos, es decir, lo primero que debemos hacer en estos casos es dividir funcionalmente lo que queramos implementar, en este ejemplo, un visor nativo con opciones de selección de texto y crear notas.

• Traducir HTML: HtmlToWidgets
• Selección de textos y mostrar burbuja: CustomTextSelectionOverlay
• Creación de notas: CreateBookNoteForm

Estos son los modulos que tienen nuestra app, y los módulos tienen que recibir los datos justamente necesarios. Te dejo mi implementación en base a clases:

HtmlToWidgets(
                            html: bookSectionModel.content,
                            sizeFactText: sizeText,
                            htmlNoteBook: htmlNoteBook,
                            callback: noteAdd,
                            setKeys: setKeys,
                          ),
***
class HtmlToWidgets extends StatelessWidget {
  ***
  /*const*/
  HtmlToWidgets({
    super.key,
    required this.html,
    required this.sizeFactText,
    this.callback,
    this.setKeys,
    this.htmlNoteBook = const {},
  });
***
_hightlightText(
                "   ${element.text}",
                element.attributes['id'] ?? idChild2,
                16 * sizeFactText,
                context,
                htmlNoteBook[element.attributes['id'] ?? idChild2],
                'SUSE'
              ),
***
Widget _hightlightText(
    String text,
    String idHTML,
    double fontSize,
    BuildContext context,
    HtmlNoteModel? htmlNoteBook, [
    String fontFamily = 'IBMPlexMono',
  ]) {
    ***
        if (tokenText == "") {
          return CustomTextSelectionOverlay(
            text,
            tokenText,
            idHTML,
            fontSize,
            callback!,
            // () => callback(id, tokenText),
          );
        }
      }
}

class CustomTextSelectionOverlay extends StatefulWidget {
  ***
}

class _CustomTextSelectionOverlayState
    extends State<CustomTextSelectionOverlay> {
  ***
                            child: CreateBookNoteForm(saveNote),

Como puedes ver en el código anterior, lo importante es ver las firmas de las clases recibe lo necesario para poder realizar su trabajo, y para las operaciones finales, se envia un la función como parámetro.

Un ejemplo de una implementación herronea, en donde una función recibe parámetros que NO va a usar directamente:

List<Widget> showSectionBookByHTML(
  String html,
  String tokenUser,
  int bookSectionId,
  Function noteAdd,
  BuildContext context, [
  Map<String, BookSectionNoteModel> bookSectionNotesModel = const {},
  double sizeText = 1.0,
]) {

En el ejemplo anterior, que es una implementación herronea, al no emplear clases no solamente se complica su gestión, al tener un monton de clases en un mismo nivel con distintos nombres, si no, tambien aqui estan recibiendo parámetros que no son empleadas justamente por la función; por ejemplo la de notas del usuario.

La función lo que hace es mostrar el contenido HTML, pero, las comentarios del usuario en las notas NO es una funcionalidad directa del visor, es un anexo u opcional de un visor nativo.

Gracias al a modularización con clases, pasamos como parámetros los métodos:

HtmlToWidgets(
                            html: bookSectionModel.content,
                            sizeFactText: sizeText,
                            htmlNoteBook: htmlNoteBook,
                            callback: noteAdd,
                            setKeys: setKeys,
                          ),