This was a disturbing discovery. Requests in watch loops would recycle
AbortControllers meaning once any request was aborted, all requests
forever after were skipped. I noticed it with deployments and job
summary on the job detail page.
I suspect this regression occurred when jQuery was removed. This needs
test coverage still to make sure it doesn't happen again.
These are based on the source code for selectChoose. I would have liked
to have used selectChoose, but the implementation has two await
settled()s in it which prevented me from writing the tests I needed to
write.
These new extension helpers separate selectChoose into two pieces so
logic can be placed between the two async actions.
The id-processing in the WatchableNamespaceIds adapter was
happening twice; this removes urlForUpdate record so it
only happens once. @DingoEatingFuzz figured it out! 🥳
Originally this was failing because it only had a getter.
I tried replacing it with a computed property and that
succeeded, but since we have already stopped using
jQuery, we might as well remove it.
Manual interventions:
• decorators on the same line for service and controller
injections and most computed property macros
• preserving import order when possible, both per-line
and intra-line
• moving new imports to the bottom
• removal of classic decorator for trivial cases
• conversion of init to constructor when appropriate
This is extracted from #8094, where I have run into some snags. Since
these ESLint fixes aren’t actually connected to the Ember 3.16 update
but involve changes to many files, we might as well address them
separately. Where possible I fixed the problems but in cases where
a fix seemed too involved, I added per-line or -file exceptions.
This is mostly a direct application of the ember-angle-brackets-codemod.
I manually restored newlines in multi-line component invocations, usually
preserving file line length except for now-non-positional link-to @route.
I needed to rename task to taskState in some cases to avoid Ember
Concurrency naming conflicts.
This partially addresses #7799.
Task state filesystems are contained within a subdirectory of their
parent allocation, so almost everything that existed for browsing task
state filesystems was applicable to browsing allocations, just without
the task name prepended to the path. I aimed to push this differential
handling into as few contained places as possible.
The tests also have significant overlap, so this includes an extracted
behavior to run the same tests for allocations and task states.
Michael Lange