-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Table Vis] Shim new platform #40732
Conversation
Pinging @elastic/kibana-app |
💔 Build Failed |
💚 Build Succeeded |
export const plugins: TablePluginSetupDependencies = { | ||
data: { | ||
expressions: { | ||
registerFunction: (fn: any) => functionsRegistry.register(fn), |
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're copying this function across all plugin defenitions.
Lets add it to data.expressions ASAP @ppisljar
import paginatedTableTemplate from './paginated_table.html'; | ||
|
||
import 'ui/directives/paginate'; | ||
export function PaginatedTable($filter) { |
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 like the idea of separating the component from the directive.
This way we can refactor these in place, and remove the directives later.
Think this is a good practice!
|
||
// Temporary solution | ||
// It will be removed when all dependent services are migrated to the new platform. | ||
__LEGACY: new LegacyDependenciesPlugin(), |
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.
@lukeelmers @streamich I like how this concept applies to the visualizations and solves the async deps problem.
I think you should have demoed this in our meeting!
I wonder how can this be applied to plugins that make more intensive use of Angular dependencies.
const Private = $injector.get('Private'); | ||
|
||
return { | ||
createAngularVisualization: VisFactoryProvider(Private).createAngularVisualization, |
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 like that you didn't end up exposing raw Angular deps here.
I wonder if this is the case for all visualizations.
But here it works great @streamich
💚 Build Succeeded |
💚 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.
Same comment about setup.ts
-> legacy.ts
as I added to the TSVB & Vega PRs. Otherwise LGTM!
💔 Build Failed |
# Conflicts: # src/legacy/core_plugins/table_vis/public/agg_table/agg_table.js # src/legacy/core_plugins/table_vis/public/agg_table/agg_table_group.js # src/legacy/core_plugins/table_vis/public/paginated_table/paginated_table.js # src/legacy/core_plugins/table_vis/public/table_vis_params.js
💚 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.
Ran through this manually locally confirming everything seems to work 👍 LGTM
.controller('KbnTableVisController', TableVisController) | ||
.directive('tableVisParams', TableVisParams); | ||
|
||
// todo: not sure that "kibana" is a right module for that directives |
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.
Not sure if this was meant to be a todo before checkin or not but seems like something to resolve before merging
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.
You might be able to get away with using kibana/table_vis
for everything since all of these directives are specific to the table vis at this point i think.
@lizozom do you have any insight on this?
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.
@lukeelmers @lizozom @nreese checked it again and looks like we can move all into one module without any risk. PR was updated
💚 Build Succeeded |
@@ -41,8 +41,7 @@ export interface TableVisualizationDependencies extends LegacyDependenciesPlugin | |||
|
|||
/** @internal */ | |||
export interface TablePluginSetupDependencies { | |||
// TODO: Remove `any` as functionsRegistry will be added to the DataSetup. | |||
data: DataSetup | any; | |||
data: ReturnType<DataPublicPlugin['setup']>; |
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.
👍 As discussed we'll update this later when we sort out the discrepancy between the src/plugins/data and src/legacy/core_plugins/data interfaces
* [Table Vis] Shim new platform * fix mocha tests * fix mocha tests * fix _agg_config test * cleanup * remove setup.ts * Set the correct type for the "Data" dependency
Summary
Part of #38245
1 Step of migrating to new Platform
What was done in this PR:
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.For maintainers