-
Notifications
You must be signed in to change notification settings - Fork 351
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
Row cellValue not updating when columnValue.valuePath is updated (Ember >= 3.13.0) #808
Comments
I can also confirm that this issue exists still even with the just released Ember v3.16.0 and v3.17.0-beta.1. Its worth noting that the first version of ember that this issue started occurring, 3.13, was the Octane "preview release", and contained a large amount of changes to Computed Properties, introducing tracked properties, etc. So it seems likely that these large internal changes to the object model have something to do with this bug. For anyone else that encounters this, a very crude workaround can be implemented by forcing ember-table to recognize a change to the @tracked isChangingColumns = false;
@action
changeColumns() {
//do something that changes `this.columns`...
this.isChangingColumns = true;
next(this, () => this.isChangingColumns = false);
} <T.body @rows={{if this.isChangingColumns (array) this.rows}} /> |
Fixes Addepar#808 Fixes Addepar#820 The idea behind this is basically the same as Addepar#567. The value of `cellValue` is computed by grabbing the `columnValue.valuePath` and then grabbing the value of the corresponding key on `rowValue`. Basically something like `rowValue.${columnValue.valuePath}`, which is not possible using any of the built in computed macros. This basically uses an observer to watch for changes to `columnValue.valuePath`, and defines/redefines `cellValue` as a computed alias for the property at that path on `rowValue`. This ensures the `cellValue` is correct if `columnValue.valuePath` or the actual value at that path on `rowValue` changes. Observers aren't recommended but this was already using one. Previously this was solved by creating a more generic `dynamicAlias` computed macro in Addepar#567. To be honest, I was having a little trouble wrapping my head around all that was happening in there but I think the changes in this PR accomplish the same idea. I'm not totally sure what the issue was with the other implementation but, since the `dynamicAlias` macro was only used in this one place, it feels OK to have a more simple implementation that is hard coded specifically for this case.
Fixes Addepar#808 Fixes Addepar#820 The idea behind this is basically the same as Addepar#567. The value of `cellValue` is computed by grabbing the `columnValue.valuePath` and then grabbing the value of the corresponding key on `rowValue`. Basically something like `rowValue.${columnValue.valuePath}`, which is not possible using any of the built in computed macros. This basically uses an observer to watch for changes to `columnValue.valuePath`, and defines/redefines `cellValue` as a computed alias for the property at that path on `rowValue`. This ensures the `cellValue` is correct if `columnValue.valuePath` or the actual value at that path on `rowValue` changes. Observers aren't recommended but this was already using one. Previously this was solved by creating a more generic `dynamicAlias` computed macro in Addepar#567. To be honest, I was having a little trouble wrapping my head around all that was happening in there but I think the changes in this PR accomplish the same idea. I'm not totally sure what the issue was with the other implementation but, since the `dynamicAlias` macro was only used in this one place, it feels OK to have a more simple implementation that is hard coded specifically for this case.
Fixes Addepar#808 Fixes Addepar#820 The idea behind this is basically the same as Addepar#567. The value of `cellValue` is computed by grabbing the `columnValue.valuePath` and then grabbing the value of the corresponding key on `rowValue`. Basically something like `rowValue.${columnValue.valuePath}`, which is not possible using any of the built in computed macros. This basically uses an observer to watch for changes to `columnValue.valuePath`, and defines/redefines `cellValue` as a computed alias for the property at that path on `rowValue`. This ensures the `cellValue` is correct if `columnValue.valuePath` or the actual value at that path on `rowValue` changes. Observers aren't recommended but this was already using one. Previously this was solved by creating a more generic `dynamicAlias` computed macro in Addepar#567. To be honest, I was having a little trouble wrapping my head around all that was happening in there but I think the changes in this PR accomplish the same idea. I'm not totally sure what the issue was with the other implementation but, since the `dynamicAlias` macro was only used in this one place, it feels OK to have a more simple implementation that is hard coded specifically for this case.
Fixes #808 Fixes #820 The idea behind this is basically the same as #567. The value of `cellValue` is computed by grabbing the `columnValue.valuePath` and then grabbing the value of the corresponding key on `rowValue`. Basically something like `rowValue.${columnValue.valuePath}`, which is not possible using any of the built in computed macros. This basically uses an observer to watch for changes to `columnValue.valuePath`, and defines/redefines `cellValue` as a computed alias for the property at that path on `rowValue`. This ensures the `cellValue` is correct if `columnValue.valuePath` or the actual value at that path on `rowValue` changes. Observers aren't recommended but this was already using one. Previously this was solved by creating a more generic `dynamicAlias` computed macro in #567. To be honest, I was having a little trouble wrapping my head around all that was happening in there but I think the changes in this PR accomplish the same idea. I'm not totally sure what the issue was with the other implementation but, since the `dynamicAlias` macro was only used in this one place, it feels OK to have a more simple implementation that is hard coded specifically for this case. Co-authored-by: Eric Kelly <HeroicEric@users.noreply.github.com>
When using new versions of Ember (>= 3.13.0) ember-table isn't updating
row.cellValue
correctly even thoughcolumnValue.valuePath
has been changed. This occurs when setting a new array of columns to thetable.head.columns
property.Here is a simple Ember project displaying this issue:
ember-table-issue
The text was updated successfully, but these errors were encountered: