This introduces a new string_compat / draftjs_exporter.engines.string_compat.DOMStringCompat engine, which is a copy of the existing string engine with two changes added for backwards compatibility:
Reverts _Remove HTML attributes alphabetical sorting of default string engine (#129)_.
Reverts _Disable single and double quotes escaping outside of attributes for string engine (#129)_.
Both of those changes were introduced in v4.0.0, I think they make complete sense for projects using the exporter since, but they do change the output. It’s important for the output to be as stable as possible in a lot of scenarios, so I made sure to document how to preserve the output back then.
Rethinking this a bit, I think it makes a lot of sense to actually have built-in support for this, so people for whom output stability is more important than speed have this kind of guarantee. It’s also nicer to maintain as a copy of the code in the same branch rather than backporting speedups to older versions indefinitely.
I had also considered adding those exact options to the string engine directly, but decided no to in the end – if there are more such compatibility changes needed in the future, I think it would be nicer for the two engines to be able to diverge as much as possible, rather than have the same code paths with different configuration.
[x] Stay on point and keep it small so it can be easily reviewed. For example, try to apply any general refactoring separately outside of the PR.
[x] Consider adding unit tests, especially for bug fixes. If you don't, tell us why.
[x] All new and existing tests pass, with 100% test coverage (make test-coverage)
[x] Linting passes (make lint)
[x] Consider updating documentation. If you don't, tell us why.
[x] List the environments / platforms in which you tested your changes. macOS Python 3.10.
This introduces a new
string_compat/draftjs_exporter.engines.string_compat.DOMStringCompatengine, which is a copy of the existingstringengine with two changes added for backwards compatibility:Both of those changes were introduced in v4.0.0, I think they make complete sense for projects using the exporter since, but they do change the output. It’s important for the output to be as stable as possible in a lot of scenarios, so I made sure to document how to preserve the output back then.
Rethinking this a bit, I think it makes a lot of sense to actually have built-in support for this, so people for whom output stability is more important than speed have this kind of guarantee. It’s also nicer to maintain as a copy of the code in the same branch rather than backporting speedups to older versions indefinitely.
I had also considered adding those exact options to the string engine directly, but decided no to in the end – if there are more such compatibility changes needed in the future, I think it would be nicer for the two engines to be able to diverge as much as possible, rather than have the same code paths with different configuration.
make test-coverage)make lint)