DataViews: Add apiVersion in view config

[ntsekouras]

What?

Part of: #67274

This PR explores adding an apiVersion to DataViews view config for preparation for making the API stable.
Right now the migration function is just an identity one, as we don't have the need for any migration.

What concerns me though is the migration cannot be an one time thing by checking VIEW_CONFIG_API_VERSION. The reason for this is the onChangeView callback where consumers can update the view config externally and they could be adding/updating some previous version props. Probably the approach for this config should be a callback (like isVersion1 or something) and not a check with a version number.

Testing Instructions

1. Everything should work as before and no visible changes.

[youknowriad]

This is a good start, I don't think there's a way around running the migration on each view object change but I don't see it as a huge problem with memoization in place.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ntsekouras]

This is a good start, I don't think there's a way around running the migration on each view object change but I don't see it as a huge problem with memoization in place.

You mean something more than what this PR is doing right now?

[youknowriad]

You mean something more than what this PR is doing right now?

No, what the PR is doing should be enough :)

[oandregal]

I was thinking about this approach and I wonder if we can actually change the view object once it's stable?

Look at this code, for example:

view.filters.forEach( filter => { /* do something */ } );

Now imagine that what we did was to rename filters to userFilters. Wouldn't the consumer code fail?

In the theme.json code base we have migrations. That approach works in that case because the consumer never deals with the theme.json structure, it just works with utilities (get_settings, get_styles) — so we migrate from different versions created by the theme to only work with one internally. For migrations to work here we'd need to do something along the same lines: ask consumers to use utilities to work with the view object, like const filters = getViewProperty( 'filters', view );.

[ntsekouras]

Now imagine that what we did was to rename filters to userFilters. Wouldn't the consumer code fail?

That's true and similar to the onChangeView handling. Probably the best handling for view config would be to not migrate anything (as it seems not practical) and have code to handle differently some different versions. That would also require a deprecation strategy - for example handle only two different versions at most each time. I'm wondering though how this is tied to core deprecation strategy, when DataViews will be stable and land in core.