Skip to content
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

[bugfix] Properly alias cellValue #567

Merged
merged 2 commits into from
Jun 30, 2018
Merged

Conversation

pzuraq
Copy link
Contributor

@pzuraq pzuraq commented Jun 29, 2018

cellValue is a dynamically computed value that depends on the row value
and a dynamic key (the column.valuePath property). Currently it
updates the value once, and never after that. It can't respond to
external changes, and changes can't be bound.

This introduces a computed property that aliases based on a dynamic key.
It's based on the work in ember-macro-helpers, simplified a bit since we
don't need all the functionality in there. It could possibly be
simplified further in the future, but should get us where we need to be
for now.

cellValue is a dynamically computed value that depends on the row value
and a dynamic key (the `column.valuePath` property). Currently it
updates the value once, and never after that. It can't respond to
external changes, and changes can't be bound.

This introduces a computed property that aliases based on a dynamic key.
It's based on the work in ember-macro-helpers, simplified a bit since we
don't need all the functionality in there. It could possibly be
simplified further in the future, but should get us where we need to be
for now.
@pzuraq pzuraq merged commit 821270b into master Jun 30, 2018
@pzuraq pzuraq deleted the bugfix/properly-alias-cell-value branch June 30, 2018 00:19
HeroicEric pushed a commit to HeroicEric/ember-table that referenced this pull request Mar 9, 2021
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.
HeroicEric added a commit to HeroicEric/ember-table that referenced this pull request Mar 9, 2021
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.
HeroicEric added a commit to HeroicEric/ember-table that referenced this pull request Mar 9, 2021
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.
mixonic pushed a commit that referenced this pull request Mar 17, 2021
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant