Conversation
| import { page } from 'vitest/browser'; | ||
|
|
||
| import { mockConsoleMethod, renderApp } from '../test-utils'; | ||
| import { mockConsoleMethod, mockDelay, renderApp } from '../test-utils'; |
There was a problem hiding this comment.
Fixing some flaky tests due to slow requests when opening the resilience group.
| const { selectExplorerNode } = await renderApp('/nexus_malformed'); | ||
|
|
||
| // `default` attribute points to non-existant entity | ||
| await selectNexusExplorerNode('default_not_found'); |
There was a problem hiding this comment.
These malformed entities no longer have the "NX" badge.
| test('visualize NXnote group', async () => { | ||
| await renderApp('/nexus_note'); | ||
| expect(page.getByText('"energy": 10.2')).toBeVisible(); | ||
| }); |
There was a problem hiding this comment.
We weren't testing the NX Note visualization
| test('visualize default dataset', async () => { | ||
| const { selectExplorerNode } = await renderApp('/entities'); | ||
| await selectExplorerNode('default_dataset'); | ||
| expect(page.getByText('foo')).toBeVisible(); | ||
| }); |
There was a problem hiding this comment.
Test case for a group with a default attribute that points to a simple dataset. We were already supporting but not testing this use case. The person who sent us the feedback about the NX badge provided a file with such a use case.
| <span className={styles.name}>{entity.name}</span> | ||
|
|
||
| <ErrorBoundary fallback={null}> | ||
| {isGroup(entity) && ( |
There was a problem hiding this comment.
Checking for groups here saves us from fetching other entities metadata, like datasets.
| <Icon className={styles.icon} /> | ||
| <span className={styles.name}>{entity.name}</span> | ||
|
|
||
| <ErrorBoundary fallback={null}> |
There was a problem hiding this comment.
NxBadge now silences errors to avoid cluttering the browser console and tests when resolving malformed entities.
1 participant
We received feedback by email that the behaviour of the "NX" badge in the explorer is confusing.
The goal of the badge is to indicate entities that have a supported NeXus visualization. In the current implementation, we compromised accuracy in favour of limiting strongly the amount of metadata requested by simply checking for the presence of a
defaultattribute or specificNX_classattribute (NXdata,NXentryorNXprocess).In this PR, when deciding whether to show the NX badge, I propose to use the same resolution algorithm we use for finding supported visualizations. This includes looking for implicit "default" children, old-style NXdata (with a "signal" dataset), NXnote, etc.
Once I have the supported visualization, I check if any of the supported visualizations is a NeXus visualization before showing the badge, since the
defaultattribute can very well point to a dataset instead of anNXdatagroup. I add a mock example and a test case for this.Because of the implicit default child algorithm, the new implementation effectively fetches the metadata of every root group on first render, and of every child group when selecting a group. If it encounters a
defaultattribute on a group, it also fetches its value and recurses, and it if encounters NeXus attributes likesignalorinterpretation, it also fetches their values as per our NeXus visualizations resolution algorithm. Overall, this can lead to a number of extra requests depending on the file, which can stack up and block other requests and delaying expanding a group or showing a default visualization. The silver lining is that when the user selects a child group, the metadata for the group itself is already available, so the little spinner no longer appears.