Move DashboardEmptyScreen inside DashboardViewport#51939
Move DashboardEmptyScreen inside DashboardViewport#51939majagrubic merged 29 commits intoelastic:masterfrom
Conversation
There was a problem hiding this comment.
noop for now as we're not in fact adding visualizations yet.
There was a problem hiding this comment.
noop for now, this is where the new logic for adding the visualization will live.
There was a problem hiding this comment.
The empty screen needs to be inside dashboardViewport, but mustn't be inside inside data-shared-items-container or else its content will be included in the report generation. This DOM structure effectively means we could have emptyScreen AND dashboard panels rendered on the screen at the same time, but if the state is always reset appropriately, this should never happen.
There was a problem hiding this comment.
Instead of leaving it as a possibility to render both at the same time, should we specifically case the renderings? I wouldn't bet on state always being reset appropriately 😬 (though maybe I'm a pessimist).
There was a problem hiding this comment.
Adding a new panel means it's not an empty state any more, so need to reset.
💔 Build Failed
|
💔 Build Failed
|
|
Jenkins, test this |
💔 Build Failed
|
|
Jenkins, test this |
c7f1ffb to
a34c220
Compare
💔 Build Failed |
💔 Build Failed |
|
I updated the code again, since the empty state was not being reset properly, which caused the exit fullscreen button to being rendered twice, which was messing the functional test. I updated that one functional test as well, I still don't understand how it was ever passing. |
💔 Build Failed |
|
Jenkins, test this |
💚 Build Succeeded |
|
@elasticmachine merge upstream |
| } | ||
| $scope.showSaveQuery = dashboardCapabilities.saveQuery as boolean; | ||
|
|
||
| $scope.getShouldShowEditHelp = () => |
There was a problem hiding this comment.
Why are those put on the scope? I can't find a place in angular where they are used
There was a problem hiding this comment.
good point. they were on the scope previously, so I just left them there, but it's true that there's no good reason why they should remain there.
| dashboardContainer.renderEmpty = () => { | ||
| const shouldShowEditHelp = $scope.getShouldShowEditHelp(); | ||
| const shouldShowViewHelp = $scope.getShouldShowViewHelp(); | ||
| const isEmptyState = shouldShowEditHelp || shouldShowViewHelp; |
There was a problem hiding this comment.
It seems like those two functions are always used like this. Would it make sense to put them into a single function and just call it directly here?
There was a problem hiding this comment.
No, there is distinction between edit and view screen, it's used in the getEmptyScreenProps to decide which screen should be rendered.
| <h2>{constants.fillDashboardTitle}</h2> | ||
| {showLinkToVisualize ? addVisualizationParagraph : enterEditModeParagraph} | ||
| </React.Fragment> | ||
| <EuiPage className="dshStartScreen" restrictWidth={'36em'}> |
There was a problem hiding this comment.
Nit: could use restrictWidth="36em"
| if (!isErrorEmbeddable(container)) { | ||
| dashboardContainer = container; | ||
|
|
||
| dashboardContainer.renderEmpty = () => { |
There was a problem hiding this comment.
It feels like we are mixing responsibilities here. From my perspective, the dashboard app and the dashboard container are two separate pieces of code that serve different purposes.
Is it absolutely necessary the container knows about the empty state panel? Couldn't we make that a private detail of the app to keep the interface between the container and the app as small as possible (not injecting the renderEmpty function in a kind of dirty way into the container)? For example we could not render the container at all as long as it's empty and directly render the empty screen from the app itself in line 317:
instead of
container.render(dashboardDom);we are calling
if (isEmpty) {
reactDom.render(<DashboardEmptyScreen {...propsNStuff} />, dashboardDom);
} else {
container.render(dashboardDom);
}Now if there is an important reason the dashboard container has to know it can be empty, would it make more sense have the empty screen component living in the dashboard container itself instead of the dashboard app? In that scenario the app would just pass in a boolean prop like showEmptyScreen or something like this and the container would take care of the rest.
There was a problem hiding this comment.
Please see one of my comments above. Empty screen needs to live inside the dashboardViewport, mainly for the reporting to work properly. data-shared-items container needs to remain where it is. Removing that wrapper will cause the report of empty screen to fail. Putting it around DashboardEmptyScreen means the content of the empty screen will be included in the report.
There was a problem hiding this comment.
Now if there is an important reason the dashboard container has to know it can be empty, would it make more sense have the empty screen component living in the dashboard container itself instead of the dashboard app? In that scenario the app would just pass in a boolean prop like showEmptyScreen or something like this and the container would take care of the rest.
I am not quite sure I fully understand this question, but I think there are two things to note:
- The props of the empty screen are still unfortunately defined on the
dashboard_app_controller: https://github.com/elastic/kibana/pull/51939/files#diff-b2738a4dec941f426bf944b70d057b75R185 DasbhoardContaineris receivingrenderEmptyin "a hacky way" as it can't go through input, because all inputs must be serializable
There was a problem hiding this comment.
Synced offline with @majagrubic and I see how the places things are placed ties into the further plans with this, so this LGTM. Nits can be addressed, but it's not blocking the PR.
|
thank @flash1293 and @streamich for all the help in getting this done 🙇♀ lots more refactoring coming, stay tuned 🎉 |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
cchaos
left a comment
There was a problem hiding this comment.
My comments aren't vital to merging this PR, but something to consider changing now. Otherwise we can do a follow-on PR.
| <EuiPageBody> | ||
| <EuiPageContent verticalPosition="center" horizontalPosition="center"> | ||
| <EuiIcon type="dashboardApp" size="xxl" color="subdued" /> | ||
| <EuiSpacer size="s" /> | ||
| <EuiText grow={true}> | ||
| <h2 key={0.5}>{constants.fillDashboardTitle}</h2> | ||
| </EuiText> | ||
| <EuiSpacer size="m" /> | ||
| {showLinkToVisualize ? addVisualizationParagraph : enterEditModeParagraph} | ||
| </EuiPageContent> | ||
| </EuiPageBody> | ||
| </EuiPage> |
There was a problem hiding this comment.
This whole thing can actually be simplified using the EuiEmptyPrompt component. But I can do that in a follow up PR.
There was a problem hiding this comment.
This screen is going to change soon, so I would suggest against additional refactoring of it now.
| const { renderEmpty } = this.props; | ||
| const { isFullScreenMode } = this.state; | ||
| return ( | ||
| <div className="dshDashboardEmptyScreen"> |
There was a problem hiding this comment.
This class is only used for tests and has not styles attached to it so its been better practice to use it as a data-test-subj instead. This way if styles were to be added or such, there wouldn't be conflicts between tests and styles.
| return ( | ||
| <React.Fragment> | ||
| {this.state.isEmptyState ? this.renderEmptyScreen() : null} | ||
| {this.renderContainerScreen()} |
There was a problem hiding this comment.
If you render only the empty state or the container screen, then the split background color problem will be gone.
There was a problem hiding this comment.
I'm afraid this needs to stay as is for reporting to work properly for now. But I'm planning on a bigger refactor that will hopefully eliminate this hack then.
| height: 100% !important; /* 1. */ | ||
| width: 100%; | ||
| position: absolute; | ||
| position: absolute !important; |
There was a problem hiding this comment.
The /* 1. */ comment refers to the comment at the top explaining this part, can you also add this comment indicator to the end of this line.
|
Thanx @cchaos, will address some of your comments in a follow-up PR. |
* Prototyping adding Visualization to Dashboard * i18n fixes * Remvoing dashboard empty screen directive * Updating test for empty dashboard screen * Removing unused state variable * Adding a test for DashboardViewPort * i18n & minor fixes * Fixing fullscreen mode view * Fixing failing functional test (hopefully) * Minor style fix * Fixing EUI text, rendering empty screen OR the panels * Fixing empty screen in fullscreen mode * Update snapshot * Trying to render empty screen from Angular controller * refactor: 💡 don't pass renderEmpty through inputs And make sure isEmptyState is not stale. * Fixing tests after Vadim's commit * Removing unnecessary isEmptyStateProps * Skipping failing test * Removing unnecessary en.json file * Re-adding emptyState, reintroducing functional test * Fixing ja-JP file * Undoing my thing to the functional test
* Prototyping adding Visualization to Dashboard * i18n fixes * Remvoing dashboard empty screen directive * Updating test for empty dashboard screen * Removing unused state variable * Adding a test for DashboardViewPort * i18n & minor fixes * Fixing fullscreen mode view * Fixing failing functional test (hopefully) * Minor style fix * Fixing EUI text, rendering empty screen OR the panels * Fixing empty screen in fullscreen mode * Update snapshot * Trying to render empty screen from Angular controller * refactor: 💡 don't pass renderEmpty through inputs And make sure isEmptyState is not stale. * Fixing tests after Vadim's commit * Removing unnecessary isEmptyStateProps * Skipping failing test * Removing unnecessary en.json file * Re-adding emptyState, reintroducing functional test * Fixing ja-JP file * Undoing my thing to the functional test


Summary
Intro
As part of the Dashboard-first project, we'll need to add Visualization from the dashboard. I was prototyping this flow, and there was a visible flick where the empty dashboard screen was still shown before the visualization appeared, visible from the GIF below:

What this PR contains?
For the flick to go away, empty screen needs to be inside
DashboardViewport. This PR refactors the code so thatDashboardEmptyScreenis rendered insideDashboardViewportand gets all the relevant info it needs to render through container input.What this PR does not contain?
This PR does not actually add visualization from the dashboard. It does not change the layout nor the actions of the empty dashboard screen. It will be added in a subsequent PR for easier review.
How best to review this?
I've add some comments to the relevant places below to help with the review. Some things to look out for: panel rendering, time application, fullscreen mode, report generation.
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.For maintainers