Upcoming input validation feature

One of our most requested features has been input validation: enabling devs to define and set rules that ensure editors and content teams provide the correct data.

We’re now in the final planning phases, and we’d love your feedback before we start building.

Here’s what we’re thinking for the first iteration of the feature:

Validation rules

  • Required values
  • Min/max length for text inputs
  • Min/max values for numbers
  • Date ranges
  • File size limits
  • Pattern matching
  • Array length limits and uniqueness

Key features

  • Inline error messages on inputs
  • Prevent saving files with validation errors
  • Conditional validation (hidden or disabled inputs won’t be validated)

You can read about all of our input options in the input reference documentation.


Examples

Here are some validation scenarios we’re planning to support at release:

Text length validation

Limiting the length of a text input to 10 characters:

title: 'Hi!'

_inputs:
  title:
    type: text
    options:
      max_length: 10

Limiting the length of a text input to between 5 and 10 characters:

title: 'Hello!'

_inputs:
  title:
    type: text
    options:
      min_length: 5
      max_length: 10

Number validation

Limiting the value of a number input to between -10 and 0:

metres_from_sea_level: -5

_inputs:
  metres_from_sea_level:
    type: number
    options:
      min: -10
      max: 0

Array validation

Ensuring an array contains between 2 and 5 items, with no duplicates:

featured_posts:
  - /posts/my-post.md
  - /posts/my-other-post.md

_inputs:
  featured_posts:
    type: array
    options:
      min_items: 2
      max_items: 5
      unique_on: '$' # JSON Path selector for each root item

Ensuring an array contains no duplicates based on a nested key:

related_posts:
  - post: /posts/my-post.md
    featured: true
  - post: /posts/my-other-post.md
    featured: false

_inputs:
  related_posts:
    type: array
    options:
      unique_on: '$.post' # JSON Path selector for post inside each item

Date and time validation

Limiting a Datetime to 2022:

previous_event: 2020-05-01T00:00:00Z

_inputs:
  previous_event:
    type: datetime
    options:
      start_from: 2022-01-01T00:00:00Z # inclusive
      end_before: 2023-01-01T00:00:00Z # exclusive

Ensure a date is in or after 2000:

this_millennium: 2020-05-01T00:00:00Z

_inputs:
  this_millennium:
    type: date
    options:
      start_from: 2000-01-01T00:00:00Z # inclusive

File size validation

Making sure new or existing files are under 1MB:

hero_image: /uploads/big-image.png

_inputs:
  hero_image:
    type: image
    options:
      max_file_size: 1000 # in kB

Pattern validation

Ensure that an email input contains an email address:

email_address: /uploads/big-image.png

_inputs:
  email_address:
    type: email
    options:
      pattern: '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}'
      pattern_message: 'Use the format ___@___.__'

Making sure an input has a http or https protocol:

full_url: 'https://cloudcannon.com/'

_inputs:
  full_url:
    type: url
    options:
      pattern: '^https?\:\/\/'

Future considerations

Although it won’t be part of our initial release, we’re also thinking about JSON Schema validation for complex rules, with error messages for invalid input values. Unlike the other validation methods we have listed above, JSON Schema validation would not be able to prevent actions (e.g., CloudCannon will disable the add button on an array once max_items is reached).

Complex object validation

Ensure an object has the on_background input set to ‘light’:

next_color:
  _type: flat_color
  value: '#ff0000'
  on_background: 'light'

_inputs:
  next_color:
    options:
      structures: _structures.colors_and_gradients
      json_schema:
        type: object
        properties:
          on_background:
            const: 'light'
      json_schema_message: 'Use a color/gradient for use on a light background.'

Complex array validation

Ensure only one array item has its featured input enabled, and all post keys are unique:

top_posts:
  - post: /posts/my-post.md
    featured: true
  - post: /posts/my-other-post.md
    featured: false
  - post: /posts/another-post.md
    featured: false
    
_inputs:
  top_posts:
    type: array
    options:
      unique_on: '$.post'
      json_schema_message: 'Only one post can be featured.'
      json_schema:
        type: array
        contains:
          type: object
          properties:
            featured:
              const: true
        minContains: 1
        maxContains: 1

We’d love to hear from you

  1. Do these examples cover your needs? What other scenarios would be helpful?
  2. How do you feel about the proposed syntax? Is it intuitive and easy to understand?
  3. Which validation rules would be most valuable for your projects?
  4. Any concerns about the proposed implementation?

Note: This is a draft proposal and details may change based on community feedback and technical considerations.

10 Likes

One use I foresee is that there would be sets of required inputs to ‘qualify’ a component to conditionally appear.

With the logic being that it will show the component if the inputs are validated?

  • As an example, it could be useful for staff collections with cascading levels of detail dependent on seniority etc.
  • Which would generate varied levels of schema detail.
  • Which would display varied levels of components on staff pages/collections.

Would the Array validation make this easy? ie ensure an array contains between 2 and 5 validated items, with no duplicates? Or would in-valid inputs never be saved-by being rejected? And am I slightly off track…

Cheers!!

4 Likes

Hey Timmy,

The upcoming input validation feature is being designed to prevent saving files that don’t meet the specified validation rules. If something isn’t quite right, the save interface will clearly highlight the issue and guide editors to where it can be fixed. For things like array length and uniqueness, you’ll be able to use the min/max items options and custom JSON schema validations.

For your idea about qualifying varied levels of schema detail, be sure to check out using structures on object inputs—they’re super handy for managing different levels of detail and making sure the right fields are present. There’s a good overview in the CloudCannon documentation on object inputs and structures if you want to dive deeper.

On your question about conditional component display: in the live preview, components will still render whether the inputs are valid or not. It’s up to the components themselves to handle invalid input—so they might show a placeholder, a warning, or some other indication if the required data isn’t present or valid. We’re also planning to pass validation errors to the live preview, which should make it possible for components to display inline error messages if needed.

Thanks again for your input! If I missed anything or you have any follow-up questions, just let me know.

1 Like

Thanks for sharing the proposal George, very much looking forward to this feature.

Personally I have a client who likes to save files with very little data in them. It seems they like to use Cloudcannon to plan upcoming content. I’ve since asked them to stop as for some reason it was overriding other files, but just having the ability to prevent files from being saved without required values would a massive help.

Something else that would be helpful is a way to prevent HTML or Markdown from being added to certain inputs. Perhaps this can be done using pattern matching?

Otherwise, the examples you’ve shared more than cover my needs. Likewise, the syntax looks good to me.

Somewhat related to this proposal but perhaps not entirely, would it be possible to prevent files from being deleted if they are being referenced elsewhere?

For example, if a collection is being used to populate the values of options, as described in the docs, and a file in that collection is current assigned as the value of a select input inside another file, then it would be helpful to show some sort of warning message to make clear that the file is being used to populate content in another file. I guess this isn’t exactly input validation, but possibly something else?

5 Likes

This feature is a great addition, looking forward to the release!

We have enough situations where we needed to configure the min/max range of adding new slider items in a hero component for example. Or where we needed to make sure that file inputs get a max. file size with file mime types.

For feedback, I might have some that might be useful for use cases that require a bit more customization:

  • More complex validation logic
    – Allowing combinations of conditions. For example: “If field A is filled, field B must be required.”
  • Field-level custom error messages
    – Allow custom error messages for all validation types, not just pattern.
  • Better support for localization / i18n
    – Will validation messages support multiple languages or dynamic rendering? If not, consider allowing error messages as a reference to a localization key.

I also have some questions regarding the feature:

  • How will validation interact with hidden/disabled fields? Conditional validation is mentioned, but how does it work when a field is dynamically shown/hidden? Will CloudCannon auto-detect visibility, or is an explicit flag required?
  • How would I know when an input field is being validated, to make sure that the fields behave as expected?

Thank you in advance and looking forward to the release once more!

5 Likes

This is awesome, validation is a much needed feature! Can’t wait for my next CC build.

4 Likes

This looks great!

Essential for almost every project

  • Min/max length for text inputs: (ideal for titles and meta descriptions—SEO)
  • Array length limits and uniqueness: (e.g., galleries, featured product lists, max cards/boxes)

Nice to have in specific cases

  • Pattern matching (e.g., digits-only on prices)

Looking forward to using it. It will be very useful. :+1:

2 Likes