docs: meteor sdk docs edits#1109
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
| | `entityId` | true | | The entity id which should be cloned | | ||
| | `context` | false | {} | Change the [request context](#request-context) | | ||
| | `context` | true | | Change the [request context](#request-context) | | ||
| | `behavior` | false | | Optional clone behavior passed as the third argument | |
There was a problem hiding this comment.
Description should include answers to the questions:
- What is a clone behavior
- What type is the parameter
There was a problem hiding this comment.
I have now added a separate description with an example, in the same style as context.
There was a problem hiding this comment.
Looks good :)
| fileAccept: "image/png", | ||
| selectors: ["fileName", "id", "url"], | ||
| callback: ({ fileName, id, url }) => {}, | ||
| callback: (mediaSelections) => {}, |
There was a problem hiding this comment.
tbf, I think it's a nice way to show the type of mediaSelections with just destructuring it like it was before with { fileName, id, url }
There was a problem hiding this comment.
I changed it to [{ fileName, id, url }] to indicate that it is an array while still maintaining the destructuring.
| - They work with **Shopware Cloud** and self-hosted instances | ||
| - They can be distributed through the Shopware Store | ||
| - The frontend and backend are fully decoupled from the Shopware codebase |
There was a problem hiding this comment.
It's missing your suggestion
[...] to say that they are the only option that works with Shopware SaaS.
There was a problem hiding this comment.
I changed the bullet point to also mention shopware Saas
@shopware-ag/meteor-admin-sdk
@shopware-ag/meteor-component-library
@shopware-ag/create-meteor-extension
@shopware-ag/meteor-icon-kit
@shopware-ag/meteor-prettier-config
@shopware-ag/stylelint-plugin-meteor
@shopware-ag/meteor-tokens
commit: |
| ```ts | ||
| const exampleCloneBehavior = { |
There was a problem hiding this comment.
Just an idea to emphasize the type of the parameter. The actual type is probably different:
| ```ts | |
| const exampleCloneBehavior = { | |
| ```ts | |
| interface CloneBehavior { | |
| overwrites: object; // object that follows the same structure as the entity to overwrite its properties | |
| cloneChildren: boolean; | |
| } | |
| const example: CloneBehavior = { |
Edit: but we can also postpone that idea for a second iteration where we'd add a type column in the parameters table for all APIs
There was a problem hiding this comment.
I like this idea but would also suggest to postpone it for the next iteration and do it in the same way for all APIs as you suggested.
It would also be nice to add those types to the SDK itself in the same step, not just to the docs. Currently the clone behavior is a parameter without a type (just any).
42f9d59
into
docs-changes-mar12
What?
Adresses suggested docs improvements in #1075.