-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Stack monitoring] No-data page #110432
[Stack monitoring] No-data page #110432
Conversation
<EuiFlexGroup gutterSize="l" justifyContent="spaceBetween" responsive> | ||
<EuiFlexItem /> | ||
<EuiFlexItem> | ||
<div>HERE GOES THE TIMEPICKER</div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PageTemplate
seemed like too much for this tiny page, so I just copied over this timepicker placeholder. We'll have to update it once that's sorted for the main pages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's a tiny page if you look at the controller 😅
But we can also add it later if it's needed. Since the angular page for no data has the MonitoringMain
directive and the PageTemplate
has some of the logic of that directive I would think that maybe there is something needed from it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah maybe "tiny" is overstating it. What I meant was that since it doesn't ever have a title header or tabs, PageTemplate seemed like it might be too much.
I'll revisit once we have setup mode and $http
sorted, since it looks like NoData can't do much without those dependencies.
|
||
import { EuiFlexGroup, EuiFlexItem } from '@elastic/eui'; | ||
// @ts-ignore | ||
import { NoData as NoDataComponent } from '../../components/no_data'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know your thoughts on this naming. We could potentially call this NoDataPage
as an alternative, or rename the NoData component but I figured we should avoid trying to alter the angular UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer calling it NoDataPage
as it's how I would name it if I was implementing it from scratch. I don't think we alter the angular UI if we call it NoDataPage
since in Angular this is not a component it's a route definition.
Posting as draft for now since I'm sure there's work to do here before merging. Just opening it early for feedback. |
@elasticmachine update branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple of comments but I didn't test the PR, so I'm not sure of close you are to a working solution (If it's already working you can ignore the comments!).
Basically, I think if we make the model part of the state and we and we update it from the Enabler class, child components should be updated.
Most of the weird things in the Angular controller seem to be to make Angular aware that the model changed inside React components and to re-render them when this happened.
const model = { | ||
errors: [], // errors can happen from trying to check or set ES settings | ||
checkMessage: null, // message to show while waiting for api response | ||
isLoading: isLoading, // flag for in-progress state of checking for no data reason | ||
isCollectionEnabledUpdating: false, // flags to indicate whether to show a spinner while waiting for ajax | ||
isCollectionEnabledUpdated: false, | ||
isCollectionIntervalUpdating: false, | ||
isCollectionIntervalUpdated: false, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be part of the state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks! I was thinking the same but not sure if it should be one state object or discrete state variables for each (like I did with isLoading).
const { updateModel } = new ModelUpdater(model); | ||
const enabler = new Enabler(updateModel); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need the ModelUpdater class, if we make the model part of the state of the component, we could do something like this:
const { updateModel } = new ModelUpdater(model); | |
const enabler = new Enabler(updateModel); | |
const updateModel = (properties) => { | |
setModel({ | |
...model, | |
...properties | |
}) | |
} | |
const enabler = new Enabler(updateModel); |
EDIT: setModel
is not that simple... I didn't see that errors
is an array
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIce, thanks! I'll try out model as a state object and see show that goes.
@elasticmachine merge upstream |
@elasticmachine merge upstream |
Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work!
// TODO not sure if we can add this conditional, but might be required for smooth internal collection enablement | ||
// if (!this.isCollectionEnabledUpdating && !this.isCollectionIntervalUpdating) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were you able to figure out if this was necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not really clear yet. I sometimes get a refresh of "we couldn't enable monitoring" that might be rooted in these conditionals missing. But I haven't been able to cleanly add them without leading to weird dependency cycles.
const [model, setModel] = useState({ | ||
errors: [], // errors can happen from trying to check or set ES settings | ||
checkMessage: null, // message to show while waiting for api response | ||
isLoading: true, // flag for in-progress state of checking for no data reason | ||
isCollectionEnabledUpdating: false, // flags to indicate whether to show a spinner while waiting for ajax | ||
isCollectionEnabledUpdated: false, | ||
isCollectionIntervalUpdating: false, | ||
isCollectionIntervalUpdated: false, | ||
} as any); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think you need to change it for this PR, but usually you would want these to all be separate variables. For example: const [isLoading, setIsLoading] = useState(true)
. You usually want to group things in objects if they are updated at the same time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was wondering about that. Thanks for the cross check.
The no data flow in angular seemed to contain a lot of updateModel
type code so I thought this approach might be better to keep the diff smaller even it's not great practice.
|
||
const clusterCheckers: SettingsChecker[] = [ | ||
{ | ||
message: 'Checking cluster settings API on production cluster', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to i18n.translate
this string
api: '../api/monitoring/v1/elasticsearch_settings/check/cluster', | ||
}, | ||
{ | ||
message: 'Checking nodes settings API on production cluster', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to i18n.translate
this string
@elasticmachine merge upstream |
This replicates how the angular app did selective re-rendering of the react component, but while still being able to render the component.
Fixed this caveat in the latest push.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: cc @matschaffer |
* Basic no-data page * Rename to NoDataPage * Add getData property to pass into EuiSuperDatePicker from pages * Wire getData and redirect for no data page * Draft port of isLoading & model updating * Add todo on handling checkers * Switch to model as state object * Add checkers * Porting enabler * Fix build checks * Attempting to smooth out enablement * Clean up CI errors * Fix breadcrumbs * Fix linter warning * Fix checkers dependency (I hope) * Hook up catchReason * Add a stub for react setup mode * Clean warnings * Fix toggleSetupMode by calling initSetupModeState first * Translating checker strings * typo on "xpack" * Move isCollection/reason check in NoData This replicates how the angular app did selective re-rendering of the react component, but while still being able to render the component. Co-authored-by: Kibana Machine <[email protected]>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
* Basic no-data page * Rename to NoDataPage * Add getData property to pass into EuiSuperDatePicker from pages * Wire getData and redirect for no data page * Draft port of isLoading & model updating * Add todo on handling checkers * Switch to model as state object * Add checkers * Porting enabler * Fix build checks * Attempting to smooth out enablement * Clean up CI errors * Fix breadcrumbs * Fix linter warning * Fix checkers dependency (I hope) * Hook up catchReason * Add a stub for react setup mode * Clean warnings * Fix toggleSetupMode by calling initSetupModeState first * Translating checker strings * typo on "xpack" * Move isCollection/reason check in NoData This replicates how the angular app did selective re-rendering of the react component, but while still being able to render the component. Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Mat Schaffer <[email protected]>
Summary
A no-data react page that uses the NoData react component.
There is still one caveat:
But I think there's still benefit to merging this to help provide a better "no data" dev experience.
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers
Fixes #112217