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

Can no longer use a string for the gridOptions.data property #6155

Closed
lobo78 opened this issue Apr 10, 2017 · 8 comments · Fixed by #6649
Closed

Can no longer use a string for the gridOptions.data property #6155

lobo78 opened this issue Apr 10, 2017 · 8 comments · Fixed by #6649
Assignees

Comments

@lobo78
Copy link
Contributor

lobo78 commented Apr 10, 2017

As of 4.0.3, I can no longer set the value of the gridOptions.data property as a string. For 4.0.2, it works perfectly, but in 4.0.3+, the grid is not rendered.

Here is a plunker that shows the issue: http://plnkr.co/edit/J9Xr3AuxI28FfxtYQstG

I'm not sure, but I believe the problem is inside the dataWatchFunction, because the newData array becomes undefined here.

@RaeCai
Copy link

RaeCai commented Apr 17, 2017

I am facing the same issue with updating from 4.0.2 to latest version, any workaround for this?

@RaeCai
Copy link

RaeCai commented Apr 17, 2017

instead of using string in gridOptions.data, i am setting this value using service response. thanks for your clarification.

@paulcsiki
Copy link

I had the same problem and I've replaced the string binding with an empty array that was getting updated whenever I had the data ready.

@StrangelyTyped
Copy link
Contributor

I've just run into this exact issue, first of all I believe that #6185 is a duplicate of this issue.

The problem was introduced here in v4.0.3 - where that fastWatch check was present previously it meant the newData value was provided by the scope watch instead of that block of code at the top of the function. This means that where previously the value would be extracted from scope directly it is now explicitly extracted from appScope with the following implications:

  • appScope may not necessarily be the same as (or even related to) $scope. The data is pulled from appScope but the watch is attached to $scope, resolving the string expression against each of these may produce different values.
  • the linked code resolving against appScope doesn't support "x.y.z" syntax, but resolving against $scope (as happens through the watches) does - ng-grid does not allow 'controller as' syntax for gridOptions.data #6185

I'd also like to note that the fastWatch option that features quite prominently in this area of the code doesn't appear to be documented anywhere.

przemyslawlis added a commit to campsych/concerto-platform that referenced this issue May 17, 2017
@trailblazer1414
Copy link

Same issue. downgraded to 4.0.2

@caseyjhol
Copy link
Contributor

@mportuga Thoughts?

@mportuga
Copy link
Member

mportuga commented Feb 7, 2018

My guess is that it has to do with my changes to try and reduce the number of digest cycles:
205a215
e6ab96b
56f0dc1

@mportuga mportuga self-assigned this Feb 7, 2018
@Joel-Kornbluh
Copy link

Joel-Kornbluh commented Mar 14, 2018

@mportuga this was caused by 75f98c3#diff-d586707ee1c4e842337e09afc6ebd587L87

We should be probably just restore the if ( self.grid.options.fastWatch ){....

mportuga pushed a commit that referenced this issue Apr 2, 2018
Added back if statement in the dataWatchFunction and added an $eval to ensure controllerAs systax is
supported.

fix #6377, fix #6155
mportuga pushed a commit that referenced this issue Apr 2, 2018
Added back if statement in the dataWatchFunction and added an $eval to ensure controllerAs systax is
supported.

fix #6377, fix #6155
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants