[
https://issues.apache.org/jira/browse/COUCHDB-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174686#comment-14174686
]
Ben Keen commented on COUCHDB-2392:
-----------------------------------
Okay, I think I've got to the bottom of it. Sorry, it’s a bit dense and will
take some explaining.
This is one-off scenario and only occurs on initial page load - not when
navigating to the page from with Fauxton. I looked through the codebase and
this is the only instance in the code where a FauxtonAPI.triggerRouteEvent() is
called from within a View's afterRender(). What's happening is that the initial
page render hasn't finished before the triggerRouteEvent is called. So in terms
of actual code being executed we have:
1. afterRender() of the View
2. FauxtonAPI.triggerRouteEvent() is called, which is calling some async code
deep down [haven't determined exactly what yet...]
3. the RouteObject's renderComplete() function fires for the initial page load
4. Now the code from #2 executes, causing the View's afterRender to get called
again
5. the RouteObject's renderComplete fires again
I don't think it makes sense to fire a route event when another hasn't finished
(but nor should a developer have to worry about that!) The lifecycle of a
page/route load is pretty complex, so I guess it’s not surprising that having
two executing at the same time has lead to weird problems, like this one.
Solution-wise, one option would be to keep a queue and only execute them when
the first is complete. The other would be keep track of when the first
renderComplete is actually loaded, and add a check in the triggerRouteEvent
code to ignore (yuck).
But I think we might be approaching this wrong… The reason the
triggerRouteEvent call was added into the afterRender function in the first
place was to prevent us having to explicitly pass a QueryOptionsTray View
instance to the ViewEditor, so it could tell it what to show/hide/prepopulate
directly. That decision made total sense - it was klutzy. Using
triggerRouteEvent was a convenient way to get around that. But the thing is
it’s really *not* an event on the route object - conceptually we don’t want to
“trigger a route change” we just want to use the route object as an
intermediary to pass info to one of it’s subviews.
So maybe we could just publish a generic backbone event or something that the
Query Options tray subscribes to? Any other alternatives…?
> afterRender is called twice
> ---------------------------
>
> Key: COUCHDB-2392
> URL: https://issues.apache.org/jira/browse/COUCHDB-2392
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Fauxton
> Reporter: Robert Kowalski
> Assignee: Ben Keen
>
> afterRender is called twice - I thought Garren fixed it some time ago, but it
> seems to happen again.
> see:
> https://github.com/apache/couchdb-fauxton/commit/332c7b5350a928e35006e821f1f8bf9b6b748c12#diff-4a170929e0ed75614fc691eaa2dac8b9R37
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
