# FR: Populate default value to new node property even if the node already exists

**URL:** <https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414>\
**Category:** Feature Requests\
**Tags:** editor\
**Created:** [4 December 2023 09:02 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414 "2023-12-04T09:02:00Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)\
**Post date:** [4 December 2023 09:02 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/1 "2023-12-04T09:02:01Z")

</div>

Hi Team,  
@marcus-j-davies, pointed out to me that when we update a node which has a new property added, the default value will not be used: When opening an existing node, the default value of the new property will not be used.

Which counter-intuitively, @knolleary why this choice?  
This requires developers to do:

```js
//oneditprepare
if (node.myNewProperty === undefined) {
    $("node-input-myNewProperty").val("defaultValue");
}

```

The value being `undefined` and `undefined` not being exportable why not consider that the property is missing and therefore use the default value?

---

<div class="post-metadata">

**Author:** ![ralphwetzel](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ralphwetzel/32/53713_2.png) [@ralphwetzel](https://discourse.nodered.org/u/ralphwetzel)\
**Post date:** [4 December 2023 09:59 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/2 "2023-12-04T09:59:37Z")

</div>

> [@GogoVega](#):
>
> why not consider that the property is missing and therefore use the default value?

Technically this is a change of the interface contract. Developers may do that and regularly do. Yet they have to ensure that prior versions are "upgraded" accordingly. The non-existence of a property gives a clear signal that there's action necessary; and it might be more to setup than just give a default value to a non-existing property. If you silently fill the gaps, we would need a different mechanism to get that signal.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [4 December 2023 10:04 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/3 "2023-12-04T10:04:26Z")

</div>

This is one of those "we didn't think of it at the time" items that was around for long enough that when it was spotted, we couldn't quite decide if it was 'safe' to automatically apply the defaults and decided to err on the side of caution.

We _always_ get complaints when a user opens an edit dialog, makes no changes, clicks 'okay' and then the node is marked as having changed. That is what would happen in this scenario. We don't like causing unexpected behaviours.

There is also the consideration that some nodes might rely on this behaviour to tell if it was handling an 'old' node or not - so it could apply additional logic to help upgrade the node.

The runtime side of a node will always have to deal with a property being undefined - there's no guarantee a user will have opened the editor and deployed any changes since the node was upgraded.

---

<div class="post-metadata">

**Author:** ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)\
**Post date:** [4 December 2023 10:21 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/4 "2023-12-04T10:21:25Z")

</div>

Just my 2c

Whilst it’s…. Frustrating, is that the right word? Having to fill in a default 🤪

I usually categorise this as a breaking change to my nodes, and sacrifice the "polyfill" approach by asking users to provide the value for the new property, if they already have the node deployed

---

<div class="post-metadata">

**Author:** ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)\
**Post date:** [4 December 2023 10:22 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/5 "2023-12-04T10:22:40Z")

</div>

> [@ralphwetzel](#):
>
> we would need a different mechanism to get that signal

validateNodeProperty allows you to signal that something is wrong.

> [@knolleary](#):
>
> The runtime side of a node will always have to deal with a property being undefined

For the runtime part, I completely agree with its behavior.

For the editor part, whether the developer defines the default value himself or whether it is the node doesn't change much.

> [@knolleary](#):
>
> We _always_ get complaints when a user opens an edit dialog, makes no changes, clicks 'okay' and then the node is marked as having changed.

This is why I attach big importance to validateNode (input validation) because it shows that a node has a fault and that the user must act. Of course until the user takes action, the node must continue to run normally.

If the user sees that his node has an error he will open the node then check each input then close the node and the error will have disappeared. If no message in the validation (red triangle) indicates that the property could be removed or something else, the user will be unhappy... because he was not warned

The current problem is that each node hangs out old properties because the user does not know that he must redeploy his node.

> [@knolleary](#):
>
> so it could apply additional logic to help upgrade the node

That's why I believe that the default value can help, of course the developer must also check the migration

I was a little long but I hope you understood my idea 😅

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [4 December 2023 10:35 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/6 "2023-12-04T10:35:33Z")

</div>

> [@GogoVega](#):
>
> If the user sees that his node has an error he will open the node then check each input then close the node and the error will have disappeared.

And that _always_ causes complaints because the user doesn't know what the error was or why it went away.

Nodes should _not_ require the user to open the edit dialog just to make an error go away. The node should be able to handle it.

Yes this means a bit of extra code for the node developer, but it keep the Node-RED experience much more user friendly.

---

<div class="post-metadata">

**Author:** ![ralphwetzel](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ralphwetzel/32/53713_2.png) [@ralphwetzel](https://discourse.nodered.org/u/ralphwetzel)\
**Post date:** [4 December 2023 10:44 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/7 "2023-12-04T10:44:01Z")

</div>

> [@GogoVega](#):
>
> > [@ralphwetzel](#):
> >
> > we would need a different mechanism to get that signal
> 
> validateNodeProperty allows you to signal that something is wrong.

Sure. Yet there's nothing 'wrong' in such a case. It's rather "watch out, there's an earlier version of our nodes config incoming"...

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [4 December 2023 10:45 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/8 "2023-12-04T10:45:33Z")

</div>

to my mind there is (slight) frustration either way. As-is the user has to go in and set a default. If fixed to auto supply the default then as Nick says the user opens and close the node and gets a changed flag even though nothing appeared to change (though of course there is now a new field they may not have noticed before).

Personally I think a) it means the node developer doesn't have to add his own "new field" handling code (1-3 lines just to set default). and b) the user annoyance is minimal. If a node really needs to do special handling the field can still be set to default value:undefined on the html side.

Of course as this is a small change in behaviour it would be a v4 item.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [4 December 2023 10:48 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/9 "2023-12-04T10:48:43Z")

</div>

If there is frustration either way, I err on the side of the end-user. We shouldn't be forcing them to take actions that are not strictly necessary.

---

<div class="post-metadata">

**Author:** ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)\
**Post date:** [4 December 2023 10:52 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/10 "2023-12-04T10:52:32Z")

</div>

> [@knolleary](#):
>
> And that _always_ causes complaints because the user doesn't know what the error was or why it went away.

That's what the red triangle is for

> [@knolleary](#):
>
> Nodes should _not_ require the user to open the edit dialog just to make an error go away.

It's tricky, if I take the example of an addition of functionality, it's not an error. As a deprecated property, as long as we stay on a non-major version, it should not be an error but after updating to the major version it becomes an error (note that the migration must still exist)

> [@dceejay](#):
>
> even though nothing appeared to change

It depends on the change, in fact

> [@knolleary](#):
>
> If there is frustration either way, I err on the side of the end-user. We shouldn't be forcing them to take actions that are not strictly necessary.

Yes, that's my recommendation, mark the node in error only if the change is breaking and not progressive like a property addition

---

<div class="post-metadata">

**Author:** ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)\
**Post date:** [4 December 2023 11:08 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/11 "2023-12-04T11:08:27Z")

</div>

If I return to the subject of this discussion:  
Let's imagine a new property is added, it is not a breaking change so the node **is not** in error, as long as the user does not modify his node nothing happens but if he opens it, the new field appears. Using the default value or using the value defined in `oneditprepare` doesn't change anything. Will the user notice the new field or not, that...

However, if the change is other, it is up to the developer to correctly migrate the value and I agree with you on this point.

I expressed myself badly, but I insist that my request **only concerns the case of a new node property** , this case where the user does not have to act obligatorily.

> [@knolleary](#):
>
> We _always_ get complaints when a user opens an edit dialog, makes no changes, clicks 'okay' and then the node is marked as having changed

If I take your answer, if it's a new property and therefore a new field, the user should notice the change and understand the reason of the modified node.

**But I also insist that for ALL other cases, it is up to the developer to manage and inform its users**

---

<div class="post-metadata">

**Author:** ![kevinGodell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kevingodell/32/27040_2.png) [@kevinGodell](https://discourse.nodered.org/u/kevinGodell)\
**Post date:** [4 December 2023 14:50 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/12 "2023-12-04T14:50:34Z")

</div>

Does the validation behavior change based on the “ **required** ” value?

In the past when I was adding features and extra settings, I had tried to make some migration code to alleviate some burden from the end user. I can’t remember exactly, but it may have been in response to somebody sharing a flow that was based on an older version of the node and had missing properties. It got complicated and on the next update of the node I removed the migration code. I realize now that maybe I could have just marked the field as not being **required** and just did my normal checking on the back end.

---

<div class="post-metadata">

**Author:** ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)\
**Post date:** [4 December 2023 14:57 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/13 "2023-12-04T14:57:48Z")

</div>

Require only checks if the value is not empty:

 ![Capture d’écran 2023-12-04 à 15.56.50](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/6/f/6fd7391f141f58c102868ceb13b79c97cd743eb1.png)

I think that using default value can help to avoid migrating code for added properties. The migration should be only used for more complex cases

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [2 February 2024 14:58 UTC](https://discourse.nodered.org/t/fr-populate-default-value-to-new-node-property-even-if-the-node-already-exists/83414/14 "2024-02-02T14:58:43Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
