Hi Alexandros, You are right, just updated http://plnkr.co/edit/mlwZYsmKL6KD6pwhyyQX?p=preview so it never reaches the $digest limit. The clean way to resolve the use of $parent is to create your own directive and call it within the switch (or other mechanism), as long as you are using some of the built-in directives, there is no easy way to avoid it.
Regards, Lucas On Friday, January 10, 2014 6:26:17 AM UTC-3, Alexandros Marinos wrote: > > Hi Lucas, > > Thanks for the detailed response (and the code!) > > The one thing I noticed is that your plunk also hits the digest limit, > with the same error I got. So even with avoiding a lot of Angular's > machinery, the digest limit is still an issue. Even if it didn't though, > the readability of the two examples is quite far off that it makes me think > "if that's wrong, I don't want to be right". > > I do like the idea about using (key, value) in both, I didn't know you > could do that! > > I have also found a way around using $parent.$parent.$parent, which makes > the code a bit more robust. (but I use ng-init and a single $parent to do > it). An updated plunk is here: > http://plnkr.co/edit/51XRoj5jProSiTbM9Gna?p=preview > > I'd still like to find a way to avoid hitting the digest limit if > possible, and a way to avoid "value in value", but without turning the code > into a procedural blob. > > cheers, > Alexandros > > On Thursday, 9 January 2014 19:25:08 UTC, Lucas Galfaso wrote: >> >> Let me answer inline >> >> >> On Wednesday, January 8, 2014 9:16:56 PM UTC-3, Alexandros Marinos wrote: >>> >>> I wanted to create an angular app that could visualise any json file, so >>> this explains the need for recursion. I did this with recursive templates. >>> >>> However, I wanted to be able to extract potential edits to the json >>> input, so that complicated things further. >>> >>> I have made it work, but not without doing a few things that would be >>> considered red flags. It feels to me like they were necessary sacrifices, >>> but I would like to be verified or corrected in that, for the sake of >>> learning Angular better. >>> >>> The working code is here: >>> http://plnkr.co/edit/30ST5BpBp2aAszeVdXNc?p=preview >>> >>> Here's a (partial?) list of red flags you'll find in the code: >>> >>> 1. $rootScopeProvider.digestTtl(16); >>> >>> The first thing I found was that the json depth that can be rendered was >>> limited by the digest limit. The current test file, with 5 levels of >>> recursion needs (5*3)+1 digest levels, hence 16. But for general use I'd >>> have to disable the digestTtl altogether (perhaps pass Infinite?) >>> >> >> This is easy to avoid, but you have to do some things slightly more >> manually and in a way that elements are added/removed asynchronously >> >> >> >>> >>> 2. ng-repeat="value in value" >>> >>> For the next level of the recursion to find the data where it was in the >>> previous one, this 'interesting' substitution has to be made. As far as I >>> can tell, this is completely kosher in Angular, as the first instance of >>> value is in the child scope, whereas the second is in the parent. >>> >> >> I do not think this is kosher at all, but this is my interpretation >> >> >> >>> >>> 3. ng-init="key = $index" >>> >>> While this is the 'proper' use of ng-init, that is to say in combination >>> with an ng-repeat, I feel aliasing $index is probably stretching it. >>> >> >> This can be fixed with ng-repeat="(key, value) in some-array", just as >> you do for object >> >> >> >>> >>> 4. ng-model="$parent.$parent.$parent.value[key]" >>> >>> Since there are three levels of scope created for each round of >>> recursion (ng-repeat, template, ng-switch) there need to be three levels of >>> parent climbed for the original value to be tracked by reference rather >>> than by value. This is needed to avoid copy-on-write which would block >>> extracting the full (edited) json file later without gobs of code. The use >>> of [key] also takes advantage of the fact that js addresses objects and >>> arrays in the same way. >>> >> >> This is a big red flag to me, using $parent means something is fragile. >> This needs some extra work and you need to make sure you reference the >> right object at the right scope. >> >> I put together these fixes at >> http://plnkr.co/edit/mlwZYsmKL6KD6pwhyyQX?p=preview This example does a >> lot of things manually that can be refactor into templates, but the way to >> fix the points you raised are there (there are other things in the example >> you posted that can be cleaned, but I made the assumption that this was >> just an example, so only look at the items you posted before) >> >> >> Regards, >> Lucas >> >> >>> >>> So this, then, is the question: Is there a way to do this that raises >>> fewer less flags, without adding reams of code to the current solution? I'm >>> quite happy to have made this work, but I would like to see if there is a >>> more correct solution. Improving the performance would be a definite plus. >>> >>> Your thoughts are welcome. >>> >> -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.
