Skip to content
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

Merged

Conversation

Heenawter
Copy link
Contributor

@Heenawter Heenawter commented Aug 11, 2022

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

@Heenawter Heenawter added Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:medium Medium Level of Effort release_note:skip Skip the PR/issue when compiling release notes impact:medium Addressing this issue will have a medium level of impact on the quality/strength of our product. backport:skip This commit does not require backporting Project:Controls v8.5.0 labels Aug 11, 2022
@Heenawter Heenawter self-assigned this Aug 11, 2022
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch 2 times, most recently from e37dfc0 to ec90a48 Compare August 11, 2022 21:07
@Heenawter Heenawter marked this pull request as ready for review August 12, 2022 20:24
@Heenawter Heenawter requested a review from a team as a code owner August 12, 2022 20:24
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

@Heenawter Heenawter marked this pull request as draft August 12, 2022 20:29
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch 4 times, most recently from a01f43f to 5b64202 Compare August 15, 2022 19:01
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch 3 times, most recently from 94ebb0d to 4581e79 Compare August 22, 2022 20:47
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch from 4581e79 to b66b09c Compare August 23, 2022 20:03
[CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch from 935cc40 to 9c26a01 Compare August 23, 2022 20:21
@Heenawter Heenawter marked this pull request as ready for review August 23, 2022 21:24
Copy link
Contributor

@cqliu1 cqliu1 left a 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.

@@ -29,3 +27,5 @@ export type OptionsListReduxState = ReduxEmbeddableState<
ControlOutput,
OptionsListComponentState
>;

export * from '../../common/options_list/types';
Copy link
Contributor

@cqliu1 cqliu1 Aug 25, 2022

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

Copy link
Contributor Author

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?

Copy link
Contributor

@cqliu1 cqliu1 Aug 29, 2022

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

Copy link
Contributor

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.

Copy link
Contributor Author

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

src/plugins/controls/public/services/data/types.ts Outdated Show resolved Hide resolved
@@ -6,7 +6,7 @@
* Side Public License, v 1.
*/

import { OptionsListRequest, OptionsListResponse } from '../options_list/types';
import { OptionsListRequest, OptionsListResponse } from '../../../common/options_list/types';
Copy link
Contributor

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.

Copy link
Contributor Author

@Heenawter Heenawter Aug 25, 2022

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 😆

Copy link
Contributor

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.

@Heenawter Heenawter requested a review from cqliu1 August 26, 2022 20:37
Copy link
Contributor

@cqliu1 cqliu1 left a 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

@Heenawter Heenawter enabled auto-merge (squash) August 29, 2022 18:01
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch from 09eecd4 to e987d9c Compare August 29, 2022 18:14
@Heenawter Heenawter force-pushed the refactor-controls-services_2022-08-10 branch from e987d9c to 114d649 Compare August 29, 2022 18:36
@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #47 / discover/classic "after all" hook: afterTestSuite.trigger in "discover/classic"
  • [job] [logs] FTR Configs #47 / discover/classic discover doc table "after all" hook: afterTestSuite.trigger for "should refresh the table content when changing time window"
  • [job] [logs] FTR Configs #47 / discover/classic discover doc table legacy "after all" hook: afterTestSuite.trigger for "should make the document table scrollable"
  • [job] [logs] FTR Configs #47 / discover/classic discover doc table legacy add and remove columns "after all" hook: afterTestSuite.trigger for "should remove columns from the table"
  • [job] [logs] FTR Configs #47 / discover/classic discover doc table legacy add and remove columns "after each" hook for "should add more columns to the table"
  • [job] [logs] FTR Configs #47 / discover/classic discover doc table legacy add and remove columns should add more columns to the table

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
controls 195 183 -12

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
controls 441.9KB 441.8KB -125.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
controls 27.0KB 25.0KB -2.0KB
Unknown metric groups

async chunk count

id before after diff
controls 7 6 -1

ESLint disabled line counts

id before after diff
controls 2 1 -1

Total ESLint disabled count

id before after diff
controls 2 1 -1

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @Heenawter

@Heenawter Heenawter merged commit 68905bd into elastic:main Aug 29, 2022
Mpdreamz pushed a commit to Mpdreamz/kibana that referenced this pull request Sep 6, 2022
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization impact:medium Addressing this issue will have a medium level of impact on the quality/strength of our product. loe:medium Medium Level of Effort Project:Controls release_note:skip Skip the PR/issue when compiling release notes Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.5.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants