Channel-aware custom fields

[chladog]

Is your feature request related to a problem? Please describe.
Make option for channel-specific custom fields. Currently change I make on channel1 applies to channel2 and other way around, however I need it to behave same as price on ProductVariant. (channel1 price and currency is independent of channel2 price and currency).
I need this independency only for some CFs, most of them are supposed to be in-sync between channels

Describe the solution you'd like
Add new configuration property to custom field channelAware?: boolean (defaults to false). If set to true then CF would be saved in separate table holding its values for each channel (analogous to current price implementation).
When switching channels in admin UI these values would get switched as well.

Describe alternatives you've considered
As I see in DB prices are saved in separate table with channel mapping. Actually I need this for additional price fields as well (used to define price for bulks). Therefore what I would basically need is "customPriceField". However I believe option for channel-specific custom fields would be handy for any other data type as well.

[incorvia]

I wonder if an alternative implementation might look like storing the properties in a jsonb column:

1. Letting the admin configure the properties in the admin interface and what channels the properties were allowed
2. Using those configured values to validate what values could be set within the jsonb column and
3. Possibly using these values as a filter when presenting them as well.

Or could use an EAV style DB structure.. like Saleor or Spree do..

[michaelbromley]

@incorvia I think the idea is worth exploring. Here are my initial thoughts:

Config-based custom fields (status quo)

• Pro: custom fields are part of the repo, under source control
• Pro: being in config also makes it easy for plugins to define their custom field requirements
• Con: changing custom fields requires DB migrations. This is good in that it makes you think about how the change will affect any existing data. Bad in the fact that if you don't plan carefully, you can lose existing data. It is also extra work.
• Con: Non-dev admins cannot set custom fields

Dynamic custom fields (JSON-based/EAV)

• Pro: Admins can create & modify
• Pro: No migrations needed
• Con: not under source control, so harder to track changes
• Con: Would need to expose new APIs for plugins to define required custom fields, and somehow make it so certain fields cannot be dynamically modified (otherwise the plugins will fail)

[chladog]

Dynamic custom fields (JSON-based/EAV)

• Pro: Admins can create & modify
• Pro: No migrations needed
• Con: not under source control, so harder to track changes
• Con: Would need to expose new APIs for plugins to define required custom fields, and somehow make it so certain fields cannot be dynamically modified (otherwise the plugins will fail)

In the old days when I was making Wordpress-based websites (prior WP Gutenberg editor) this plugin was my holy grail of dynamic custom fields, that made development a breeze: https://www.advancedcustomfields.com/
You could build up dynamic structures, apply dynamic conditions, loops etc.
Everything was saved in JSON, you could import and export whole definitions in JSON table from/to files (and sync them - which merged the definitions (overriding only with newer properties that were in both, leaving other fields untouched). This was solving the missing source control issues.
The CF management process was centralized (Custom Fields in main menu) and there for each group you would just set for which entity/condition it applies. (no need for special plugin api, nor special management per entity/plugin)
Plugin authors just made the definitions in CF manager and plugins just came along with their own JSON file definitions that you either import (if you needed alter it) or just leave it as JSON file which got loaded automatically, not even being saved in DB. (Local JSON was said to have even better performance: https://www.advancedcustomfields.com/resources/local-json/)
Unfortunatelly it's PHP, but worth looking in for inspiration ;-)

[incorvia]

Will add this for reference, not everyone loves EAV.

I think part of this depends on the philosophy of Vendure as an e-commerce platform. Is it attempting to be more 'dev centric' or admin centric. I'm actually ok with it being more dev centric if that's how we want to go, @michaelbromley would need to make the end call there. That said if we go with dev configuration we just want to make sure it's the right DB structure..

• EAV
• jsonb fields
• default fields in primary product table, custom fields in channel specific tables
• all fields in same table, some columns are just null and we use a list of fields to determine what to select

Are facets going to become channel aware as well?

[michaelbromley]

Thanks both for the input.

@incorvia I'd say Vendure leans more towards "dev centric". For example, I want to stay away from Wordpress-style "click to install" plugins, in favour of npm install and integrate.

Are facets going to become channel aware as well?

Probably. For context, I don't personally use Channels in my current project and therefore the initial implementation was minimal. As others have started using them, we've seen the addition of channel aware Orders and Customers. Facets seem likely to be requested & if a PR is made I am happy to add that functionality.

if we go with dev configuration we just want to make sure it's the right DB structure..

Yep, this is key. I'm not going to spend time on this until after v0.17.0 at least. Others are welcome to contribute design ideas in the mean time.

[michaelbromley]

@chladog I'm revisiting this feature request and I'm a little intimidated about the implications of implementing!

I'd first of all like to know how you've been handling this requirement with the current custom fields implementation?

Going with a new table per channel would mean adding 25 new tables. It also would significantly complicate certain things such as the automatic filter/sort handling of the ListQueryBuilder, plus all read/create/update operations on those entities with custom fields, to add a step to check for ChannelAware custom fields and join the appropriate data.

[chladog]

@michaelbromley Originally I wanted to use channels for multi-currency setup (I needed some channel specific CFs (additional prices inputs) and some system-wide cfs (variant parameters), but in the end it felt like too much of a management hassle to have multiple channels just for multi-currency and decided to have single channel with recalculating rates on UI & PaymentHandler side...
We were discussing this feature on Slack and I was asked to create a new ticket. I'm sure that for multi-channel setup this feature would be very useful though I can see the complexity that comes with it. Maybe keep it open as potential feature for after v1.0?

[michaelbromley]

@chladog Got it. We also do a similar thing in our project to handle multi currencies.

I'll keep this around for a potential future version and see how needed it is.

[chladog]

We started using channels for their real purpose that is having multiple frontends (now starting wholesale channel) and this issue became relevant for us again. Only CustomFields where we set additional prices (bulk pricing, discounted price) of the ProductVariant are relevant for channel-awareness. I wonder, would it be somehow feasible to implement to current config-based custom fields channel-awareness until some resolution on dynamic cfs is made?
Either as originally proposed channelAware flag to CF config or maybe introduce additional group channel-aware custom fields?

Alternatively extension of the Price interface where we could set additional values. Then these values could be get on ProductVariant object in Promotion calculate function.