# TypedInput string validation

**URL:** <https://discourse.nodered.org/t/typedinput-string-validation/47661>\
**Category:** Core Development\
**Created:** [25 June 2021 13:22 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661 "2021-06-25T13:22:52Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![H3llsing](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/h3llsing/32/40624_2.png) [@H3llsing](https://discourse.nodered.org/u/H3llsing)\
**Post date:** [25 June 2021 13:22 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661/1 "2021-06-25T13:22:52Z")

</div>

Hey devs,

i got some problems with the string validation in the TypedInput widget.  
The validation is not working for my TypedInput of type string.  
it should work like described here

> [@Show validation results](https://discourse.nodered.org/t/show-validation-results/36358):
>
> Hi folks, Suppose a user has entered invalid input in a TypedInput field, are there any ways to visualize what he did wrong? For example when I enter an incorrect email address in the json editor: [image] Then I would like to make the error visible (instead of hiding the TypedInput and accepting the incorrect value). For example similar to standard html input validation (but without submitting a form): [image] But I have a number of questions: Does perhaps anything already exists in Nod…

my example:

```auto
...
defaults: {
  atContext: { value: '', required: true },
  atContextType: { value: 'str' },
...
// and somewhere in the onPrepareEdit:
$("#node-input-atContext").typedInput({ types: ['str'], default: 'str' })

```

did i miss a flag for non empty strings?  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/1/5/156f96131123c6441363c87a836d5fa48686fdc2.png)

The same procedure with JSON typedInput works.

**EDIT**  
and the correct HTML class is beeing generated, but somehow its not shown.

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/5/3/5359a9ae77ed411f6714a08f73f23e8cd0bb880e.png)

**EDIT2**  
 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/5/5/555b66f9696d40d49528ca7ec46c5396e34dd16d.png)  
with an own definition type and validation its working

```auto
const strType = {
                value: "string",
                label: "String",
                icon: "red/images/typedInput/az.svg",
                validate: /^(?!\\s*$).+/
            }

$("#node-input-atContext").typedInput({ types: [strType], default: 'string'})

```

is it a bug or am i missing something ?

---

<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:** [25 June 2021 14:04 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661/2 "2021-06-25T14:04:51Z")

</div>

It is more a limitation of the validation system, rather than a bug. (Although that's a matter of perspective and interpretation and just be splitting hairs...)

When validating values, the editor doesn't know 100% how that property is represented in the UI. It looks for a `<input>` with the expected id (based on the property name). If it finds one, then it sets the css class on that input.

In the case of a TypedInput, the `<input>` with that id is actually an internal hidden input. But the editor doesn't know that field is being represented by a TypedInput.

As a 'feature enhancement' (rather than bug fix), it wouldn't be unreasonable to add TypedInput awareness to that editor code, so that in this scenario to applies the class to the right element.

---

<div class="post-metadata">

**Author:** ![H3llsing](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/h3llsing/32/40624_2.png) [@H3llsing](https://discourse.nodered.org/u/H3llsing)\
**Post date:** [25 June 2021 14:09 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661/3 "2021-06-25T14:09:50Z")

</div>

thx for the explanation.  
Why is it working then with the JSON type ? Isn't here everything similar ?

---

<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:** [25 June 2021 14:11 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661/4 "2021-06-25T14:11:23Z")

</div>

The TypedInput has its own built-in type validation for some types.

When it comes to a String type however, a blank string is a valid string. The TypedInput doesn't know what extra requirements you have set on the node property.

---

<div class="post-metadata">

**Author:** ![H3llsing](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/h3llsing/32/40624_2.png) [@H3llsing](https://discourse.nodered.org/u/H3llsing)\
**Post date:** [25 June 2021 14:16 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661/5 "2021-06-25T14:16:43Z")

</div>

I see.  
Would it then make sense to enhanced the default options in custom nodes for an attribute like 'emptyValueAllowed' or one with a better name...

`atContext: { value: '', required: true, emptyValueAllowed: false },`

which the typedinput could interpret, if the built-in types have been adjusted ?

Because i think an empty value can be a valid case for every type here.  
For json type:  
if an empty value is allowed -\>  
i would generate an empty object which can be parsed. This would reduce the need of manual input.

if an empty value is **not** allowed -\>  
i would forbid an empty input and an empty json object '{}'

---

<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:** [24 August 2021 14:17 UTC](https://discourse.nodered.org/t/typedinput-string-validation/47661/6 "2021-08-24T14:17:03Z")

</div>

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