<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=235970) </details> <!--IssueSummary end--> ## Summary <!-- Please briefly describe what part of the code base needs to be refactored. --> Currently we use a combination of several strategies to identify a line on a diff file. This has broken down in the past by being easily mixed up and by not supporting certain scenarios like symlinks where the same file name is shown twice. ## Improvements Have an easy and unique way to identify a specific: * diff file (file path, file mode) * line (and interval) In the contexts: * inline / parallel mode * specific version comparison * ... ## Risks <!-- Please list features that can break because of this refactoring and how you intend to solve that. --> Central mechanism to diff rendering. ## Involved components <!-- List files or directories that will be changed by the refactoring. --> * `app/assets/javascripts/diffs` ## Optional: Intended side effects <!-- If the refactoring involves changes apart from the main improvements (such as a better UI), list them here. It may be a good idea to create separate issues and link them here. --> ## Optional: Missing test coverage <!-- If you are aware of tests that need to be written or adjusted apart from unit tests for the changed components, please list them here. --> <!-- Please select the appropriate label from the following: ~"feature::addition" ~"feature::maintenance" ~"tooling::pipelines" ~"tooling::workflow" -->