[jira] [Updated] (NIFI-16009) Refactor frontend theming to eliminate centralized component-theme mixin registration pattern

["Scott Aslan (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIFI-16009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Aslan updated NIFI-16009:
-------------------------------
    Issue Type: Improvement  (was: Bug)

> Refactor frontend theming to eliminate centralized component-theme mixin registration pattern
> ---------------------------------------------------------------------------------------------
>
>                 Key: NIFI-16009
>                 URL: https://issues.apache.org/jira/browse/NIFI-16009
>             Project: Apache NiFi
>          Issue Type: Improvement
>            Reporter: Scott Aslan
>            Assignee: Scott Aslan
>            Priority: Major
>
> The NiFi frontend currently uses a two-part pattern to apply per-component theming: a {{_*.component-theme.scss}} file alongside each component containing a {{generate-theme()}} mixin, plus a registration in each app's {{styles.scss}} that {{{}@use{}}}s every theme file and {{{}@include{}}}s every mixin inside an {{html {}}} block. This pattern has two structural problems.
> Redundancy. Angular Material v15+ (MDC) expresses all theming through CSS custom properties ({{{}--mat-sys-*{}}}, {{{}--nf-*{}}}). These cascade to all descendants automatically. There is no scenario in which calling {{@include canvas.generate-theme()}} inside {{html {}}} produces a different result than those same styles placed in {{{}canvas.component.scss{}}}. The global registration was emitting the same CSS as the component stylesheet would have — the {{styles.scss}} mixin registry was redundant by construction.
> Scalability. As applications grow toward lazy-loaded feature modules, bundling all component styles into the eager {{styles.scss}} bundle unnecessarily inflates initial load. Styles that belong to a specific feature should be delivered with that feature.
> Changes:
>  * Delete all {{_*.component-theme.scss}} files across {{{}apps/nifi{}}}, {{{}apps/nifi-jolt-transform-ui{}}}, {{{}apps/standard-content-viewer{}}}, and {{apps/update-attribute}} (25 files total); migrate each component's styles into its own {{*.component.scss}}
>  * Migrate shared library component themes ({{{}resizable{}}}, {{{}property-hint-tip{}}}) to their component stylesheets
>  * Move {{{}_app.scss{}}}, {{{}_listing-table.scss{}}}, {{{}_prism-theme.scss{}}}, and {{_tailwind-theme.scss}} from {{libs/shared/src/assets/styles/}} into the design system directory ({{{}libs/shared/src/assets/themes/{}}}); wire through {{material.scss}} which becomes the sole eager orchestrator
>  * Reduce all four app {{styles.scss}} files to ~30 lines containing only framework-level entries (Tailwind, fonts, material theme, Font Awesome)
>  * Audit all {{::ng-deep}} usage — retain only where Angular's template compiler does not create the target DOM (D3/SVG elements, CodeMirror, CDK overlay portals, child component internals); add explanatory comments to each usage
>  * Update {{libs/shared/src/assets/themes/README.md}} to document the new architecture
>  * Add {{.cursor/rules/ng-deep.mdc}} documenting the {{::ng-deep}} decision criteria
> No functional changes. This is a pure refactor. Dark mode behavior is unchanged — the {{.darkMode}} token rebind lives in {{material.scss}} and all component styles use {{--mat-sys-*}} / {{--nf-*}} custom properties that resolve correctly for both modes without any per-component {{.darkMode}} block.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)