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

Route vs Resource and the resetNamespace option #11251

Closed
hashemi opened this issue May 22, 2015 · 8 comments
Closed

Route vs Resource and the resetNamespace option #11251

hashemi opened this issue May 22, 2015 · 8 comments

Comments

@hashemi
Copy link

hashemi commented May 22, 2015

Since 1.11.0, this.resource has been deprecated in favour of nested this.route. However, the difference in namespacing behaviour requires a large refactor involving moving route and template files and folders around and changing many references in link-to and transitionTo calls. In addition to requiring a refactor, it also breaks the analogy between the model tree and the route/template tree.

Passing { resetNamespace: true } as an option to this.route results in the namespacing behaviour of a resource. This has been proposed as an easy way to remove the deprecated this.resource usage from applications. (See Erik Bryn's Ember 2.0 Talk at 11:10 and this StackOverflow Answer)

However, resetNamespace is not a documented public API and if I understand the code correctly, it is merely a flag for the router to differentiate between this.route and this.resource. Therefore, it would stand to reason that when this.resource is removed, resetNamespace will be removed with it.

An official statement regarding this may save the community a lot of unexpected grief as users follow the stability without stagnation plan.

@rwjblue
Copy link
Member

rwjblue commented May 22, 2015

However, resetNamespace is not a documented public API and if I understand the code correctly, it is merely a flag for the router to differentiate between this.route and this.resource

Thanks for asking! I personally consider it a private API at the moment, but am not opposed to making it public if folks see a need for it longer term. I am not sure that preventing a refactor to a nested layout justifies supporting both concepts long term (seems to me that the point of all deprecations is refactoring to a better pattern), but I definitely agree that we should formally decide so folks know what to do going forward.

@mixonic
Copy link
Sponsor Member

mixonic commented May 22, 2015

I am pretty strongly in favor of having a way to reset namespaces. A big app can get really gnarly without it (pods dirs 4 or 5 layers deep).

@mixonic
Copy link
Sponsor Member

mixonic commented May 22, 2015

An example: https://github.com/aptible/dashboard.aptible.com/blob/master/app/router.js#L13

I did not realize we currently have no public API for resetting namespace.

@rwjblue
Copy link
Member

rwjblue commented May 22, 2015

I did not realize we currently have no public API for resetting namespace.

Technically, this.resource is not deprecated yet, and is still currently public API. Though I think we would all agree that having both this.route and this.resource long term is not good.

@diogomafra
Copy link
Contributor

I think this issue can be closed. The option resetNamespace is documented here: https://github.com/emberjs/ember.js/blob/master/packages/ember-routing/lib/system/router.js#L930

@rwjblue
Copy link
Member

rwjblue commented Aug 2, 2015

Thanks @diogomafra!

@tsmacdonald
Copy link

@diogomafra That's a dead link, the current version is here. I do think that this should be documented somewhere more user-friendly than a source file, though. I expected to see it in the Ember guide, for example.

@marclundgren
Copy link

marclundgren commented Oct 6, 2016

Linking to a blob like master will only contain link to the relevant content as long as it's position doesn't change on that branch.

Here: this points to a commit on master (today): https://github.com/emberjs/ember.js/blob/d3ceb22/packages/ember-routing/lib/system/router.js#L1168

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

6 participants