Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identifier clashes in DOM when multiple score containers contain renderings of the same MEI file #2

Open
musicog opened this issue Feb 28, 2019 · 1 comment

Comments

@musicog
Copy link
Contributor

musicog commented Feb 28, 2019

... and more generally, whenever different MEI files share identifier names.

Problem: The fragment URI's prefix up to the # is stripped in-application before rendering annotations. We should instead replace the prefix with the relevant score container's React key, and make a method for "getByOriginalID" for those containers.

@DILewis
Copy link
Contributor

DILewis commented Nov 17, 2020

To clarify different levels of issue:

  1. ID clashes: Lots of components turn IDs in source files (especially MEI and TEI) into DOM IDs. There is no guarantee that these will be unique, making the resulting app invalid HTML and it's functionality, potentially, unreliable.
  2. URI reuse: The same file, rendered twice may have the same IDs duplicated because of 1., but also, depending on how component keys are generated, may have clashing react component keys. We provide no clear mechanism to distinguish between elements from multiple renderings of the same file within the app. This may have an impact on preserving or recreating state.
    Where it is important to be able to refer to state specifically, we will need react keys to be reproducible (rather than random). It's probably worth noting that we've got relatively little currently for saving and loading state anyway.

To be clear, there is no problem keeping track of URIs referring to external materials or parts of them within MELD, this is largely (entirely?) an issue of the DOM and of the application state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants