Skip to content

Establish a consistent cross-resource reference model in spx-gui #2941

@nighca

Description

@nighca

Background

We currently have multiple cases where one resource needs to reference another resource, but these relationships are not modeled in a consistent way.

Examples discussed in recent PR reviews:

  • animation references sound
  • monitor may reference sprite
  • sprite animation bindings reference animation
  • project zorder references sprite

Some existing cases already use a relatively stable pattern:

  • store the referenced resource by internal id in the model
  • convert to exported name only when exporting

However, other cases are handled differently, and the differences are starting to affect model organization itself.

For example:

  • sounds are currently kept at the project level partly because animations need to reference sounds across sprites, and removeSound needs to clean up those references
  • some other reference cases need extra rename / synchronization handling because the reference is not modeled in the same way

What this issue is about

Introduce a more consistent and reliable model for cross-resource references in spx-gui, so we do not need to keep making case-by-case compromises in model structure or lifecycle handling.

Why this matters

Without a unified approach, different features solve similar problems in different ways, which makes the codebase harder to evolve and increases the risk of bugs around:

  • rename
  • remove / cleanup
  • export / import
  • ownership and placement of models
  • future new resource-reference relationships

Possible direction

A possible baseline is to standardize on a pattern like:

  • keep stable internal references by resource id in the model
  • resolve or convert to exported names only at export boundaries
  • make rename independent from reference updates whenever possible
  • make remove / cleanup logic follow a predictable reference-management mechanism

The exact solution does not have to be limited to this pattern, but the goal should be to avoid ad hoc handling per feature.

Context

This issue is motivated by the design tradeoffs discussed in:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions