Skip to content

Refactor string-based APIs and eliminate unnecessary magic strings #8

Description

@imsaba16

Review the Valix codebase for APIs and internal implementations that rely on hard-coded string values where stronger type-safe alternatives would be more appropriate.

Areas to investigate:

  • Validation property/path handling
  • Error codes/types
  • Configuration values
  • Generated validator metadata
  • Public APIs exposed as strings
  • Any stringly-typed APIs that could use enums, sealed types, value classes, or typed models

The goal is not to eliminate strings entirely, but to identify places where strings are being used unnecessarily and improve the API's type safety and maintainability.

This was raised as external community feedback, so the issue should include an initial audit of the affected areas before deciding what should actually be changed.

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions