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

Make sure that hasLoaded flag is only true when the loaded event has fired. Alternative implementation of commit 924dc00 (fix #5425) #5430

Merged
merged 2 commits into from
Jan 31, 2024

Conversation

dmarcos
Copy link
Member

@dmarcos dmarcos commented Jan 13, 2024

No description provided.

@dmarcos dmarcos changed the title Make sure that hasLoaded flag is only true when the loaded event has fired (alternative implementation of commit 924dc00 (fix #5425) Make sure that hasLoaded flag is only true when the loaded event has fired. Alternative implementation of commit 924dc00 (fix #5425) Jan 13, 2024
@dmarcos
Copy link
Member Author

dmarcos commented Jan 13, 2024

@mrxz this should cover all the issues of #5425

I introduced an isLoading flag different that hasLoaded (only set before 'loaded' fires) and also a loaded-private (don't love the name) event analog to loaded but "private" so A-Frame can handle internal stuff before the public event fires.

I tested on your glitches and added test to cover those scenarios. Can you also validate on your side? Thanks

@dmarcos
Copy link
Member Author

dmarcos commented Jan 13, 2024

Glitch with build for convenience:

https://glitch.com/edit/#!/lemon-magnificent-badge?path=index.html%3A1%3A0

@@ -278,7 +278,7 @@ Component.prototype = {

// Just cache the attribute if the entity has not loaded
// Components are not initialized until the entity has loaded
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps update this comment to something like "... until the entity starts loading"

@mrxz
Copy link
Contributor

mrxz commented Jan 17, 2024

Thanks, this does indeed seem to cover all the issues. Did some more testing and didn't find any other regressions, so seems good to go.

The naming of the loaded-private event could use some work, but it's tricky to come up with a suitable one.

@dmarcos
Copy link
Member Author

dmarcos commented Jan 17, 2024

@mrxz Thanks for testing it. Just one request. I copied your glitch test case from #5425 (comment) verbatim to the tests include in this PR. They are a tad complicated / convoluted and will be hard to understand and maintain. Do you think you can simplify them a bit? Thanks

@dmarcos
Copy link
Member Author

dmarcos commented Jan 25, 2024

@mrxz just ping in case you have some bandwidth to simplify your test cases so I can incorporate them to the unit tests. Thanks so much

@mrxz
Copy link
Contributor

mrxz commented Jan 26, 2024

@dmarcos Gave it a shot. The test cases included visual output, but as unit tests that's not relevant. However they do all rely on specific order of execution (things taking place during isLoading), so I'm afraid they still remain somewhat complex.

See my attempt at simplifying them: mrxz@2ff8fac

In summary:

  • The double update test now uses the (built-in) visible component, as the erroneous behaviour occurs with any component, so no need to create a test-specific one
  • Remove geometry from the mixin test and changed test name to align with surrounding tests
  • Simplified primitive and updated naming to better describe what the component does.

@dmarcos
Copy link
Member Author

dmarcos commented Jan 31, 2024

Thanks. I cherry picked your commit

@dmarcos dmarcos merged commit d9d1259 into aframevr:master Jan 31, 2024
1 check passed
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

Successfully merging this pull request may close these issues.

2 participants