-
Notifications
You must be signed in to change notification settings - Fork 24
Conversation
Need to update http url
* change position of index-management in kibana side bar * remove logo from side bar menu
Output for running
|
return response.custom({ | ||
statusCode: 200, | ||
body: { | ||
ok: true, | ||
response: results, | ||
}, | ||
}); |
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.
Rather than response.custom
, you can use the given response.ok
which will return a statusCode
of 200
by default.
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.
Was using response.ok
but resulted in a lot of type error. So changed back to response.custom
. Thanks for the reminder.
@@ -27,6 +27,7 @@ interface ChangeManagedIndicesProps { | |||
onChangeManagedIndices: (selectedManagedIndices: { label: string; value?: ManagedIndexItem }[]) => void; | |||
onChangeStateFilters: (stateFilter: { label: string }[]) => void; | |||
managedIndicesError: string; | |||
core: CoreStart; |
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.
Since I see you are wrapping all of the UI components in a core services consumer, you should be able to access the services via context (like how AD does it here), rather than passing a core
object via props
. This would simplify your components from having to add a core
prop for all components and/or subcomponents that need to access the core services for toasts, breadcrumbs, etc. More info here
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.
In my mind, accessing object via Context or props depends on the usage frequency of the object.
If an object are utilized in most of the components from the parent to the child, passing that through props
maybe looks better. While, if the object is only used in few components, especially the deepest component, accessing the object via Context
like AD plugin does (and AD features in Alerting Kibana plugin as well) definitely much simpler.
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.
Modified code to get core from context instead of passing props.
onStateSelectChange={() => {}} | ||
selectedPoliciesError="" | ||
/> | ||
<CoreServicesContext.Provider value={coreServicesMock}> |
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.
Did you need to wrap all of these in the provider since you're already passing it below as props? Should only need the provider if you're consuming the context internally in NewPolicy. And maybe look into Tylers comment, this seems like a lot of nested passing.
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.
Changed to let components access core by context. So the passing core as props arguments are removed.
@@ -34,6 +34,7 @@ interface NewPolicyProps { | |||
onChangePolicy: (selectedPolicies: PolicyOption[]) => void; | |||
onChangeStateRadio: (optionId: string) => void; | |||
onStateSelectChange: (e: React.ChangeEvent<HTMLSelectElement>) => void; | |||
core: CoreStart; |
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.
Should try to limit what you're passing down. We don't need this giant core object, we just need the notifications service. You can use that in the props and pass it as core.notifications in whoever renders 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.
This is what I did in Alerting Kibana plugin inspired by Yan's previous comment: https://github.com/opendistro-for-elasticsearch/alerting-kibana-plugin/blob/master/public/pages/Main/Main.js#L61. Drew please feel free to leave comment, and I will also keep an eye on how core
will be passed here in Index Management plugin.
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.
Refactored code to get core from context. Removed arguments to pass core as props.
type Server = Legacy.Server; | ||
|
||
export default function(server: Server, services: NodeServices) { | ||
export default function (services: NodeServices, router: IRouter) { |
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.
Was the validations a requirement of the new framework? If we are going from no validations -> validations can you just confirm each API works as expected on Kibana.
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.
Tested. Everything should work fine.
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.
But I don't think validation is required for new platform.
*/ | ||
|
||
import { AppMountParameters, CoreSetup, CoreStart, Plugin, PluginInitializerContext } from "../../../src/core/public"; | ||
import { IndexManagementPluginSetup } from "."; |
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 I've ever seen from "."
🤔
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 is because the interfaces IndexManagementPluginSetup
and IndexManagementPluginStart
are defined in ./index.ts
Issue #, if available: N/A
Description of changes:
Bump plugin version to 1.12.0.0
Bump Kibana version to 7.10.0
Bump node version to 10.22.1
Changed year of license for multiple files
Remove
index.js
andpublic/app.js
and haveRemoved dependencies in package.json to avoid duplicate imports
Browser side changes:
Add
public/index.ts
,public/index_management_app.tsx
, andpublic/plugin.ts
to define entry pointAdd CoreStart prop for components
Changes to toast notification to be added by
core.notifications
Breadcrumbs of pages are now set by
core.setBreadcrumbs
For APIs that require query string, a query object will be used as parameter instead of forming a query string. This is due to the http client function not decoding the query correctly with a query string.
Update the browser side services to replace legacy angular
IHttpService
andIHttpResponse
with newHttpSetup
andHttpResponse
Server side changes:
Add
server/index.ts
,server/plugin.ts
as server side entry point and configurationUpdate route definitions to support new platform
Update route handlers to support new platform
Some rollup data model fix in interface file
Other:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.