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

application view rerender(): Uncaught TypeError: Cannot read property 'append' of null #10304

Closed
zyllorion opened this issue Jan 29, 2015 · 3 comments

Comments

@zyllorion
Copy link

Ember-cli 0.1.9
ember.debug.js:4272 DEBUG: Ember : 1.11.0-beta.1+canary.22d2afab
ember.debug.js:4272 DEBUG: Ember Data : 1.0.0-beta.14.1
ember.debug.js:4272 DEBUG: jQuery : 1.11.2
ember-cli-i18n 0.0.5

Stack:

Uncaught TypeError: Cannot read property 'append' of null
Renderer_insertElement
Renderer_renderTree (anonymous function)

Called from here (the anonymous function above):

// TODO: should be scheduled with renderer
        run.scheduleOnce('render', function () {
          if (view.isDestroying) {
            return;
          }
          view._renderer.renderTree(view, view._parentView);
        });

Erroring on this line:

    function Renderer_insertElement(view, parentView, element, index) {
      if (element === null || element === undefined) {
        return;
      }

      if (view._morph) {
        view._morph.setContent(element);
      } else if (parentView) {
        if (index === -1) {
>>>>          view._morph = parentView._childViewsMorph.append(element);
        } else {
          view._morph = parentView._childViewsMorph.insert(index, element);
        }
      }
    }

I'm trying to refresh all views after modifying locale translations for ember-cli-i18n.
The code I'm using to refresh the top level application view is:

Ember.$.each(Ember.View.views, function(i, view) {
                    if (view.renderedName === "application") {
                        view.rerender();
                        Ember.Logger.debug('rerendering application view');
                    }
                });

Originally posted here:
tildeio/htmlbars#271

@rwjblue
Copy link
Member

rwjblue commented Jan 29, 2015

A few JSBin's:

I was unable to replicate the exact error that @zyllorion is reporting though (but clearly there are some thing to fix).

@zyllorion - Can you tweak one of my JSBin's above to trigger the specific error that you are getting?

@krisselden
Copy link
Contributor

@rwjblue this is a bug, the parent view destroys views connected to an outlet and when rendering again errors trying to reattach destroyed views

@ef4 ef4 closed this as completed in ba1d1a6 Feb 8, 2015
ef4 added a commit that referenced this issue Feb 8, 2015
This closes #9814 and closes #10304, which are examples of a class of
problems caused by the way the router synchronously reaches into the
view hierarchy to set outlet state. It is a significant refactor of the
way the router communicates state to outlets.

What motivates this change?

 - Simple examples like `{{#if something}}{{outlet}}{{/if}}` are
   incorrect under the current model.

 - Richer examples like block-helpers to enable animation also
   suffer. In general, the router cannot know when and whether a
   particular outlet is going to exist, and it shouldn't need to know.

 - The router maintains a bunch of view-related state that is actually
   redundant with the view hierarchy itself, leading to unnecessary
   complexity.

 - This eliminates the longstanding weirdness & confusion caused by the
   fact that we used to create new `View` instances and then throw them
   away if they looked similar enough to ones that were already
   rendered. That functionality is now covered by state diffing in the
   `OutletView`.

 - We reduce the API surface area between router and view layer in a way
   that should make it easier to experiment with swapping in compatible
   implementations of either.

 - As a bonus, this changes makes outlets work in an observer-free way
   that will make them easy to integrate with upcoming planned view
   layer optimizations.

How does this work?

 - Rather than directly building and linking views, the router builds up
   an abstract summary of the render decisions that have been made by
   the current routes.

 - This state is cheap to recalculate as needed. It doesn't do any view
   creation. To avoid expensive observer creation & teardown, we just
   recreate the whole thing and use a `setState`-like mechanism to
   propagate the changes through the outlet hierarchy. This gives us
   optimal granularity of updates.

 - Actual view instantiation moves into the OutletView -- within the
   view layer where it belongs. Each outlet does a diff to see whether
   it should rerender itself or propagate inner changes down to its
   child outlets.

 - To bootstrap rendering, the router creates a single top-level outlet,
   after which all view creation is internal to the view layer.

Does this break any existing semantics?

 - No, as far as I can tell.

Could this get even better if we decided to deprecate some old
semantics?

 - Yes. It would be better if users` `renderTemplate` implementations on
   `Route`s were required to be idempotent. Then we could eliminate a
   bunch of the remaining state from them.

 - Also, when we deprecate the `render` helper we can eliminate the
   remaining use of `_activeViews` state tracking on the router. That is
   the only remaining use for it.
@dogawaf
Copy link

dogawaf commented Feb 22, 2015

Hi!

I was updating an app from 1.7.1 to 1.8.1, and I found the same issue (or maybe another one).

With 1.7.1: rerender the application view works fine
With 1.8.1 or 1.9.1 : rerender throw an error: Error while processing route: XXX Cannot read property 'connectOutlet' of undefined
With canary: rerender works fine

Here is a simple jsbin to demonstrate how to reproduce my issue (just play with the set of script tags): http://emberjs.jsbin.com/naquvegali/3/edit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants