The code currently has widespread string literals identifying resource type names (like "portal") as well as field identifiers like "description". This issue captures a refacotring request to implement a better pattern for these identifiers. For each resource type, if necessary to have hardcoded resource field identifiers, or resource type identifiers, centralize those identifers as constants in the resource relative package. Then scan the codebase for usage of string literals and replace with constant usage.
here is just one example of what is widely used across the codebase:
func (a *EventGatewayDataPlaneCertificateAdapter) MapUpdateFields(
_ context.Context,
_ *ExecutionContext,
fieldsToUpdate map[string]any,
update *kkComps.UpdateEventGatewayDataPlaneCertificateRequest,
_ map[string]string,
) error {
// Certificate is required for updates
if certificate, ok := fieldsToUpdate["certificate"].(string); ok {
update.Certificate = certificate
}
// Optional fields
if name, ok := fieldsToUpdate["name"].(string); ok {
update.Name = &name
}
if description, ok := fieldsToUpdate["description"]; ok {
if desc, ok := description.(string); ok {
update.Description = &desc
} else if description == nil {
// Handle nil description (clear it)
emptyStr := ""
update.Description = &emptyStr
}
}
return nil
}
The code currently has widespread string literals identifying resource type names (like
"portal") as well as field identifiers like"description". This issue captures a refacotring request to implement a better pattern for these identifiers. For each resource type, if necessary to have hardcoded resource field identifiers, or resource type identifiers, centralize those identifers as constants in the resource relative package. Then scan the codebase for usage of string literals and replace with constant usage.here is just one example of what is widely used across the codebase: