NIFI-14319: Create initial project structure for new NiFi Registry UI #9855

sardell · 2025-04-07T22:04:11Z

Summary

Description

This PR establishes the initial project setup for the new NiFi Registry UI and includes the new explorer view.

Testing

Build and start the old registry project with maven using the existing instructions. Next, run npm ci at nifi-frontend/src/main/frontend and start the app by running npx nx run nifi-registry:serve. Visit http://localhost:4204/nifi-registry/ to see the new explorer page. Compare the old explorer view with the new one, ensuring feature parity between the two views. Run unit tests with npx nx run nifi-registry:test.

NOTE: buckets cannot be created through the new UI yet, so in order to test the functionality of the new explorer view you must first create a bucket through the old UI.

Considerations

Styling - The old logo was created with a much darker background color in mind. It may be time for a refreshed logo, but for now I simply added the old one to the header along with a heading containing the application's name.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

Apache NiFi Jira issue created

Pull Request Tracking

Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

Pull Request based on current revision of the main branch
Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

Build completed using mvn clean install -P contrib-check
- JDK 21

Licensing

New dependencies are compatible with the Apache License 2.0 according to the License Policy
New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

Documentation formatting appears as expected in rendered files

exceptionfactory

Thanks for this work on NiFi Registry @sardell!

The standard ci-workflow builds are failing, does this build locally for you, or is this still a work in progress that should be marked as draft?

sardell · 2025-04-08T21:39:32Z

@exceptionfactory Thanks for raising the failing CI to my attention. It looks like the failure was due to the favicon missing from the old registry ui directory. I accidentally deleted it when copying over images to the new project. I noticed the missing file while working on this PR and added the file back, but it seems that file was accidentally added to the .gitignore (I think intention of that .gitignore line was to ignore the generated favicon, not all instances of that file). I believe this is why I could successfully build locally and also see the CI failures you pointed out.

Fingers crossed the CI passes this time. I'll keep an eye on it.

UPDATE: Looks like the CI build is now failing on a build step that runs fine locally. Will need to investigate a little further.

exceptionfactory

Thanks for the update @sardell, although the build completes on macOS, it is failing on Linux and Windows.

On Linux, there appears to be something platform-dependent:

[INFO] ::group::❌ > nx run shared:build:production
[INFO] 
[INFO] Building Angular Package
[INFO] 
[INFO] ------------------------------------------------------------------------------
[INFO] Building entry point '@nifi/shared'
[INFO] ------------------------------------------------------------------------------
[INFO] - Compiling with Angular sources in Ivy full compilation mode.
[INFO] ✖ Compiling with Angular sources in Ivy full compilation mode.
[INFO] 
[INFO]  NX   The package "@esbuild/linux-x64" could not be found, and is needed by esbuild.

elcsiga

looks good for the 1st glance, I post my first comments, will continue the review soon

nifi-frontend/src/main/frontend/apps/nifi-registry/src/styles.scss

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/ui/header/header.component.ts

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/state/droplets/droplets.effects.ts

...olorer/feature/ui/import-new-flow-version-dialog/import-new-flow-version-dialog.component.ts

...ry/src/app/pages/expolorer/feature/ui/droplet-table-filter/droplet-table-filter.component.ts

scottyaslan

@sardell thanks for the PR! I have left several comments on things that need to be addressed. Apologies that there are so many comments as I know this is a big undertaking and your effort here is appreciated. I am sure I will have more comments after you make the requested changes.

Also, I didn't have a great place to leave the following comments so placing them here:

Please run prettier and lint:fix. There are several strange formatting issues.

Please delete nifi-registry/public directory and the favicon.ico.

nifi-frontend/src/main/frontend/apps/nifi-registry/project.json

nifi-frontend/src/main/frontend/apps/nifi-registry/.eslintrc.json

...rc/app/pages/expolorer/feature/ui/delete-droplet-dialog/delete-droplet-dialog.component.html

sardell · 2025-05-27T20:36:18Z

@scottyaslan @elcsiga Thank you both for taking the time to review this PR! I've addressed all your comments. When you have a chance, could you please take another look?

@scottyaslan I've updated the Jira tickets for the Registry UI work to be tasks organized under an epic per your suggestion. I've also started breaking down the work into much smaller chunks (see the ticket for the buckets view and its subtasks for an example). I'll continue this work for the users and groups view.

sardell · 2025-06-11T16:22:22Z

@scottyaslan @elcsiga Could you please re-review when you have time?

scottyaslan · 2025-06-23T14:18:50Z

Reviewing...

scottyaslan

Hey @sardell! I have reviewed this PR and it is looking good. There are still several things to get dialed in but all in all this is headed in the right direction. Please let me know if you have any questions or comments or if you need any clarity on my latest set of comments.

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/ui/header/header.component.scss

...ifi-registry/src/app/ui/header/common/context-error-banner/context-error-banner.component.ts

...orer/feature/ui/import-new-flow-version-dialog/import-new-flow-version-dialog.component.html

scottyaslan · 2025-06-24T00:19:37Z

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/service/droplets.service.ts

+        });
+    }
+
+    getDropletSnapshotMetadata(dropletUri: string): Observable<any> {


Can we do better than Observable<any> here? It would be better if we had some types defined.

I can manually type out all of these response interfaces in this PR, but we use Observable<any> for most of the http response types in NiFi. I think if we want to have stronger typing for our API responses it would be much better to leverage a package that generates Typescript interfaces from backend schemas. Not only would it save us a ton of time doing manual work but we also get the big advantage of ensuring the contract between the frontend and the backend isn't broken at build time.

scottyaslan · 2025-06-24T00:19:47Z

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/service/droplets.service.ts

+        });
+    }
+
+    exportDropletVersionedSnapshot(dropletUri: string, versionNumber: number): Observable<any> {


Can we do better than Observable<any> here? It would be better if we had some types defined.

.../app/pages/expolorer/feature/ui/import-new-flow-dialog/import-new-flow-dialog.component.html

...src/main/frontend/apps/nifi-registry/src/app/pages/expolorer/feature/explorer.component.html

scottyaslan · 2025-06-24T21:57:53Z

...d/src/main/frontend/apps/nifi-registry/src/app/pages/expolorer/feature/explorer.component.ts

+        this.store
+            .select(selectQueryParams)
+            .pipe(takeUntilDestroyed())
+            .subscribe((queryParams) => {
+                if (queryParams) {
+                    this.filterTerm = queryParams['filterTerm'] || '';
+                    this.filterBucket = queryParams['filterBucket'] || 'All';
+                    this.filterColumn = queryParams['filterColumn'] || '';
+                    this.dataSource.filter = JSON.stringify(queryParams);
+                }
+            });
+    }


I have a few thoughts here:

First, no other listing in nifi preserves the filters, sortings, etc via query params. I see a few issues currently with having these query params with back/forward navigation and row selection while keeping the query params in sync. Also the handling of erroneous values for query params, handling erroneous query params, etc. seems to be missing.

Secondly, the routes in this new NiFi registry application explorer view do not behave the same way as the legacy UI and I think we need to honor the existing routes. Users from the existing NiFi Registry may have bookmarks etc and expect those to work and since NiFi Registry is part of the NiFi release I don't think we want to have breaking changes like this in a minor release. It is kind of like an api.

Both of these thoughts lead me to request that you remove the query params from the url for filtering, sorting, etc. Just let the user land at the explorer perspective and let them apply a filter, sort, etc. Instead we can use deep links like the legacy UI.

Now, if we look at the routes from legacy NiFi Registry legacy UI then /explorer/grid-list takes the user to the listing of all resources. explorer/grid-list/buckets/<bucket-id> takes the user to the listing of all resources in . And explorer/grid-list/buckets/<bucket-id>/flows/<resource-id> takes the user to a single resource in the listing.

I think for this effort we can support the same routes and deep links. /explorer/grid-list would route to the explorer.component and would take the user to the listing of all resources. explorer/grid-list/buckets/<bucket-id> would also route to the explorer.component but would set the formcontrolname="filterBucket" to the bucket-id which would then show only the resources in that bucket in the listing. Then for explorer/grid-list/buckets/<bucket-id>/flows/<resource-id> it would also route to the explorer.component, set the formcontrolname="filterBucket" to the bucket-id which would then show only the resources in that bucket in the listing, and would select the in the listing.

Secondly, the routes in this new NiFi registry application explorer view do not behave the same way as the legacy UI and I think we need to honor the existing routes. Users from the existing NiFi Registry may have bookmarks etc and expect those to work and since NiFi Registry is part of the NiFi release I don't think we want to have breaking changes like this in a minor release. It is kind of like an api.

Couldn't we just add a redirect to handle legacy urls instead of locking into a convention that IMO is not very intuitive? Additionally, is the expectation really to have no breaking changes whatsoever when rewriting an entire UI? Why wouldn't we just follow semantic versioning if there are breaking changes?

I think most people would agree that nifi-registry/#/resources/<resource-id> is much simpler and easier to understand than nifi-registry/resources/grid-list/buckets/<bucket-id>/flows/<resource-id>. I think path parameters make sense when viewing a specific resource, but it's pretty common convention to use query parameters to handle the persistence of filter values selected on a page.

I'm fine not persisting filter values since we don't persist them in NiFi, but if we do want to support that in the url I don't think the deep linking you're proposing is the way we should it. Long urls like that make sense on the canvas, where it's a drill-down view of nested components without a filter, but we aren't doing that in list views. For example, when you look at the summary of a processor in NiFi, the url is nifi/#/summary/processors and not nifi/#/summary/process-groups/<process-group-id>/processors.

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/ui/header/header.component.ts

scottyaslan · 2025-06-24T22:25:29Z

nifi-frontend/src/main/frontend/apps/nifi-registry/src/app/state/error/error.actions.ts

+export const fullScreenError = createAction(
+    '[Error] Full Screen Error',
+    props<{ errorDetail: ErrorDetail; skipReplaceUrl?: boolean }>()
+);
+
+export const snackBarError = createAction('[Error] Snackbar Error', props<{ error: string }>());
+
+export const addBannerError = createAction('[Error] Add Banner Error', props<{ errorContext: ErrorContext }>());
+
+export const clearBannerErrors = createAction('[Error] Clear Banner Errors', props<{ context: ErrorContextKey }>());
+
+export const resetErrorState = createAction('[Error] Reset Error State');
+
+export const setRoutedToFullScreenError = createAction(
+    '[Error] Set Routed To Full Screen Error',
+    props<{ routedToFullScreenError: boolean }>()
+);


Are you really using all of these actions in this PR? If not, let's delete the ones we aren't using and we can bring them back when we need them for the next feature we work.

scottyaslan · 2025-06-24T22:28:49Z

@sardell also please run npx nx run prettier:fix.

scottyaslan · 2025-06-24T22:32:17Z

...src/main/frontend/apps/nifi-registry/src/app/pages/expolorer/feature/explorer.component.html

+<div class="pb-5 px-5 flex flex-col h-full">
+    <div class="h-full flex flex-col">
+        <h3 class="primary-color">Flows</h3>
+        <div class="flex justify-between items-baseline">


We likely also need a context banner above the table here. If the resources fail to load we need a place to inform the user. This should also have a unique context.

I might be misunderstanding, but aren't context banners intended for dialogs? I currently show an error page if the main resources don't load.

scottyaslan · 2025-06-24T22:33:07Z

...src/main/frontend/apps/nifi-registry/src/app/pages/expolorer/feature/explorer.component.html

+            </div>
+        </div>
+        @if (droplets$ | async; as droplets) {
+            <droplet-table 


How does the user know if the registry is empty versus a filter is applied and no resources are in the listing because they do not match the filter?

I originally had a different message explaining the difference, but you didn't think it was needed because of the filtered count (which I still agree with).

* check if window.matchMedia has value before calling method * add empty states to explorer table * destroy direct store subscriptions * add filtered count to droplet table filter

* Linux solution: https://github.com/evanw/esbuild/issues/1819\#issuecomment-2426254293 * Windows solution: nrwl/nx#29551

* fix error service

* fix multiple namings * template cleanup * configuration changes to align better with NiFi * style fixes

* use px units instead of calc for logo container * use unique contexts for dialog errors * update explorer page title * margin and sizing class updates * run prettier to fix formatting issues

scottyaslan · 2025-08-02T14:53:16Z

@sardell I hope to get back to reviewing this next week. Sorry for the delay!

exceptionfactory reviewed Apr 8, 2025

View reviewed changes

exceptionfactory requested changes Apr 9, 2025

View reviewed changes

sardell force-pushed the NIFI-14319 branch from 13a332d to 17f4c38 Compare April 9, 2025 17:45

sardell requested a review from exceptionfactory April 9, 2025 19:51

mcgilman added the ui Pull requests for work relating to the user interface label Apr 24, 2025

sardell force-pushed the NIFI-14319 branch 2 times, most recently from bd6fd83 to 74df539 Compare April 28, 2025 23:42

elcsiga reviewed Apr 29, 2025

View reviewed changes

scottyaslan requested changes May 5, 2025

View reviewed changes

sardell force-pushed the NIFI-14319 branch from 52f42f2 to 50ca383 Compare May 19, 2025 18:33

sardell requested a review from scottyaslan May 21, 2025 04:47

exceptionfactory mentioned this pull request Jun 7, 2025

Bump webpack-dev-server from 4.7.3 to 5.2.1 in /nifi-registry/nifi-registry-core/nifi-registry-web-ui/src/main #9990

Closed

sardell force-pushed the NIFI-14319 branch from e90e3ee to 1cfb01c Compare June 20, 2025 19:34

scottyaslan requested changes Jun 24, 2025

View reviewed changes

sardell and others added 10 commits July 17, 2025 17:30

NIFI-14319: init new registry app

65bc15b

NIFI-14319: add unit test coverage

c5810b0

NIFI-14319: update redirect value

d323227

Remove commented code in droplet filter

465a44d

NIFI-14319: remove commented code from current user effects

7048b32

NIFI-14319: remove commented code from bucket reducer

d08161f

NIFI-14319: remove commented code from index.ts

16df1c6

NIFI-14319: address initial feedback

e74480f

* check if window.matchMedia has value before calling method * add empty states to explorer table * destroy direct store subscriptions * add filtered count to droplet table filter

NIFI-14319: add wrongly removed favicon back to old project

c22dbaa

NIFI-14319: fix CI build failures

6760bf7

* Linux solution: https://github.com/evanw/esbuild/issues/1819\#issuecomment-2426254293 * Windows solution: nrwl/nx#29551

sardell added 14 commits July 17, 2025 17:31

NIFI-14319: fix alt value used for registry logo

b16e460

NIFI-14319: review feedback

8c2b698

* fix error service

NIFI-14319: address naming and formatting feedback

05e13a6

NIFI-14319: address review feedback

1d23c47

* fix multiple namings * template cleanup * configuration changes to align better with NiFi * style fixes

NIFI-14319: refactor droplet table into standalone component

84da9c6

NIFI-14319: align banner error handling with NiFi UX

49eff61

NIFI-14319: align file upload UX with NiFi UI

9bbe72e

NIFI-14319: additional dialog header and button style tweaks

9d9b55b

NIFI-14319: update logo styling

092e0f2

NIFI-14319: error handling improvements

78195c6

NIFI-14319: use NiFi file pick UX in import new flow dialog

eea1ff8

NIFI-14319: remove unused directory

94bbc67

NIFI-14319: cleanup action types and fix missing import description

2db479a

NIFI-14319: address feedback

0d281df

* use px units instead of calc for logo container * use unique contexts for dialog errors * update explorer page title * margin and sizing class updates * run prettier to fix formatting issues

sardell force-pushed the NIFI-14319 branch from 1cfb01c to 0d281df Compare July 17, 2025 22:31

sardell added 5 commits July 18, 2025 14:17

NIFI-14319: move context error into shared lib

f48d4fe

NIFI-14319: remove current user code

5f48a80

NIFI-14319: remove old context error code from registry

7e6863e

NIFI-14319: update explorer naming to resources

e80c0b6

NIFI-14319: remove circular dependency

30c5dce

NIFI-14319: Create initial project structure for new NiFi Registry UI #9855

Are you sure you want to change the base?

NIFI-14319: Create initial project structure for new NiFi Registry UI #9855

Uh oh!

Conversation

sardell commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Description

Testing

Considerations

Tracking

Issue Tracking

Pull Request Tracking

Pull Request Formatting

Verification

Build

Licensing

Documentation

Uh oh!

exceptionfactory left a comment

Choose a reason for hiding this comment

Uh oh!

sardell commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

exceptionfactory left a comment

Choose a reason for hiding this comment

Uh oh!

elcsiga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

scottyaslan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sardell commented May 27, 2025

Uh oh!

sardell commented Jun 11, 2025

Uh oh!

scottyaslan commented Jun 23, 2025

Uh oh!

scottyaslan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

scottyaslan Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sardell Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scottyaslan Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

scottyaslan Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

sardell commented Apr 7, 2025 •

edited

Loading

sardell commented Apr 8, 2025 •

edited

Loading

scottyaslan Jun 24, 2025 •

edited

Loading

sardell Jul 17, 2025 •

edited

Loading

scottyaslan Jun 24, 2025 •

edited

Loading

sardell Jul 22, 2025 •

edited

Loading