adopted-ember-addons
`firstItemPosition` computed property is not recomputed when `sortedItems` changes
This PR proposes a fix for the test case highlighted in the PR https://github.com/adopted-ember-addons/ember-sortable/pull/599.
The changes removes the computed property on the firstItemPosition getter in sortable-group.ts modifier as it's not recomputed when the sortedItems array changes from the outside. If excessive recomputation of that getter gets expensive we could maybe use the more modern @cached decorator from @glimmer/tracking ?
Deploy Preview for ember-sortable canceled.
| Name | Link |
|---|---|
| Latest commit | 9f74129f0a5b0f070927d2e9dd426996951b24af |
| Latest deploy log | https://app.netlify.com/projects/ember-sortable/deploys/6863c86d0d5dcd0008f385bc |
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi @cyril-sf, can any maintainer look into this issue and related PR ? We're currently using our fork in our main production application, but would prefer not to...
I'd feel more comfortable if this PR provided a test that failed before the changes here, and then passes afterwards <3
The changes to the test app feel a smidge excessive? Why'd every example have to change? Can something more targeted happen instead?
Also, biggest apologies for not commenting sooner. I don't know how i missed this PR <3