Uses revision numbers, not a deep compare of content, to detect whether it's possible to save and launch a piece.
The current behaviour is arguably better for users when it works, because 'save and launch' is not available when there's nothing new to publish.
However, it has some disadvantages:
It's more error-prone. Are we definitely comparing every aspect of the content? If we miss a new field or accidentally remove an old one from the logic, it'll be incorrect.
It means that other tools – like Composer – need to know a lot about the shape of a video atom to figure out 'unpublished changes', and they also need to keep up to date with MAM, introducing more scope for inconsistencies and errors to creep in. At the moment, Composer does not use a deep compare, meaning that the tool incorrectly suggests that there are unpublished changes in content.
It's worth noting that other tools, like Composer, use a revision number, not a deep compare, to determine whether a piece can be republished.
Rather than re-implement deep compare in Composer, it's arguably better to go for a less potentially buggy and more consistent approach for now. This doesn't rule out reimplementing deep compare in future across both tools in some more robust way.
How to test
Running this branch locally or in CODE, create a video and publish it.
Edit fields. You should notice the disabled 'published' button change to 'save and launch' in every instance. Publishing should work as normal.
In CODE, embed in Composer by dragging the video URL an article. The element should show a message when the atom has unpublished changes, and should show nothing otherwise:
Has unpublished changes ('save and launch' available in MAM)
prout-bot
commented
1 year ago
NB: depends on #1130.
What does this change?
Uses revision numbers, not a deep compare of content, to detect whether it's possible to save and launch a piece.
The current behaviour is arguably better for users when it works, because 'save and launch' is not available when there's nothing new to publish.
However, it has some disadvantages:
It's worth noting that other tools, like Composer, use a revision number, not a deep compare, to determine whether a piece can be republished.
Rather than re-implement deep compare in Composer, it's arguably better to go for a less potentially buggy and more consistent approach for now. This doesn't rule out reimplementing deep compare in future across both tools in some more robust way.
How to test