[
https://issues.apache.org/jira/browse/NIFI-15708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18065434#comment-18065434
]
Scott Aslan commented on NIFI-15708:
------------------------------------
Hello, and thank you for submitting this ticket. Hopefully I can answer some of
your questions.
You mentioned your specific concern is the way the nifi theme is 'injected'
into advanced ui's. This is not fully accurate. All of the @nifi/shared
components are available and used across the nifi, nifi-registry,
standard-content-viewer, nifi-jolt-transform-ui, and update-attribute
applications. Each of these applications are part of the Nx monorepo we
leverage for the frontend source code, assets, dependency management, etc. If
you look at the styles.scss file in each application you can see that the theme
is modular such that only the styles for the component used by that application
need to be included. This style.scss file is loaded in the head of any of our
ui's.
These shared components are already available to any application in the Nx
monorepo and are used by both the update-attribute and the
nifi-jolt-transform-ui advanced ui's.
Any new frontend UI applications should also live in this Nx monorepo. Mvn
should be leveraged to then take those build artifacts and include them in any
.nar, .jar, .war.
The only 'injected' part of the theme is when an advanced ui is displayed in an
iframe within the nifi application. In that case, the advanced ui could have
been built with a different theme than the nifi ui. Since all of these ui
applications are built with the same design system from @nifi/shared they all
leverage the same css tokens we use that to our advantage and when an advanced
ui is displayed in an iframe in the nifi ui the frontend takes the current
token values from the parent nifi and injects them into the iframe ui
application to override the token values there. This ensures that the advanced
ui running in an iframe within the nifi ui application will have the same
colors and theme regardless of whether or not the advanced ui was originally
built with a different theme.
Why do you propose exposing @nifi/shared as an npm package? If you are
building a new advanced ui application you should be able to follow what has
been done for the nifi-jolt-transform-ui or the update-attribute applications.
Once you have the Nx project.json and the style.scss the theme and design
system should be setup and you should be able to import any of the components
directly from @nifi/shared via `import xyz from '@nifi/shared';`. Distributing
an npm package requires versioning, testing, documentation.... That is a lot of
overhead for a community. It is not impossible though and I have pondered this
approach over the years (see nifi-fds) but ultimately the theme and design
system implementation of components provided by @nifi/shared are really only
meant to support the nifi ui and any ui application that are part of the larger
nifi ecosystem (i.e. part of the Nx monorepo). As such, to date, these
components are not syndicated anywhere outside of the nifi frontend Nx
monorepo. If you have a good use case here it could be the catalyst for
publishing and maintaining a package.
> [Advanced UI] Ease providing additional Advanced UIs leveraging NiFi Theme
> logic
> --------------------------------------------------------------------------------
>
> Key: NIFI-15708
> URL: https://issues.apache.org/jira/browse/NIFI-15708
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Affects Versions: 2.8.0
> Reporter: Denis GARET (AmeXio)
> Priority: Major
>
> *As* a developer extending NiFi with extra capabilities
> *I want to* be provided with helpers / integrated mechanisms
> *In order to* ease building Advanced UIs for custom components (keeping
> overall UX consistency)
> My specific concern is around the way *NiFi theme* is injected into advanced
> UIs.
> * The "nifi-frontend" module provides valuable assets to be reused across
> various "Advanced UIs for custom components" (as it is the case for OOTB
> Advanced UIs such as UpdateAttribute or JOLTTransformJSON)
> * In order to keep overall UI/Theme consistent for other advanced UIs I plan
> to leverage such elements
> * At the time being I did not find a proper way to achieve this rather than
> copy/pasting existing "source code files" (subfolder
> src/main/frontend/libs/shared from module nifi-frontend into my own
> repository/modules
> Would there be another way to achieve this objective of keeping UX/Theme
> consistent when developing addintional Advanced UIs for custom components ?
> (I may have missed some documented instructions/hints to setup an alternate
> strategy)
> Aternatively, would it be possible to consider anticipating smoother
> extension mechanisms for Advanced UIs such as
> * (ideal) Exposing the @nifi/shared package/bundle in order to make it
> reusable in other Advanced UIs (my understanding being that it is currently
> only available locally when building the nifi-frontend module
> * (acceptable workaround that would require less effort I guess) Adapt
> configuation applicable for the maven-source-plugin on module nifi-frontend
> in order to have the associated publishedjar
> (nifi-frontend-<version>-sources.jar) contain frontend source files (I guess
> the default plugin configuration makes it ignore non java files) so that
> custom developments could reuse it through maven-dependency-plugin
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
