conditional options

[xavitoro]

PR Type

What changes does this PR include (check all that apply)?
[ ] Bugfix
[x ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build process changes
[ ] Documentation changes
[ ] Other... please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x ] No

Any other relevant information

This change is to add conditions to select component options, now we have two ways:

Example 1:
{
"key":"[yourkey]",
"type":"select",
"titleMap": [
{ "value": [value], "name": "[name]", "conditionKey": "[conditionKey1]"},
{ "value": "K843", "name": "CODE_K843", "conditionKey": "[conditionKey1]"},
{ "value": "L843", "name": "CODE_L843", "conditionKey": "[conditionKey2]"}
],
"conditionMap": [
{
"key": "[conditionKey1]",
"condition":{
"functionBody": "[functionBody1]"
}
},
{
"key": "[conditionKey2]",
"condition":{
"functionBody": "[functionBody2]"
}
}
]
}

Example 2:

{
"key":"[yourkey]",
"type":"select",
"titleMap": [
{ "value": [value], "name": "[name]",
"condition":{
"functionBody": "[functionBody1]"
}},
{ "value": "K843", "name": "CODE_K843",
"condition":{
"functionBody": "[functionBody1]"
}},
{ "value": "L843", "name": "CODE_L843",
"condition":{
"functionBody": "[functionBody2]"
}
}
]
}

[johnedvard]

I am just wondering if it is equally correct to write if(item.conditionKey && layoutNode.options.conditionMap) skipping the !== undefined. I mean, if 0 and null are unacceptable values as well.

[johnedvard]

I am not familiar with what is best practice. If this is the style that goes through the rest of the code in this repo, then by all means, its better to keep it this way (using !== undefined).

[xavitoro]

You are right

[jscharett]

This seems like a large change incorporating more than just conditional options. Specifically, the package.json and build changes seem like they should go into a separate PR.