deep nested subviews issue of re-rendering

[orenmizr]

deep nested subviews issue of re-rendering

[dschissler]

I'm also having an issue where nested subviews cause it to render twice. Apparently subviews are simply broken. How is it nobody has discovered this. I crashed into this bug immediately upon trying to build a real program.

[edit] subviews work for me but just not two levels deep in declarative definition.

[cdaringe]

Can one of you get a requirebin going so we can look at it together?

[orenmizr]

too complex for requirebin but i can add you to my private repo, if you'd like. it is a discrete project.

[dschissler]

I am going to try overloading the _parseSubview method to get it to do what I want. I really don't have time to setup a test case. I'm guessing that it is something like pastebin?

If you could point me to a skeleton setup of Ampersand on requirebin then I could get to it soon.

[dschissler]

@cdaringe Maybe the problem is that many people are using waitFor with a relevant condition and so they are not noticing this bug?

[dschissler]

I have RootView -> ViewSwitcher -> HeaderView -> subview -> subview.

[cdaringe]

declarative subviews get rendered on on change:el, I believe. i'm pretty swapped at work ATM, but you could slap a debugger; perhaps in the parseSubviews fn and try and sniff a trace back on that second dubious render. perhaps if you're binding to the root element in both subviews this would occur. in the src there's a local fn called action that you can hook into for debugging purposes

[dschissler]

@cdaringe @orenmizr I think that I have a work around as I am now getting a proper display without a double render.

I set autoRender: false on my base view and then I just need to manually call render on my RootView - which is fine since I can now control it better in my base Application class (if I need to). I use two ViewSwitcher objects for my content and body area and this automatically calls render on the HeaderView and BodyView, which then works its way through all of the nested subviews with no problem.

So perhaps follow the autoRender code paths to find an issue?

[orenmizr]

@dschissler: the p.o.c i did with ampersand (as i recall) did rely heavily on waitFor for the nested views (all by the way - declarative subviews). even though they all waited for the same model.

[dschissler]

@orenmizr We both had this issue and I'm not yet using waitFor like you were. Perhaps it is tied to the fate of autoRender?

[orenmizr]

i am not using autoRender a lot BUT the problematic view does have it defined autoRender: true.

to be honest, after seeing how deserted the trello roadmap, gitter and github activity. i simply decided (even though i think it has great ideas) that i can't really use in production. so i haven't touched ampersand since. waiting for a sea change.

[dschissler]

I'm refactoring an existing Backbone application and Ampersand looks to be of a better design than Backbone+Marionette. I'm expecting to need to change all of my view code into a new framework in 2-3 years when many libraries will be using IE11 or MS Edge as a base line. A lot of the rewrite is moving everything to ES7/Babel and PostCSS and I'll be able to recycle much of that work. I just think that its a bad time to be investing into a new JS framework and so I'm going with something that is basically the same.

[orenmizr]

i am completely sold on ampersand. the ideas, design and the backbone-ish parts. i am too from a backbone + marionette. so i know how easy it was to adopt ampersand. but without active development, a big community to push forward and squash bugs with you - it's a bit risky. think, it has been a month since i opened this thread.

[cdaringe]

@orenmizr, did you figure out what was up?