El esqueleto de un plugin

El esqueleto

use tauri::{plugin::{Builder, TauriPlugin}, Manager, Runtime};pub struct MiEstado {    // lo que el plugin necesita recordar}pub fn init<R: Runtime>() -> TauriPlugin<R> {    Builder::new("miplugin")        .invoke_handler(tauri::generate_handler![comandos::hacer_algo])        .setup(|app, _api| {            app.manage(MiEstado::nuevo()?);      // el estado del plugin            Ok(())        })        .on_event(|_app, evento| {            // ganchos del ciclo de vida. Fase IV        })        .build()}

Y en la aplicación que lo usa, una línea:

tauri::Builder::default().plugin(mi_plugin::init())

El nombre del plugin es importante: prefija todos sus comandos y aparece en los permisos. Se elige una vez y cambiarlo rompe a quien lo use — igual que los identificadores del nivel 39.2.

El estado

Un plugin puede tener el suyo, con las mismas reglas de la fase IV:

• Se registra en el arranque y vive mientras la aplicación.
• Es accesible desde sus comandos y, si es público, desde la aplicación anfitriona.
• Y hay que decidir si es público: exponerlo permite a quien use el plugin acceder desde su propio código Rust, y ata tu implementación interna a tu API. Casi siempre conviene que sea privado y exponer funciones en su lugar.

Los ganchos

Y el primero merece atención: un plugin que hace trabajo pesado en su configuración inicial alarga el arranque de todas las aplicaciones que lo usen. Nivel 57.2, desde el otro lado.

Diseñar la API

Las dos decisiones que determinan si se usa bien:

La cuarta merece énfasis: un plugin que solo expone comandos obliga a que todo pase por el puente, incluso cuando quien lo usa quiere llamarlo desde Rust. Exponer las dos capas —funciones y comandos que las envuelven— es el diseño correcto.