-
Notifications
You must be signed in to change notification settings - Fork 49
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
Ability to remove a resolved async node #404
Ability to remove a resolved async node #404
Conversation
d44a01b
to
5fe2d2a
Compare
af27395
to
bed39af
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #404 +/- ##
==========================================
+ Coverage 91.72% 91.84% +0.11%
==========================================
Files 338 338
Lines 26824 26831 +7
Branches 1941 1941
==========================================
+ Hits 24605 24642 +37
+ Misses 2206 2175 -31
- Partials 13 14 +1 ☔ View full report in Codecov by Sentry. |
3319bbe
to
f5731a4
Compare
|
||
expect(view?.actions[0].asset.type).toBe("action"); | ||
expect(view?.actions[1].asset.type).toBe("action"); | ||
expect(view?.actions[2]).toBeUndefined(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this not checking for something out of bounds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since view
is just a record, and the value of actions
can be of type any
, could you get actions[2]
being undefined but actions[3]
being well defined? If so, does it make more sense to check size rather than actions[2]
specifically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean I think we shouldn't check for view?.actions[2]
at all because there's no significance to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyhow view?.actions[2] would be undefined , but yes as you said it makes no sense checking for this at this point of time as view?.actions[2] is not expected at all. Removed it
f5731a4
to
50591e0
Compare
Updated business logic |
await new Promise((resolve) => setTimeout(resolve, 100)); | ||
|
||
// Verify that the updateNumber is still 0, indicating that the async node was not resolved | ||
expect(updateNumber).toBe(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm a bit skeptical with this test -- it doesn't look like you have the setup to update updateNumber
on view updates. And even then, I would expect it to update at least once for when the initial view resolution occurs when you start the Player
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I removed it on purpose , as I wanted to check if the view would still be resolved even if the baseplugin instance doesn't exist , do we still want the view to update ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have duplicate code in applyResolverHooks
, we can probably clean that up to be called in the apply
method. We should probably follow the convention of ApplicabilityPlugin
and rename it to applyResolver
|
||
expect(view?.actions[0].asset.type).toBe("action"); | ||
expect(view?.actions[1].asset.type).toBe("action"); | ||
expect(view?.actions[2]).toBeUndefined(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since view
is just a record, and the value of actions
can be of type any
, could you get actions[2]
being undefined but actions[3]
being well defined? If so, does it make more sense to check size rather than actions[2]
specifically
@@ -72,7 +86,7 @@ const player = new Player({ | |||
</core> | |||
<react> | |||
|
|||
The `react` version of the AsyncNodePlugin is identical to using the core plugin. Refer to core usage for handler configuration: | |||
The `react` version of the AsyncNodePluginPlugin is identical to using the core plugin. Refer to core usage for handler configuration: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should stay AsyncNodePlugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -42,7 +43,8 @@ This means there must be a constant renewal of new `AsyncNode`s after the previo | |||
|
|||
## Usage | |||
|
|||
The AsyncNodePlugin itself accepts a list of plugins and should take the AsyncNodePluginPlugin to be passed in. The AsyncNodePluginPlugin also comes from the `'@player-ui/async-node-plugin'` and contains the resolver and parser functionality | |||
The `AsyncNodePlugin` itself accepts an options object with a `plugins` array, enabling the integration of multiple view plugins for extended functionality. | |||
The `AsyncNodePluginPlugin` is provided as a default way of handling asset-async nodes, it is just one handler for one possible way of using async nodes. If the default behaviour does not align with the desired usage, users are able to provide their own implementation of the handler in the form of a plugin to be passed to the base `AsyncNodePlugin`.The `AsyncNodePluginPlugin` also comes from the `'@player-ui/async-node-plugin'` and contains the resolver and parser functionality |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The `AsyncNodePluginPlugin` is provided as a default way of handling asset-async nodes, it is just one handler for one possible way of using async nodes. If the default behaviour does not align with the desired usage, users are able to provide their own implementation of the handler in the form of a plugin to be passed to the base `AsyncNodePlugin`.The `AsyncNodePluginPlugin` also comes from the `'@player-ui/async-node-plugin'` and contains the resolver and parser functionality | |
The `AsyncNodePluginPlugin` is provided as a default way of handling asset-async nodes, it is just one handler for one possible way of using async nodes. If the default behavior does not align with the desired usage, users are able to provide their own implementation of the handler in the form of a plugin to be passed to the base `AsyncNodePlugin`. The `AsyncNodePluginPlugin` also comes from the `'@player-ui/async-node-plugin'` and contains the resolver and parser functionality. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
Returning a value in the above context enables uses cases where the async node only needs to be resolved once. For use cases where the async node needs to be updated multiple times, the onAsyncNode hook provides a second callback argument that can be used to update the value multiple times. For example, if the async node is used to represent some placeholder for toasts, or notifications, the async node handler could initially resolve with some content, and then update with null after some time to remove those views. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
||
expect(view?.actions[0].asset.type).toBe("action"); | ||
expect(view?.actions[1].asset.type).toBe("action"); | ||
expect(view?.actions[2]).toBeUndefined(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean I think we shouldn't check for view?.actions[2]
at all because there's no significance to it
plugins/async-node/core/src/index.ts
Outdated
|
||
return newNode; | ||
}); | ||
this.handleAsyncApi(resolver, view); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.handleAsyncApi(resolver, view); | |
this.applyResolver.bind(this) |
to keep convention consistent with other ViewPlugin
s
Ability to remove a resolved async node
Change Type (required)
Attaching logs FYR to see how the fucntionality works :
Key Changes
This version of the plugin allows for the flexibility needed to handle complex async updates, including conditionally removing resolved async nodes from rendering.
Test results:
https://app.buildbuddy.io/invocation/fc720b64-f848-4123-9e95-22216f410acc
patch
minor
major
Does your PR have any documentation updates?
Version
Published prerelease version:
0.8.0-next.4
Changelog
Release Notes
JS Package Cleanup (#442)
Fix migration issues in JS packages
Does your PR have any documentation updates?
Bazel 6 Migration (#252)
Swaps the repo internals to use
bazel@6
,rules_js
, bazel modules,vitest
andtsup
for the core + plugin builds🚀 Enhancement
🐛 Bug Fix
🏠 Internal
📝 Documentation
Authors: 11