[Content Management] Maps onboard#153304
Conversation
ebde438 to
6de3442
Compare
10e5f14 to
3bffab5
Compare
|
Pinging @elastic/appex-sharedux (Team:SharedUX) |
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
|
@elasticmachine merge upstream |
|
Sorry for the ping to the reviewers. I need to put this back in draft as we are going to make a change to the API before merging this one. |
There was a problem hiding this comment.
Aside from mapAttributesSchema, this looks like a generic saved objects schema
There was a problem hiding this comment.
This has me a bit confused. As best I can tell its changing some object keys from snake case to camel case.
There was a problem hiding this comment.
It is a function that guarantees that we explicitly return the fields for our MapItem instead of doing { attributes: ...savedObject.attributes }
67eb74c to
abd68a4
Compare
We declare clear TS types for each CRUD (get, create, update, delete) and search methods inside a versioned folder ("v1"). Once that is done we can create the schema validation for the different object and expose a "v1" serviceDefinition.
A service definition is an object where every objects that comes "in" (e.g. data to be saved or a query to execute) can have a schema validation and up & down transform handler for BWC. The same applies for the result object that comes "out".
The MapsStorage class is where the CRUD + search methods are declared. This is where calls to the Saved Object client apis are made
MapSavedObjectAttributes is going to be versioned and might evolve across different versions of the map content. For that we will expose under the "v1" folder. It is then re-exposed by the "latest.ts" file which is exposed by the barrel file.
…kibana into content-management/maps-onboard
| uiStateJSON?: string; | ||
| }; | ||
|
|
||
| export interface MapItem { |
There was a problem hiding this comment.
this seems like saved object type that could be abstracted as it will be the same for all our saved objects ? SavedObject ?
There was a problem hiding this comment.
I think that the goal is to decouple from the SavedObject naming (exposing the persistence layer). There is indeed an opportunity to create a generic somewhere that SO content could extend but the idea in this PR is to decouple the specific content type from the storage layer (SO) and creating generic is out of scope.
Where this generic should live, I don't know.
I do think it is important to not want to abstract too early to save a few LOC (types anyway that will go away). If teams/owners of multiple SO types want to create a package for the generic they are free to do so 😊
|
|
||
| // Save data in DB | ||
| const soClient = await savedObjectClientFromRequest(ctx); | ||
| const partialSavedObject = await soClient.update<MapAttributes>( |
There was a problem hiding this comment.
Why does this work with partial saved objects? Is there something about the SO client that makes this necessary?
There was a problem hiding this comment.
That's what you get from soClient.update : https://github.com/elastic/kibana/blob/main/packages/core/saved-objects/core-saved-objects-api-server/src/apis/update.ts#L44
| uiStateJSON?: string; | ||
| }; | ||
|
|
||
| export interface MapItem { |
There was a problem hiding this comment.
This is really the SO data and meta data. The name item confused me a bit.
There was a problem hiding this comment.
MapItem,MapSavedObject, Map... It could be named as the team understand better.
With that said, adding the SavedObject suffix is what we want to get away from as we don't want to expose databases specifics (e.g. we would not call this MapPostgreSQL)
|
I put together a PR against this branch which simplifies types for any SO using content management. I've made a number of assumptions, hopefully I got more right than wrong - https://github.com/sebelga/kibana/pull/19/files The abstraction - https://github.com/sebelga/kibana/pull/19/files#diff-1fcd1885f36b55f3d124588ce363d99feffa17cdc3a2f53ff7e611a3f353305a |
@mattkime Those abstraction look good to me. They are out of scope for this PR, you probably want to create a package and expose them for other plugins to consume. And then open a PR to refactor the types here in map 👍 |
|
@nreese I reverted the change to return the full object back to only returning the "title" and "description". Can you have another look? Cheers! 👍 |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsESLint disabled in files
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @sebelga |
nreese
left a comment
There was a problem hiding this comment.
LGTM
code review, tested in chrome
thomasneirynck
left a comment
There was a problem hiding this comment.
hi @sebelga
this proposal looks really straightforward. Only some nits and small Qs thx!
| export const getExecutionContextService = () => coreStart.executionContext; | ||
| export const getTimeFilter = () => pluginsStart.data.query.timefilter.timefilter; | ||
| export const getToasts = () => coreStart.notifications.toasts; | ||
| export const getSavedObjectsClient = () => coreStart.savedObjects.client; |
|
Thanks for the review @nreese and @thomasneirynck 👍 ! |
|
Part of #157043 |
## Summary Changes to the `down` method type from #153304, missed passing the generic input type. Also fixes types on schema utility functions from `@kbn/content-management-utils`. I created #231191 and a child issues for CO teams to track and fix. _Pulling this out of a larger PR, #229534, to ease CO review._ ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
## Summary Changes to the `down` method type from elastic#153304, missed passing the generic input type. Also fixes types on schema utility functions from `@kbn/content-management-utils`. I created elastic#231191 and a child issues for CO teams to track and fix. _Pulling this out of a larger PR, elastic#229534, to ease CO review._ ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 7acaf61)
## Summary Changes to the `down` method type from elastic#153304, missed passing the generic input type. Also fixes types on schema utility functions from `@kbn/content-management-utils`. I created elastic#231191 and a child issues for CO teams to track and fix. _Pulling this out of a larger PR, elastic#229534, to ease CO review._ ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
This PR migrates the "map" Saved object type to content management.
Included in the PR
mapcontent type in the contentManagement registries (browser and server)v1CM services definition for BWC supportMapsStorageclass on the server to communicate with the saved object clientNot included in this PR
The main focus of the PR was to remove the use of the
savedObjectpublic client in the browser. I didn't change other dependency on the@kbn/saved-objects-pluginpackage like the<SavedObjectSaveModalOrigin />component.Notes for reviewer
I've re-written the history of commits to better show how the migration has been done. I would recommend to review "by commit" (read the description of the commit wherever I've added one).
Documentation
In #154453 we have the documentation on how to onboard content into CM.
Fixes #153256