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

Provide read-only access to window.location #156

Closed
srvance opened this issue Jul 19, 2016 · 1 comment
Closed

Provide read-only access to window.location #156

srvance opened this issue Jul 19, 2016 · 1 comment

Comments

@srvance
Copy link

srvance commented Jul 19, 2016

Summary: Provide an Ember-y way to read the full URL contained in window.location that also supports testable ways of changing the value.

Context: I have a site-brand service that computes critical branding elements based on the domain used to access the app. First invocation is from index.js to set the window title with ember-cli-document-title, so router-based solutions aren't sufficient. Testing the naive implementation of the service would require changing window.location directly which has undesirable consequences.

Alternatives:

  1. Someone suggested using this.get('router.url') but it's undefined in index.js and only returns the route path.
  2. Someone suggested using Ember.Location, but access to the required information in it is private and/or undocumented. The same thing goes for the underlying ember-metal/environment it relies on for location.
  3. Wrap access to window.location or memoize it in a way that can be overridden by tests.

I'm doing #3, but feel something more Ember-y would be of general utility.

I understand we're talking about SPAs, so the protocol and domain parts won't change over the app's lifetime. I also suggest read-only because external links should be handled as links and internal ones should be handled through the router. It should be changeable during testing, but without the side effects you'd get from changing window.location.

Thoughts?

@locks
Copy link
Contributor

locks commented Jan 16, 2017

As discussed on the Slack channel, I'm closing this issue since this should be able to be resolved via an addon, and @srvance will reach out if he hits any walls.

@locks locks closed this as completed Jan 16, 2017
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

2 participants