See Steps to Reproduce for details.
There are two problems here:
1. Dynamic types (eg. concatenated strings) are not displayed properly (see availability_zone below):
2. White screen (WSOD) is presented upon clicking edit icon for inputs with types different than string, integer and boolean.
availability_zone input is defined the following way:
This issue relates to: .
Environment:
OS (CLI), HA cluster, cloud provider
------------------------------------
Steps to reproduce:
------------------
1. Import AWS-Basics-VM-Setup blueprint (available in Blueprints Catalog) into Composer
2. Open Inputs
3. Click on Edit icon near `availability_zone` input
Expected result:
---------------
1. Proper default value in `availability_zone` input field should be displayed
2. Modal show up with value of `availability_zone`
Actual result:
-------------
1. Input field value of `availability_zone` is: "[object Object]"
2. White screen with error in console:
```
VM257 react_devtools_backend.js:2273 TypeError: e.match is not a function
at c.ace.define.$detectNewLine (vendor.bundle.js:sourcemap:352)
at c.ace.define.insert (vendor.bundle.js:sourcemap:352)
at c.ace.define.setValue (vendor.bundle.js:sourcemap:352)
...
overrideMethod @ VM257 react_devtools_backend.js:2273
vendor.bundle.js:sourcemap:381 Uncaught TypeError: e.match is not a function
at c.ace.define.$detectNewLine (vendor.bundle.js:sourcemap:352)
at c.ace.define.insert (vendor.bundle.js:sourcemap:352)
at c.ace.define.setValue (vendor.bundle.js:sourcemap:352)
...
```
Yes, I think so. The edit functionality is not working in that specific case, so as long as we agree only on fixing the white-screen issue (+ maybe avoid showing “[object Object]“) and not digging more into changing handling of different types, I think we are on the safe side.
if you and has an agreement on how it should be handled let’s do it
We agreed with that he’ll take closer look and share his thoughts. As I’m today focused on presentation and the next week I’m off Mon-Wed, it’s not critical at that moment.
What if we take the “naive” approach here? this is after all an input of type string. the string representing the default value is multiline, but still a string.
how complicated would it be to display it as-is and let the user edit it - again, as a string.
We would not be parsing it to show the sub-objects or the function (e.g. concat) but rather regard it as a string. is that a complicated / long task?
Alternatively, if editing is the bigger challenge and the above is not an option with the 5.1 timeline, we can display the default value as a string, and disable the edit button for this one. this will be poor usability but will save us the WSOD.
Let’s discuss on our call.
Fix implemented for 2 out of 3 issues: misleading representation of non-string input value ("[object Object]") and white screen after clicking edit on such input. Waiting for review.
Full support for different types should be implemented within .