-
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
[Management] Scripted fields table in React #16604
[Management] Scripted fields table in React #16604
Conversation
@@ -1,7 +1,7 @@ | |||
import _ from 'lodash'; | |||
import './index_header'; | |||
import './indexed_fields_table'; | |||
import './scripted_fields_table'; | |||
// import './scripted_fields_table'; |
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.
commented out code begone
@@ -140,4 +143,43 @@ uiModules.get('apps/management') | |||
$scope.indexPattern.timeFieldName = field.name; | |||
return $scope.indexPattern.save(); | |||
}; | |||
|
|||
$scope.tryToRenderScriptedFieldsTable = function () { | |||
if ($state.tab === 'scriptedFields') { |
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.
This file and a couple of others are just so bound up in Angular. Since we are supposed to be running away from Angular anyway, I wonder if it makes sense to take this Reactification work farther ?
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.
Yea I agree, but I think the focus should be on the tables for now to ensure those can go out sooner rather than later. Once the tables are in, I want to take a pass on the shell part (edit_index_pattern
)
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 guess I just worry about people looking at these squashed merged changes and taking them as patterns.
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.
And maybe there are bugs in all this glue code. Just seems better to get out of this to me.
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.
Yea I don't want that to happen, but converting this to React is probably more work than it seems because this is a shell that renders angular directives and getting those to work within a React shell seems complicated too.
What if I renamed the variables/functions in here to names that directly state to not use this and it's just a stopgap?
💔 Build Failed |
💔 Build Failed |
💚 Build Succeeded |
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.
Rad! This looks sweet. I had a few minor suggestions. Can we delete scripted_fields_table_angular.js
? Looks like it's not in use.
@@ -140,4 +142,45 @@ uiModules.get('apps/management') | |||
$scope.indexPattern.timeFieldName = field.name; | |||
return $scope.indexPattern.save(); | |||
}; | |||
|
|||
$scope.tryToRenderScriptedFieldsTable = function () { |
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.
Does this need to be a scope method? Can we just make it a local function?
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.
And a minor nit: can we rename it to updateScriptedFieldsTab
? I wasn't sure how to intuit its role from the word "try" in the name.
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.
Sure, I'll change it
} | ||
}; | ||
|
||
$scope.renderScriptedFieldsTable = function () { |
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 it makes sense to redefine this as a local function instead of a scope method (unless it needs to be on scope, but I don't think it does), and to move the logic from scripted_fields_table/index.js
into here instead.
This makes sense to me since it mirrors how this will be structured once we migrate to React. The owner of the <ScriptedFieldsTable />
instance will be responsible for providing the props it needs. I think it also simplifies the code a bit.
So it would be:
function renderScriptedFieldsTable() {
const node = document.getElementById(DOM_ELEMENT_ID);
if (!node) {
return;
}
render(
<ScriptedFieldsTable
indexPattern={$scope.indexPattern}
fieldFilter={$scope.fieldFilter}
scriptedFieldLanguageFilter={$scope.scriptedFieldLanguageFilter}
helpers={{
redirectToRoute: (obj, route) => {
$scope.kbnUrl.redirectToRoute(obj, route);
$scope.$apply();
},
getRouteHref: (obj, route) => $scope.kbnUrl.getRouteHref(obj, route),
}}
/>,
node,
);
}
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.
Sounds good!
return ( | ||
<div> | ||
<EuiCallOut | ||
title="Deprecation Warning" |
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.
According to our writing guidelines, this should be sentence case, "Deprecation warning." @gchaps Could you look over the copy below and provide feedback?
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.
Sure!
); | ||
} | ||
|
||
renderNoFieldsFound() { |
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.
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.
My comments for the screen above:
- Tab names should have init caps:
Fields
Scripted fields
Source filters
- I feel that this paragraph is overwritten
These scripted fields are computed on the fly from your data. They can be used in visualizations and displayed in your documents. However, they cannot be searched. You can manage them here and add new ones as you see fit, but be careful, scripts can be tricky!
My recommendation:
You can use scripted fields in visualizations and display them in your documents. However, you cannot search scripted fields.
- Button names use sentence case:
Add Scripted Field -> Add scripted field
- No scripted fields found. -> No scripted fields found (no ending punctuation)
For the screen below:
1)The delete button in the upper right is in red and the Delete button in the confirmation modal is blue. The color should be consistent. Red is typically used for Delete.
- Rewrite for the sentence starting with "This page.." as follows:
This page lists every field in the log* index and the field's associated core type as recorded by Elasticsearch. To change a field type, use the Elasticsearch Mapping API.
- For the Add button on the on the Source filter page, our guidelines say to follow Add by a noun, so
Add source filter
- I recommend cutting down on the text under Source filter and making it easier to scan, The text feels like a help topic
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.
Thanks!
1)The delete button in the upper right is in red and the Delete button in the confirmation modal is blue. The color should be consistent. Red is typically used for Delete.
@cjcenizal Is this supported in EUI now? I don't see a prop that looks like it will do it. Want me to add something?
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.
@chrisronline Yes please! Thanks!
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.
This pattern is super similar to what I've done so far for the indexed fields table so that's awesome 😄I'll adjust what I have to match more closely with this (just small changes).
I second CJ's comments about removing scripted_fields_table_angular.js
. I removed the old angular version for indexed fields table. Also +1 on hiding table when there aren't any fields to display.
Also saw a small bug where if you delete a field, the count on the tab doesn't update:
We've detected that the following deprecated languages are in use: {deprecatedLangsInUse.join(', ')}. | ||
Support for these languages will be removed in the next major version of Kibana and Elasticsearch. | ||
We recommend converting your scripted fields to <EuiLink href={painlessDocLink}>Painless</EuiLink>. | ||
</p> |
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.
Here's my suggested rewrite. I'd prefer to see a more descriptive title than Deprecation Warning
Deprecated languages in use
The following deprecated languages are in use: {deprecatedLangsInUse.join(', ')}. Support for these languages will be removed in the next major version of Kibana and Elasticsearch. Convert you scripted fields to Painless to avoid any problems.
@jen-huang Great catch! |
Thanks for the feedback everyone! PR is updated and ready for another pass! |
💚 Build Succeeded |
@chrisronline Another minor thing - long field names overlap the next column a bit too soon: I dealt with the same issue on indexed fields table. My fix includes setting |
Thanks @jen-huang! @cjcenizal does it make sense to fix something like that in EUI directly? |
@chrisronline Yes it absolutely does. We just need to remove the |
Great, I made a ticket to address that |
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!
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! I noticed that when a scripted field uses the default formatting the "Default" column is blank. Maybe it's worth showing the default value there?
Backport 6.x: 0060fd1 |
Fixes #16539
Relates to #15721
This PR converts the scripted field tables to using React/EUI.
cc @cjcenizal