-
Notifications
You must be signed in to change notification settings - Fork 101
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
Reimplemented Workers using side effects (GUWT). #110
Conversation
@@ -16,7 +16,7 @@ import kotlin.test.Test | |||
import kotlin.test.assertEquals | |||
import kotlin.test.fail | |||
|
|||
private const val WORKER_COUNT = 1000 | |||
private const val WORKER_COUNT = 500 |
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.
Workers are a lot slower now, unfortunately. Fortunately, any optimizations we do for rendering Workflows will now also speed up workers, theoretically.
480469c
to
4f6a074
Compare
inline fun <T, reified W : Worker<T>, PropsT, StateT, OutputT> | ||
RenderContext<PropsT, StateT, OutputT>.runningWorker( | ||
worker: W, | ||
key: String = "", | ||
noinline handler: (T) -> WorkflowAction<PropsT, StateT, OutputT> | ||
) { | ||
/* ktlint-enable parameter-list-wrapping */ | ||
runningWorker(worker, typeOf<W>(), key, handler) |
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 isn't the API I'd ideally like to have, but since we don't have access to the full reflection library in this module, it's the best we can do. If we did, we could create the full worker type from the worker's class and the worker's outputType
property, or maybe using the reified T
type parameter. But since we don't, all we have is typeOf()
, which means we need to reify the entire worker type.
However, while less flexible, it has the nice property that the type that is used to compare the worker will always be exactly the type for the worker that the IDE is showing you when you pass it to runningWorker
. There's no mystery or hidden implementation details anymore. You might need to pass a few more key
s in, but that's probably a good idea anyway.
workflow-core/src/main/java/com/squareup/workflow/LifecycleWorker.kt
Outdated
Show resolved
Hide resolved
workflow-core/src/test/java/com/squareup/workflow/WorkerTest.kt
Outdated
Show resolved
Hide resolved
d47b57d
to
585ba45
Compare
samples/dungeon/common/src/main/java/com/squareup/sample/dungeon/GameWorkflow.kt
Show resolved
Hide resolved
@@ -179,7 +178,7 @@ interface Worker<out OutputT> { | |||
* } | |||
* ``` | |||
*/ | |||
fun doesSameWorkAs(otherWorker: Worker<*>): Boolean = otherWorker::class == this::class | |||
fun doesSameWorkAs(otherWorker: Worker<*>): Boolean = true |
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'm unclear why these changes to true
are okay.
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.
Good point. The thinking was that the old default, comparing classes, would always be true now since the runtime itself is ensuring that worker types match. However, we ended up only comparing on the declared type of the worker, which means two workers that the runtime thinks are equivalent could still be different classes, so it would be safer to leave the class checks in here.
That said, by defaulting to relying on concrete types again, we lose the nice simplicity for testing. Not sure what the best thing to do is.
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.
Reverted this default implementation, and added a bunch of tests around it. This implementation makes sense, because if the concrete type of a worker changes (e.g. was running a parent type, then runs a subtype with the same declared type), then the worker should restart. I need to document this somewhere…
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.
Additional documentation added to runningWorker
and doesSameWorkAs
.
workflow-testing/src/main/java/com/squareup/workflow/testing/RenderTesterWorkers.kt
Show resolved
Hide resolved
workflow-testing/src/test/java/com/squareup/workflow/testing/WorkerRenderExpectationsTest.kt
Show resolved
Hide resolved
workflow-testing/src/test/java/com/squareup/workflow/testing/WorkerRenderExpectationsTest.kt
Outdated
Show resolved
Hide resolved
workflow-testing/src/main/java/com/squareup/workflow/testing/RenderTesterWorkers.kt
Outdated
Show resolved
Hide resolved
585ba45
to
42859d0
Compare
Just found a pretty bad bug that blocks the release, but I want to fix separately: #120 |
6c2e14d
to
76b2c37
Compare
Issues: - Fixes #82, which is the Kotlin half of square/workflow#1021. - Fixes #92. - Fixes square/workflow#1197.
76b2c37
to
5a883c6
Compare
Issues: