Skip to content

Conversation

@hashicc
Copy link
Collaborator

@hashicc hashicc commented Dec 2, 2025

Description

Migrates the component from hashicorp/ember-asciinema-player into admin ui. We use it one place within this app. It's easier to maintain within this app and also allows us to make changes as needed.

To see how the existing files from the repo were migrated it's best to go commit-by-commit on this PR.

How to Test

Go to the session recordings page and ensure that our sample cast is still playable.

Checklist

  • I have added before and after screenshots for UI changes
  • I have added JSON response output for API changes
  • I have added steps to reproduce and test for bug fixes in the description
  • I have commented on my code, particularly in hard-to-understand areas
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • I have added a11y-tests label to run a11y audit tests if needed

PCI review checklist

  • I have documented a clear reason for, and description of, the change I am making.
  • If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
  • If applicable, I've documented the impact of any changes to security controls.
    Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

Migrated from repo:
https://github.com/hashicorp/ember-asciinema-player

At commit:
09db104dd1db96348351a1cf50315cd00c3189dd
Rename class name to match the class naming conventions for generated
components
The player property doesn't need the @Tracked because its not being used
by ember to render. It is not rendered itself and changes to the
property do not impact what ember renders. The player property only
needs to track the previous player reference during teardown
@vercel
Copy link

vercel bot commented Dec 2, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
boundary-ui Ready Ready Preview Comment Dec 2, 2025 9:24pm
boundary-ui-desktop Ready Ready Preview Comment Dec 2, 2025 9:24pm

Comment on lines 9 to 10
{{did-insert this.initializePlayer}}
{{will-destroy this.destroyPlayer}}
Copy link
Collaborator Author

@hashicc hashicc Dec 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ember template lint warns against using these

*/
@action
destroyPlayer() {
later(() => this.dispose(), 250);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ember eslint warns against using runloop functions

assert.expect(1);

const asciicast = await fetch('/example.cast');
const asciicast = await fetch('/session.cast');
Copy link
Collaborator Author

@hashicc hashicc Dec 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our app we have the same cast file as this test was using in the repo, it's just under a different filename

}}

<div ...attributes {{this.initializePlayer}}></div>
<div ...attributes {{this.initializePlayer data=@data}}></div>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seemed better to bring in the @data through the element modifier args than reference this.args in the modifier logic although in both cases this.args.* usage should be tracked, this way is a bit more explicit as a dependency input to the modifier function

* @type {?AsciinemaPlayer}
*/
@tracked player = null;
player = null;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I set up a modified test where the data arg was set, and then 4 seconds later set with a new cast input. This change was required otherwise ember detected that this.player is being read and set in the same autotracking routing which it errors could cause infinite render loops. This is because the modifier dispose function sets a this.player = null and then a new this.player is being set.

In reality though this can all be avoided because player doesn't need to be @tracked. Render does not need to know when it changes to update something it is responsible for rendering. Everything within the div passed to AsciinemaPlayer is managed by that library

@hashicc hashicc self-assigned this Dec 2, 2025
"overrides": {
"nomnom>underscore": "^1.12.1",
"@hashicorp/design-system-components>ember-stargate": "^0.6.0",
"@hashicorp/ember-asciinema-player>asciinema-player": "3.4.0",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We previously had to lock in on this version because we relied on specific internal DOM structure and classes that changed after 3.4.0. With this PR we can remove this but still need to ensure that our dependency brought in within admin UI is 3.4.0. When we upgrade to a newer version we'll have make sure our additional css styles still apply

},
"dependencies": {
"@babel/runtime": "7.27.6",
"asciinema-player": "3.4.0",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hashicc hashicc marked this pull request as ready for review December 2, 2025 21:42
@hashicc hashicc requested a review from a team as a code owner December 2, 2025 21:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant