Does ember strip hashes in URLs?

I’m not super experienced with ember, and I’m still on the beginner’s side of the learning curve, so bear with me if I ask anything a bit off :smile:

In Discourse, I’ve noticed that all links with hashes/anchors at the end are being stripped. ie: FAQ - Demo does not work on page-load, but if a hash is set after load, it works normally.

Is ember doing this? I am looking for more ember based projects to see if they do, and how they handle it in certain situations. Thanks!

Ember.js’ router delegates all URL-related responsibilities to an object call a location. Discourse has a custom location object that uses the pushState API to create URLs that do not have a # in them.

There are two downsides to pushState:

  1. It does not work in older browsers.
  2. It requires special configuration on the server hosting the static assets.

Unless I’m mistaken, the DiscourseLocation object (which is really just a HistoryLocation with some tiny fixes I have not pushed upstream yet) doesn’t strip any hashes.

I put some logged into it, and it seems the paths that it gets already have the hashes stripped.

This might not make sense and be stupid, but do you think it’s possible to mix both? For example can we route to /faq using pushState and THEN jump to the #keep-tidy element?

It doesn’t sound like it would be hard to make /faq/keep-tidy work but I am wondering if it would be possible to just ignore the #keep-tidy and then somehow have a method to query it in the router so we can jump to the element we want?

2 Likes

Based on @eviltrout’s answer, the #keep-tidy part of

Is stripped by the Ember routing engine. So @tom can it… please not do that? I personally find it very irritating that basic HTML stuff like deep linking to a named element stops working.

I’m fine with re-parsing the #keep-tidy with JavaScript, but I seriously object to forcing us to use

http://try.discourse.org/faq/keep-tidy

Which is semantically completely different. And worse!

3 Likes

I’m with Jeff on this one. Right now, this is achievable by doing something like this prior to app initialization:

var windowParams;

windowHash = function() {
  var hashStr;
  return hashStr = window.location.hash;
};

Assigning windowParams as a property on the app during initialization is a convenient second step. Having the Router do this automagically would be great though.

1 Like

I meant to respond to this and completely forgot.

I want to do that but am unsure if I should tamper with anything in the initialization of discourse’s ember app. I should do a bit more reading first. I’ll probably play around with it on a local server for a bit.

@eviltrout do you have any opposition to it yourself?

on the other hand it has some major advantages

  1. # portions of urls are never passed to the server, meaning you have no way of shipping the content with the initial payload, the client needs to figure out where she is and perform a second round trip to get the actual payload

  2. (1) means you can not be indexable for non js aware crawlers

  3. #! is a major hack generally discouraged where possible

2 Likes

Can you expand on this? not following (are you alluding to the double router implementation)

2 Likes

I’m interesting this too, every time when I hear about pushState is there a condition that a server requires special configuration, but what type of configuration, do I need to setup up mod_rewrite?

I understand why this configuration is required, but I don’t know how to do that. I don’t need detailed instructions, but show the right way only.

Thank you for advice.