Clean up Ember router map

[jaswilli]

• Switch resources to routes.
• No longer nest "settings" routes so the router reflects the way the templates are rendered.
• Remove renderTemplate override from settings routes.
• Remove unneeded routes, controllers, and views.
• Adjust users page so that infinite scroll loading of users works and markup remains the same for Zelda styling.

[cobbspur]

A lot of this looks good, I think it will make another routing task I was struggling on, a lot easier but I noticed you removed the redirect test for the about page and the redirect route. Consequently if I navigate to /ghost/settings/about I now get a 404 error which doesn't seem desirable.

[jaswilli]

if I navigate to /ghost/settings/about I now get a 404 error which doesn't seem desirable.

I'm not sure why you'd want a redirect to that route. It's a protected URL inside a single page app, so links inside the app should be updated and nothing external is linking to it.

[cobbspur]

I'm not sure what you mean by nothing external linking to it, how do you know that, you are guessing I think there. What makes you think I/somebody doesn't have a link to myblog.com/ghost/settings/about...

You can argue whether the about page has enough significance to warrant a redirect but when we moved debug tools to labs we set up a redirect and so for consistency alone I would think we need a redirect here but if other people disagree that's cool with me, how long we keep the redirect is another point to argue perhaps - maybe the debug redirect can go now?

[jaswilli]

Covered in the meeting so no need to go into it, except that for the record, I totally did argue against the Debug redirect 😛 , but since it was only a URL (never linked from the menu) it was argued that a redirect made sense, and I was convinced 😄

I'd be up for removing the Debug redirect unless there's third party documentation out there still referring people to it, in which case we may as well keep it...

[cobbspur]

I would say dump it, it's been in Labs for long enough and is clearly visible in the new nav menu :)

[jaswilli]

Updated--now removes the legacy Debug redirect.

[novaugust]

This is great. Nice cleanup, and I dig shifting our paradigm to export default all the things directly.

[ErisDS]

and I dig shifting our paradigm to export default all the things directly.

We use the export-at-the-end structure across both node and ember at the moment - so the code base is consistent. I agree that it can be a bit verbose, but consistency is king.

There are other ways to do this, which includes declaring the exports inline, which I believe is confusing in larger files, and also declaring first - I know this works in node not sure if it does in ember-land?

Either way - if there is a sense that this should be changed, it should probably be discussed in an issue or on slack and decided upon for certain, and then rolled out across the codebase.

[novaugust]

I thought the changeover had already begun - I've seen a few PRs getting merged in this style without comment.
It seems to be the standard for ES6, and I think is a more straightforward way of doing things in a file where the .extend is really the last line of the file anyways.

I believe putting the export on the declaration improves readability, particularly in files with a lot of code happening in the declaration. Making a variable there begs the question of "Do we do more things to this than just extend it?" forcing people to scroll through a bunch of code just to double check that the file puts out what they think it should anyways. Nice to have that immediately in most all of our files, where nothing else happens. One less cognitive switch / layer of indirection, is what I'm trying to say.

// foo.js Scroll!
var Foo = Bar.extend({
  //50 lines of code
  //..
  //....
});
export default Foo;

// foo.js No scrolling needed!
export default Bar.extend({
  //50 lines of code
  //..
  //....
});

[jaswilli]

There are a few reasons why I've started making this switch when I touch files in the ember app:

• This is the format that is preferred by ember-cli. If you ember generate controller mycontroller, the code that is generated is export default Ember.Controller.extend....
• Naming the thing via a var confuses people because of the "old" way in which the Ember resolver used variable names to look up objects.

var PostsPostController = Ember.Controller.extend();

export default PostsPostController;

The above implies that the name of the variable may be important.

• It's still "export at the bottom" since nothing occurs below that expression. I agree that if a file has a lot of different exports intermingled with non-exported code that we should have an exports block at the bottom of the file.