Add a schema to fully specify the configuration options for the JSON files

[JlUgia]

One alternative to configure payment providers for this plugin is to create a configuration file in JSON format, and reference it in the instantiation of the payment client or the widgets directly.

This configuration is not fully specified for all providers.:

• Apple Pay – currently using W3C payment request specification
• Google Pay – based on the existing JSON spec in the SDK

Create a fully specified JSON schema for the parameters, types and values allowed for each provider. The current plan is to use JSON Schema, currently published as a draft IETF tool, and open to other suggestions.

[remonh87]

I think this is a very good suggestion to give devs more insights because currently the config parameters are not clear to me for all cases.

However why not directly go for a config object in Dart that helps developers and use build in jsonserialization ? Advantage of this is that we have type safety and analyzer can help us. Also JSON Schema can be very complex to read when you have a lot of parameters .

[vincevargadev]

At the project I am working on, we currently use our own "pay" plugin (it's a heavily edited fork of the flutter_pay plugin). That plugin has a set of Dart classes that help developers build the correct payloads that are necessary for the pay plugin to work.

We found that building the JSON (Map<String, dynamic>) correctly is quite difficult as the payloads are quite big. Having the more idiomatic Dart classes helps us spot mistakes at "analyze" or compile time as it enables static type checking.

What we can do is take our "well-defined classes" and provide that as an optional additional dependency. It could maybe even be in a separate little package (for example pay_data, or something like that), as for defining the data classes we used freezed+json_serializable, and maybe it would be better to leave those "big" dependencies out of the main pay package.

Integrating it into this plugin will take some time as in our plugin, we tried to match the original data structures very closely. Their format are documented here: Google's Android JSON request objects, JSON response objects, and Apple Pay's PKPaymentRequest, PKPayment.

The simple JSON based resource is great if the backend sets all the payment options, or if a developer likes the "simpler" approach, but the Dart classes really improve the developer experience (better documentation and compile time errors).

What was the thought process that made you land these two dependencies?

json_serializable is a "standard" way of converting from plain-old-Dart-objects to JSON (mainly Map<String, dynamic>) in the Dart eco-system.

We found that freezed is also helpful for its unions and pattern-matching capabilities. This was useful for example in cases where a parameter can be of multiple different types, for example Google Pay's request object's payment method parameter than can be either "card parameter" or "paypal parameter

The whole build process requires a couple of more dependencies: freezed_annotation, freezed, json_annotation, json_serializable, and build_runner, but "conceptually", it can be considered as two dependencies: json_serializable and freezed.