-
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
[Dashboard] [Controls] Refactor controls services #138668
[Dashboard] [Controls] Refactor controls services #138668
Conversation
e37dfc0
to
ec90a48
Compare
Pinging @elastic/kibana-presentation (Team:Presentation) |
a01f43f
to
5b64202
Compare
94ebb0d
to
4581e79
Compare
4581e79
to
b66b09c
Compare
[CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
935cc40
to
9c26a01
Compare
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 just an initial code review. I'm loving how clean and uniform the controls code is looking! I'm gonna check out this branch and test locally before I approve.
Here are a few nits, but none of them are blockers.
src/plugins/controls/public/control_group/editor/edit_control.tsx
Outdated
Show resolved
Hide resolved
src/plugins/controls/public/control_group/editor/create_control.tsx
Outdated
Show resolved
Hide resolved
src/plugins/controls/public/control_group/editor/edit_control_group.tsx
Outdated
Show resolved
Hide resolved
@@ -29,3 +27,5 @@ export type OptionsListReduxState = ReduxEmbeddableState< | |||
ControlOutput, | |||
OptionsListComponentState | |||
>; | |||
|
|||
export * from '../../common/options_list/types'; |
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.
Why was this line moved to the bottom of the file? Just curious
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 was making it match the range_slider
types file, which also has it at the bottom. But I could move both to the top instead? Don't really have a strong preference - what are your thoughts?
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.
Hmmmmm I guess you can leave it at the bottom. It's an export so it's not like we need to group all of them at the top. We have a clear pattern for imports, but I don't think we've discussed exports. I don't know that we need to organize exports in any particular way besides just having them below imports? What do you think @ThomThomson
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.
Where are these exports being used? Can we not just import from common in those places rather than reexporting here? I think it's usually best not to re-export if it can be avoided, because it can make things more difficult to follow.
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.
Very fair point - the common
export actually seems to be used more frequently than the re-exported public
types (at least for options list - haven't checked range slider yet), so I think it makes the most sense to just avoid re-exporting stuff even if it results in shorter paths 👍 I'll make the change to this PR since it should be only a few changes
@@ -6,7 +6,7 @@ | |||
* Side Public License, v 1. | |||
*/ | |||
|
|||
import { OptionsListRequest, OptionsListResponse } from '../options_list/types'; | |||
import { OptionsListRequest, OptionsListResponse } from '../../../common/options_list/types'; |
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 we come to a consensus about exporting all types from the root types
file in common
, public
, and server
? I think it'd look nicer if we imported from ../../../common/types
because I prefer shorter import paths, but this isn't a dealbreaker.
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.
Hmmm... I honestly don't remember if we decided that, haha! :) I looked in to it and it seems like this would require a lottt of import changes if we wanted to be consistent with it - for example, src/plugins/controls/public/control_group/types.ts
is exporting stuff from ../../common/control_group/types
and so I would have to go through and change all of the imports of .../public/control_group/types.ts
to use the common
import instead.
Totally cool doing that, but I don't think it makes sense to make all those changes as part of this PR - maybe I could make a follow up PR that cleans up all exports/imports to make them consistent if @ThomThomson agrees that shorter import paths is better? I honestly don't have a strong preference so I'm good with either 😆
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 that within a plugin having longer import paths is fine. If we're in a file related to options_list
in public and we have to import from ../../../common/options_list/types
I think that works great because it ties the disparate parts of the plugin together nicely.
…enawter/kibana into refactor-controls-services_2022-08-10
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 👍 Pulled down the changes and didn't encounter any new bugs
09eecd4
to
e987d9c
Compare
e987d9c
to
114d649
Compare
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsasync chunk count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @Heenawter |
* Restructure services folder and change all imports * Fix export of controls service * Fix import of plugin services to be async * Clean up data service to remove duplicate code Fix * Fix imports * Get rid of `useHooks` in components [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix' * Address feedback * Remove re-exported types
Summary
This PR refactors the
src/plugins/controls/public/services
folder with the goal of aligning with the new code standards that the Presentation team is working on. It has absolutely no user-facing changes.Checklist
N/A
For maintainers