Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

Sidenav doesn't show on partial view #473

Closed
ghost opened this issue Oct 24, 2014 · 7 comments
Closed

Sidenav doesn't show on partial view #473

ghost opened this issue Oct 24, 2014 · 7 comments

Comments

@ghost
Copy link

ghost commented Oct 24, 2014

When I change view (ng-view) using partials, the sidenav inside my partial view doesn't get toggled (both 'on' and 'off' won't work) unless I reload the whole page.

Any idea?

Code is pretty simple: got a sidenav in the main layout (which currently has no issues) and various (depends on the partial, between 1 and 2) other sidenavs which need a click on a button (with a call on a $scope function) to get toggled.

@ajoslin
Copy link
Contributor

ajoslin commented Oct 28, 2014

Can you open a plunkr with a reproduce case?

@ghost
Copy link
Author

ghost commented Oct 29, 2014

Aye, here it is:

http://plnkr.co/F2q4nCgloqnIX7gJjkTL

You might need to wait some seconds to see the full view due to heavy scripts inclusions (angular-animate, angulat-route, etc.)

@crrazymind
Copy link

+1 for this issue.
Seems that $mdComponentRegistry doesn't check for duplicates on register step.
And it returns wrong instance of sidenav when partial view loads again.

@ajoslin
Copy link
Contributor

ajoslin commented Oct 30, 2014

Good catch @crrrazymind.

The component registry is very old, and was only meant to be a proof of concept. It will be refactored soon.

For now, I would advise using data-binding to open and close your sidenav.

@ghost
Copy link
Author

ghost commented Oct 31, 2014

Nice to know what it's about.

@ajoslin What do you mean by "data-binding" to open and close the sidenav?

@ajoslin
Copy link
Contributor

ajoslin commented Oct 31, 2014

Use the is-open attribute. It's in the API documentation for sidenav.

@ghost
Copy link
Author

ghost commented Nov 3, 2014

Thank you for explanation, your suggestion works perfectly.

@ghost ghost closed this as completed Nov 3, 2014
pandaiolo added a commit to pandaiolo/material that referenced this issue Nov 4, 2014
Element registry is currently kept even after element
is removed from DOM. Appart from the memory leak, it
also disable future components with same handle from
beeing pulled from the registry, for example when users
navigate away/back to a page, DOM is reloaded but new
component does not work anymore (old registry
component is called instead of the new one)

@ajoslin reported in referenced issue that registry
component will be refactored. Until then, this patch
should fix the bug on the component side.

Closes angular#473,angular#474
ajoslin pushed a commit that referenced this issue Nov 6, 2014
Element registry is currently kept even after element
is removed from DOM. Appart from the memory leak, it
also disable future components with same handle from
beeing pulled from the registry, for example when users
navigate away/back to a page, DOM is reloaded but new
component does not work anymore (old registry
component is called instead of the new one)

@ajoslin reported in referenced issue that registry
component will be refactored. Until then, this patch
should fix the bug on the component side.

Closes #473,#474
pandaiolo added a commit to pandaiolo/material that referenced this issue Nov 6, 2014
Element registry is currently kept even after element
is removed from DOM. Appart from the memory leak, it
also disable future components with same handle from
beeing pulled from the registry, for example when users
navigate away/back to a page, DOM is reloaded but new
component does not work anymore (old registry
component is called instead of the new one)

@ajoslin reported in referenced issue that registry
component will be refactored. Until then, this patch
should fix the bug on the component side.

Closes angular#473,angular#474
pandaiolo added a commit to pandaiolo/material that referenced this issue Nov 6, 2014
Element registry is currently kept even after element
is removed from DOM. Appart from the memory leak, it
also disable future components with same handle from
beeing pulled from the registry, for example when users
navigate away/back to a page, DOM is reloaded but new
component does not work anymore (old registry
component is called instead of the new one)

@ajoslin reported in referenced issue that registry
component will be refactored. Until then, this patch
should fix the bug on the component side.

Closes angular#473,angular#474
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants