-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat: support storing custom fields on orders when placing #4962
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
Conversation
Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
ticean
left a comment
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.
The suggested approach to adding this to the GraphQL is to extend the GraphQL schemas with the new fields. That looks good to me and I see the example shows adding strongly typed fields. π
Can we require a typed customData in simple schema, too and extend the fields with a plugin? Blackboxes aren't portable when make the data available outside the reaction process.
An example to illustrate why it's important, we've got work in progress that exports the Catalog collection to a Kafka topic so that it can be consumed by external processes. It was working great, then we hit a problem where bad values were written to the MongoDB collection and they blocked entire data pipeline. π₯
Strong schemas create a contract and the and structural validation in the reaction code before writing to the db helps guarantee the data conforms to the contract.
|
I am testing this right now. |
|
This works, can be merged. |
Plugin will need to extend the schema Signed-off-by: Eric Dobbertin <[email protected]>
Signed-off-by: Eric Dobbertin <[email protected]>
|
@ticean I believe my changes should address your concerns. I removed I also changed |
|
@Akarshit Note the field name change and that you now need to extend the simple schema, too. (See "Extending the Order Schema" in my draft docs.) |
Resolves #4944
Impact: minor
Type: feature
Issue
For reporting, integrations, or other reasons, you may sometimes want to store additional data when placing an order.
Solution
customDataobject as part oforderInputfrom clients.transformCustomOrderDatato add to, modify, or remove custom order data provided by clients.Custom data sent from clients is not supported out of the box because it isn't in the
OrderInputGraphQL type. If you want to use this feature, you must create a custom plugin to add that field and define types for it. See draft documentation below.Additional Changes
HTTP request headers are now added to context, on
context.requestHeaders. It is common to want to store some of these on orders that are placed.Breaking changes
None
Testing
Using the draft documentation below, try out this feature and verify that it works as expected.
Draft Documentation
Storing Custom Order Data
For reporting, integrations, or other reasons, you may want to store additional fields when placing an order. This might be data from the client placing the order, data you can or must generate on the server, or some combination of the two.
The core orders plugin supports attaching additional arbitrary fields to orders, but you must do a bit of work to enable it. The first step is to decide whether the data you need can safely come from clients or if it must be built on the server. An in-between approach is to send data from the client but validate and extend it on the server.
Enabling Clients to Send Additional Order Data
The only step necessary to allow clients to send additional order fields is to define the expected schema for it in GraphQL, which you do by extending the
OrderInputGraphQL input type in a custom plugin to add acustomFieldsfield:Now in your storefront code, you can add the now-required extra fields:
Transforming or Adding Custom Order Fields on the Server
Whether or not you've allowed clients to send additional order data, you can also provide a function that returns custom order fields on the server. Do this using the
functionsByTypeoption inregisterPackage:As you can see in the example, the function receives an object argument with
context,customFields, andorderproperties.orderis the full order that is about to be created.customFieldsis the current custom fields object that would be saved asorder.customFields. This may be from the client placing the order, if you've allowed clients to send it, or it may be fromtransformCustomOrderFieldsfunctions registered by other plugins. It will be an empty object if no othertransformCustomOrderFieldsfunctions have run and the client did not pass any custom fields.The object you return will replace
order.customFields, so if you want to keep the properties already incustomFields, be sure to add them to the object you return, or simplyreturn customFieldsif you have no changes to make. You may also further validate the object and either remove properties from it or throw an error.transformCustomOrderFieldsfunctions may beasyncif necessary.Extending the Order Schema
If you are adding custom fields either from clients or from server functions, you must also extend the SimpleSchema for
Orderso that it validates for storage. This is similar to the "Enabling Clients to Send Additional Order Data" task, but you must extend the SimpleSchema rather than the GraphQL schema, and it's required even if all data is being generated on the server. In your custom plugin:Exposing Custom Fields Through GraphQL
If you are collecting extra order fields only for reporting or integration purposes, it may not be necessary to have them available through GraphQL queries. But if you do need some fields added to orders retrieved by GraphQL, it is easy to do this by extending the schema and adding resolvers in your custom plugin:
And then query for it: