Implement Standardized Content Node Specifications

[Abhishek-Punhani]

Problem

Currently, content node validation is scattered across components, leading to:

• Duplicated validation logic
• Inconsistent validation rules
• Difficulty maintaining validation requirements

Motivation

We need a centralized, reusable specification system for content nodes to:

• Ensure consistency across the application
• Reduce code duplication
• Make validation maintenance easier
• Support component-specific extensions

Proposed Solution

1. Create a base content node specification in packages/kolibri/utils/specs/:

   • Define required/optional fields
   • Implement type validation
   • Support extensibility

2. Migrate existing validation:

   • Move component-specific validation to central specs
   • Update components to use the new spec system
   • Support extensions for special cases (e.g., LibraryAndChannelBrowserMainContent)

Implementation Details

• Location: packages/kolibri/utils/specs/contentNodeSpec.js
• Based on the existing objectSpecs.js pattern
• Will support:
  • Required/optional fields
  • Type validation
  • Default values
  • Extension mechanism
  • Nested object validation

/cc @rtibbles @nucleogenesis

[nucleogenesis]

Thank you for this excellent overview of the issue @Abhishek-Punhani

I have some thoughts and I think we'll want to clarify the requirements a bit more before someone takes this on.

---

For discussion, some questions that come to mind:

• How do we organize the various types of content node specs? For example, I imagine we could have a QuizContentNode (where we can expect it to have assessmentmetadata) - so I wonder if that should be defined in the kolibri/utils/specs or more locally to where it is used.

• What kind of API should we provide to make custom versions? I'm thinking we'll mostly want to customize which properties are required (ie, a QuizContentNode would require assessmentmetadata stuff on it but a "default" content node wouldn't).

[rtibbles]

Perhaps the simplest thing, rather than having lots of customization is just to have the spec always track the return value of the API endpoint, and we just keep the two in sync? So essentially what it is asserting is "I need an object that the API provides".

[Abhishek-Punhani]

Thank you for this excellent overview of the issue @Abhishek-Punhani

I have some thoughts and I think we'll want to clarify the requirements a bit more before someone takes this on.

For discussion, some questions that come to mind:

• How do we organize the various types of content node specs? For example, I imagine we could have a QuizContentNode (where we can expect it to have assessmentmetadata) - so I wonder if that should be defined in the kolibri/utils/specs or more locally to where it is used.
• What kind of API should we provide to make custom versions? I'm thinking we'll mostly want to customize which properties are required (ie, a QuizContentNode would require assessmentmetadata stuff on it but a "default" content node wouldn't).

@nucleogenesis , I think we can extend baseContentNodeSpec contentNode for specific needs by defining a function which will just expand the spec array to incorporate the requested object, like we can define QuizContentNode and export these extended contentNodeSpecs from these files, and use them in the needed files?