-
Notifications
You must be signed in to change notification settings - Fork 1k
[@task] allow initial value #2836
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
Conversation
🦋 Changeset detectedLatest commit: b848485 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultslit-element-list
render
update
update-reflect
lit-html-kitchen-sink
render
update
nop-update
lit-html-repeat
render
update
lit-html-template-heavy
render
update
reactive-element-list
render
update
update-reflect
|
|
related to: #2367 |
|
What is a concrete use case for this? I don't fully understand that yet. |
|
@mohe2015 one potential use-case is lazy loading / lazy execution of a task, providing data for the initial render but before a remote request, a kind of User loads page. Component needs a visual "stencil" up until the asynchronous task is requested / performed / completed. |
|
addressed feedback |
sorvell
left a comment
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.
Please add a test where initialValue is set.
|
@sorvell added a test for initial values :) ready for another review |
AndrewJakubowicz
left a comment
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.
Please remove all the .wireit directory files.
They should have been ignored by .gitignore?
|
thanks @AndrewJakubowicz, theyve been removed. |
sorvell
left a comment
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.
Almost there, just a couple of points to address, see comments. Let's also make sure to update the PR description to say that the value is only updated when the task completes (currently, it incorrectly says that it's reset to the initialValue).
| assert.equal(el.taskValue, undefined); | ||
| }); | ||
|
|
||
| test('tasks start with initialValues in the first PENDING state', async () => { |
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.
Please add another test that specifically validates the task value during the different states when it's re-run. Some of the changes here reflect the new behavior but I think it makes sense to have a test that focuses on that aspect.
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!
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 want specifically a test that validates that the value is not reset when the task is re-run (before it completes). This has nothing to do with initial value, but the behavior is being changed with this PR.
|
Sweet! thanks yall
|
This is not true is it? |
| --- | ||
|
|
||
| Added `initialValue` parameter to `TaskConfig`. | ||
| Task can start with an initial value from TaskConfig. |
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 are changing the behavior of how value is treated when the task is re-run. This should be called out specifically here.
| } | ||
| this.status = TaskStatus.PENDING; | ||
| this._error = undefined; | ||
| this._value = undefined; |
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 is the significant change that I want to make sure we're documenting and testing.
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.
First I think we need to decide that this is the behavior we want. Is it required to add an initial value? Should it be controlled with an option? Let's chat.
| assert.equal(el.taskValue, undefined); | ||
| }); | ||
|
|
||
| test('tasks start with initialValues in the first PENDING state', async () => { |
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 want specifically a test that validates that the value is not reset when the task is re-run (before it completes). This has nothing to do with initial value, but the behavior is being changed with this PR.
e111077
left a comment
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.
Technically this looks fine to me. Code LGTM
I'm also in favor of this behavior – Task has the tendency to flicker. Would be cool if value is the way to make it not
|
Haven't checked on this PR in a while, will update and rerequest a review. I think the tests could be better |
|
Superseded by #4001 |
Currently the
initial valueofTaskis assumed to beundefined.This is the default behavior. When a Task is "re-run",
valueis set asundefined.This PR adds an
initialValueto theTaskConfiginterface.When no
intialValueis set, the behavior described above is preserved.When
initialValueis set, the value is only updated when the task completes. As in, the initial value will not be set in futurePENDINGstates.