[Discussion] Should validateNode functions have access to Value?

Do you want to request a feature or report a bug?

Feature

What’s the current behavior?

Current behavior is that validateNode only accepts the node undergoing validation as an argument.

What’s the expected behavior?

I’m wondering how many other folks have found themselves wishing that they could access the value undergoing change. I have some complicated validation rules that depend on where a block sits in the document hierarchy, and this requires me to implement validations at the object: document level.

That’s ok, but it would be a large optimization if I could have a validateNode rule that operated against a object: block and was able to analyze the block’s parents. One nice way to achieve this might be to also pass in the Value object undergoing validation.

For example consider a validation where for some reason I only want to add a property to the data of certain blocks based on their position in the document and type.

// assume that there's some logic somewhere else that ensures this is only called on a document node
validateSomeBlocksHaveSpecialData(document) {
  let invalids = document.nodes.filter(b => isSpecialType(b));
  // lets say list items are special, but stuff inside of table cells are not, so it doesnt serve me to arbitrarily recurse
  document.nodes.filter(b => isList(b)).forEach(li=> {
    li.nodes.filter(c => isSpecialType(c)).forEach(child => {
       invalids.push(child);
    });
  });
  if (invalids.size) {
    // return change function
  }
}

This has to be run at the document level now because that’s the only way to get an idea of the document hierarchy.

But what if I also had the value on hand? Then I could have validateNode functions that operate on the block level and look like

// assume there is some logic somewhere that ensures this is only called on a block node and block 
// and value are basically passed down to this fn
validateSomeBlocksHaveSpecialData(block, value) {
  // block is special if its not in a table
  if(isSpecialType(b) && !value.document.getClosest(p => p.type !== 'table')) {
    // return change function
  }  
}

I can then have a block validation function that operates against the block as it’s modified, and I don’t have to iterate over the entire document everytime something is changed

Is that a reasonable feature? Or have I wandered into some sort of antipattern?

[ianstormtaylor]

I believe this is currently impossible because of the architecture using to cache the normalization. We’re only able to cache at the node level because we limit the normalization to only knowledge of the node, and not its parents.

[zhujinxuan]

@CameronAckermanSEL

about a rule that automatically numbered headers sibling headers can be found in by the children of the parent from the ancestors