fixed readonly property of code-editor

[anishagg17]

Summary

Fixes : #2960
fixed readonly property of code-editor

reference : https://github.com/securingsincity/react-ace/blob/master/docs/Ace.md

readOnly should be passed directly to the ace-editor instead of an option as suggested by the documentation

Checklist

• Check against all themes for compatibility in both light and dark modes
• Checked in mobile
• Checked in IE11 and Firefox
• Props have proper autodocs
• Added documentation examples
• Added or updated jest tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[kibanamachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[myasonik]

This doesn't seem to fix the problem described in the ticket

(Notice, there's still no [readonly](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly) property on the textarea)

react-ace isn't the most accessible thing so there isn't an API to do this, we have to mutate the dom after render to do this. (Kibana example, though I did mess up a little, the value of readonly should be readonly not true)

[anishagg17]

Fixed it, by updating ace to 8.0.0.
Please recheck @myasonik

[myasonik]

Great, I can see that readonly is now applied!

[myasonik]

jenkins test this

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_2967/

[thompsongl]

I think it's a combination of the react-ace version update and the removal of brace from its deps, but syntax validation no longer occurs (compare https://eui.elastic.co/#/forms/code-editor to https://eui.elastic.co/pr_2967/#/forms/code-editor)

It's possible swapping the brace import statements for ace-build imports will solve it, but that may constitute a breaking change for consumers. Was a readOnly feature the reason for the version update, or can we continue to use [email protected] and reinstate the brace imports?

[myasonik]

Without updating react-ace the workaround to get the readonly property is to do a post-render DOM update

[anishagg17]

@myasonik I am trying to restore highlighting

[anishagg17]

@thompsongl I have fixed syntax validation ,highlight

[anishagg17]

Was a readOnly feature the reason for the version update, or can we continue to use [email protected] and reinstate the brace imports?

we should go with newer version as it major part was Removing brace as a dependency for ace-builds, which builds it's own integrated styles,supports
https://github.com/securingsincity/react-ace/blob/master/CHANGELOG.md

[thompsongl]

We'll need to label this as a breaking change because of the brace to ace-build dependency change. Kibana (and other consumers) has brace import statements alongside usage of EuiCodeEditor.
@chandlerprall can you think of any other potential impacts here?

[chandlerprall]

brace vs. ace-build could have unintended side effects in:

• content security policy support ([DISCUSS] react-ace/brace + Content Security Policy #1710)
• how the theme and/mode is loaded (e.g. import them before the editor import in brace's AMD/UMD way, are they dynamically loaded with another fetch request, etc)

It's been too long since I've looked into the differences in the various ace packages, so I don't know what I may be mis-attributing to another package, and we'd need a full exploration of these changes to know.

Another option, given:

Without updating react-ace the workaround to get the readonly property is to do a post-render DOM update

is related to #2961 where we're already exploring dynamic attribution setting after mount

[myasonik]

Maybe we just do this as a post-render update and table the package update until we can do a full test that it doesn't break anything

[thompsongl]

Right, I think I'd prefer avoiding the package update if we're planning on supplementing attributes anyway.

[thompsongl]

Closing this in favor of post-render, dynamic attribute supplementation (see #2961)