[Controls Anywhere] Convert ControlGroupRenderer#236350
Conversation
2734aa0 to
c8d45ae
Compare
There was a problem hiding this comment.
I deleted the React control example, since it is no longer relevant now that the control group is not an embeddable.
| (current) => current.id !== action.id | ||
| ); | ||
| if (isCompatible) { | ||
| if (isCompatible && (disabledActions ?? []).indexOf(action.id) === -1) { |
There was a problem hiding this comment.
This ensures that the disabled actions are filtered out even when the actions change via the compatibilityChangesSubject
| const expectedChildCount = | ||
| Object.values(layout.panels).filter((panel) => { | ||
| return panel.gridData.sectionId ? !isSectionCollapsed(panel.gridData.sectionId) : true; | ||
| return panel.grid.sectionId ? !isSectionCollapsed(panel.grid.sectionId) : true; |
There was a problem hiding this comment.
This is a fix for a bad merge conflict
There was a problem hiding this comment.
I don't love the duplication between use_children_api and Dashboard's API definition. Essentially, I found I was just creating a subset of the Dashboard API for this - which works well enough, but I'm worried about potential drift. I'm not sure if we should go through the hassle of making some sort of shareable children API, though? 🤔
There was a problem hiding this comment.
…urce-definitions/scripts/fix-location-collection.ts'
… src/core/server/integration_tests/ci_checks'
…github.com:heenawter/kibana into controlsAnywhere_control-group-renderer_2025-09-24
…github.com:heenawter/kibana into controlsAnywhere_control-group-renderer_2025-09-24
rmyz
left a comment
There was a problem hiding this comment.
infra&services changes LGTM
| /** | ||
| * TODO: I added this to avoid circular dependencies; however, we should probably clean up the typings | ||
| * expected here so that `controls-renderer` is less depenedent on Dashboard types. i.e. it shouldn't | ||
| * need all the layout information, just controls. | ||
| */ |
There was a problem hiding this comment.
I can address this in a follow-up. I don't want to blow up this PR even more by making changes to controls-renderer
| HasSerializedChildState<object> & | ||
| Partial<PublishesDisabledActionIds> & | ||
| Pick<DashboardApi, 'registerChildApi' | 'layout$'> & { | ||
| // Pick<DashboardApi, 'registerChildApi' | 'layout$'> & |
There was a problem hiding this comment.
I am keeping this comment as a reminder - it will be removed
| export interface HasCustomPrepend { | ||
| CustomPrependComponent: React.FC<{}>; | ||
| } |
There was a problem hiding this comment.
I know this is controls-schemas but I needed to move this type out of the controls plugin to avoid circular dependencies and this is the best quick place for it.
💔 Build Failed
Failed CI StepsHistory
|
ThomThomson
left a comment
There was a problem hiding this comment.
Changes look good! I enjoyed looking through the new control group renderer.
As discussed offline, I would have preferred a messier translation layer to avoid bloating the feature branch with changes in the solutions, but it seems like all the changes to solutions made here are pushing them in the right direction.
| # @kbn/control-group-renderer | ||
|
|
||
| This is a shared component that allows a group of controls to be rendered via props. | ||
| It is a wrapper for the `ControlsRenderer` component, and it is responsible for defining the `parentApi` that |
There was a problem hiding this comment.
Nice to see this in a package!
| "@testing-library/react" | ||
| ] | ||
| }, | ||
| "include": [ |
There was a problem hiding this comment.
Why do we have changes to this file?
There was a problem hiding this comment.
I think that is CI nonsense. I don't think the larger PR from the feature branch will include this - and if it does, I can attempt to clean it up at that point
| <EuiFlexGroup | ||
| component="ul" | ||
| className={'controlGroup'} | ||
| className="controlGroup" |
There was a problem hiding this comment.
This is a nice clean & simple file.
| import { BehaviorSubject, Subject, combineLatest, map } from 'rxjs'; | ||
|
|
||
| import { ControlsRenderer, type ControlsRendererParentApi } from '@kbn/controls-renderer'; | ||
| import type { StickyControlState } from '@kbn/controls-schemas'; |
There was a problem hiding this comment.
Nice to see this type imported from the schemas package!
| compressed?: boolean; | ||
| } | ||
|
|
||
| export const ControlGroupRenderer = ({ |
There was a problem hiding this comment.
This is a really interesting strategy / approach for a compatibility layer between a pure React component and Embeddable react components. I like the approach and the organization a lot.
Warning
This work is being merged into a feature branch, not main!
Because of this, we only need a review from @elastic/kibana-presentation for now.
Type failures are expected because the feature branch is currently in an incomplete state, where the controls that have not yet been converted (time slider, etc.) are dependent on things that no longer exist.
Closes #235866
Closes #236128
Summary
This PR modifies the
ControlGroupRendererso that it wraps theControlsRenderercomponent instead of the oldReactEmbeddableRenderer(sincecontrolGroupis no longer an embeddable). To do this, we must create a parent API that matches the expectations ofControlsRendererfrom the props that the consumer provides.As part of this, I also added the
ignoreValidationsattribute back as a data control setting (rather than a control group setting, like it used to be), since some solutions relied on validations being turned off. I also ensured that, for legacy dashboards whereignoreValidationswas turned on for the control group, I passed this setting to the individual panels.Important
The time slider has not been converted yet, which means that certain uses of the
ControlGroupRenderer(such as the one used in the maps application) could not be tested. However, this is a large enough PR that I don't want to delay merging this first big step. I will keep the attached issue open until I can confirm that the time slider works as expected.Checklist