In a previous post, I provided a simple recipe for passing simple type arrays to avoid more formal data binding in Angular.
Recently a problem emerged where in Typescript (translated to JS), I were instancing randomly generated class/struct data called lineData in working with a visual graph/charts data interface and this data was instanced inside the class of two canvas selector directives from a parent component controller. My intent were to pass an array object of this class namely lineData[]
The problem:
When instancing a class array type of this data and while passing the array object of lineData, or lineData[], I was repeatedly generating errors in the contstructor and ngOnInit() or ngOnChanges() methods when attempting to write data to either directive instance. The error generated was an 'undefined' when accessing the lineData[] object even though it were supposedly populated in the constructor call with data. Strangely when not passing from the parent controller component to the individual child directives, lineData[] instanced at the child level with non injection would not generate non persistence problems as seen in the parent to child injection case.
Solution:
I still needed to pass and coordinate data between two child directives on the lineData[] array object, so instead, I opted to generate the random lineData[] at the parent component controller level and then pass this to each child directive where data persistence would suffice. This in retrospect still seems a bit troubling to me, one since evidently manipulating and instancing data in the child directive fails as an instancing source, but not if such origins are in the parent component controller class. Technically though it should work, it my suspicions are that the ngOnChanges() method is cleaning the lineData[] object (beyond the constructor call) with the changes in the parent level controller binding of this object to its child directives. Technically, I haven't set anything at the parent level to reset lineData[] (i.e., removing data or splicing or whatever), but the mystery remains as to what were occurring here.
Recently a problem emerged where in Typescript (translated to JS), I were instancing randomly generated class/struct data called lineData in working with a visual graph/charts data interface and this data was instanced inside the class of two canvas selector directives from a parent component controller. My intent were to pass an array object of this class namely lineData[]
The problem:
When instancing a class array type of this data and while passing the array object of lineData, or lineData[], I was repeatedly generating errors in the contstructor and ngOnInit() or ngOnChanges() methods when attempting to write data to either directive instance. The error generated was an 'undefined' when accessing the lineData[] object even though it were supposedly populated in the constructor call with data. Strangely when not passing from the parent controller component to the individual child directives, lineData[] instanced at the child level with non injection would not generate non persistence problems as seen in the parent to child injection case.
Solution:
I still needed to pass and coordinate data between two child directives on the lineData[] array object, so instead, I opted to generate the random lineData[] at the parent component controller level and then pass this to each child directive where data persistence would suffice. This in retrospect still seems a bit troubling to me, one since evidently manipulating and instancing data in the child directive fails as an instancing source, but not if such origins are in the parent component controller class. Technically though it should work, it my suspicions are that the ngOnChanges() method is cleaning the lineData[] object (beyond the constructor call) with the changes in the parent level controller binding of this object to its child directives. Technically, I haven't set anything at the parent level to reset lineData[] (i.e., removing data or splicing or whatever), but the mystery remains as to what were occurring here.
No comments:
Post a Comment