[Refactor/Chore] Audit workflow and RAG pipeline static loading boundaries

Abierto
#42,437 1 comentario 1 reacción 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
45/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript, vite

Línea de trabajo

Start with web/app/components/workflow/header/index.tsx, web/app/components/workflow-app/index.tsx, and web/app/components/rag-pipeline/components/panel/test-run/index.tsx. Reproduce the static dependency graph and measure production loading for workflow editing, pipeline editing, and snippets, tracing concrete eager import chains and existing dynamic imports. Done means justified boundaries with preserved editing, run/debug, history/restore, CRDT, and ELK behavior, plus before/after transferred JavaScript and request measurements.

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

Descripción

project#dify
Self Checks
  • I have read the Contributing Guide and Language Policy.
  • This is only for refactors or chores; questions belong in Discussions.
  • I have searched for existing issues, including closed ones.
  • I confirm that I am using English to submit this report.
  • 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
  • I have filled in the required template fields.
Description

Audit the client loading boundaries shared by workflow editing, RAG pipeline editing and snippets. A local Rolldown build produced a workflow-related shared header chunk of 1,143,158 bytes (about 294,139 bytes gzip), containing 579 project modules as well as third-party modules. Following its static manifest imports yields 379 JS files / 7.14 MB / approximately 2.11 MB gzip.

The chunk is statically referenced from workflow-app, the dataset pipeline page, several RAG pipeline panels, snippets, and workflow panels. Its generated name is not evidence that one header component alone is responsible.

Starting points:

This is an investigation/refactor task, not a confirmed claim that all of these bytes are unnecessary or fetched on every page. Identify which infrequently opened panels or feature dependencies are reachable statically, then choose boundaries based on actual route usage.

Motivation

A broad shared static dependency graph can cause workflows and pipeline surfaces to load functionality before it is needed. Measure route-level production requests before deciding which boundaries to change.

Acceptance criteria:

  • Reproduce the graph and record per-route production loading for workflow editing, pipeline editing and snippets.
  • Identify concrete eager import chains to optional functionality; defer only features that do not need to participate in initial rendering.
  • Preserve editing, run/debug, history/restore and shared state behavior. Existing history/restore wrappers already use dynamic imports, so confirm transitive reachability rather than assuming they are entirely eager.
  • Report before/after transferred JS and request behavior. Renaming chunks or increasing file count alone is not success.
  • Keep already-lazy CRDT runtime and ELK loading lazy; their large chunks are not included merely because they exist in the output.
Additional Context

Measurements come from a local Dify 1.17.1 development checkout (base commit 06e473015a9a1abb71da88ac0a0e92d96a992008, with local DevTools integration patches), using Vinext 1.0.0-beta.10 / Vite+ core 0.3.2 / Node 24.21.0. They are a diagnostic baseline, not a benchmark of an unmodified main checkout or a production network measurement. Related background: #30931 (closed).

Static dependency totals below follow manifest imports recursively, deduplicate files, and exclude dynamic imports, CSS, images and fonts. Gzip values are summed per-file estimates. Shared closures overlap and must not be added together.

Lenguaje dominante
TypeScript
Estrellas
157k
Forks
24.7k
Merge medio
22 h 32 min
PR fusionados (30 d)
611

Guía de contribución

Abrir la 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 langgenius/dify

Todos los issues de langgenius/dify

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.