Why does the plugin enable html5 pushState?

[searls]

Ref: https://github.com/linemanjs/lineman-angular/blob/master/config/plugins/server.coffee#L4

I'm inclined to disable this in a minor bump of the project. Unless there's something about the Angular community that makes them disproportionately more likely to want html5 pushState enabled by default than the rest of the Internet, I think it's only going to continue to trip people up who want to benefit from the (much more immediately beneficial) API proxy.

Arguments against: @jasonkarns @davemo @Foxandxss?

[markbates]

Personally, I like that pushState is enabled by default, one less thing for me to have to set up in my applications.

[davemo]

I defaulted it to on because my experiences in the real world™ :P have led me to believe the pointy-haired types like to harp on single-page apps when they see the "ugly urls" /#/login. Essentially this was a conscious choice made to disarm one piece of FUD I'd experienced in the wild.

I don't hold that opinion too closely so if this is causing other issues or complexity in stubbing I'm fine with flipping it.

[searls]

What I'm really looking for in this question is whether angular is materially different than other web frameworks. If it isn't then I don't see why this setting is being flipped in this plugin and not in lineman core.

[davemo]

I don't think it's appropriate in Lineman core given it's specific to the use of a single page app framework when working with Lineman.

[jasonkarns]

Now would be a good time to remember the Big Brother idea about tracking
the use of lineman. This would be an excellent metric driven decision

[searls]

I don't trust myself not to abuse all of that data.

On Thu, Feb 13, 2014 at 10:33 PM, Jason Karns notifications@github.comwrote:

Now would be a good time to remember the Big Brother idea about tracking
the use of lineman. This would be an excellent metric driven decision

Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-35052723
.

[searls]

(Which is a FUD-ey way to say "let's just do it the way I want!")

On Thu, Feb 13, 2014 at 10:37 PM, Justin Searls searls@gmail.com wrote:

I don't trust myself not to abuse all of that data.

On Thu, Feb 13, 2014 at 10:33 PM, Jason Karns notifications@github.comwrote:

Now would be a good time to remember the Big Brother idea about tracking
the use of lineman. This would be an excellent metric driven decision

Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-35052723
.

[jasonkarns]

My gut is saying leave it off for now. Probably change default to enabled
as pushState gets more usage IRL.

[Foxandxss]

Well, I am a little bit confused of how our pushState works. If we have an angular app with doesn't use pushState, will still everything works? If so, leave it on. If it only works (or makes sense) when our angular app is using pushState, disable it.

So far we always used the angular-template as the seed project which comes with pushState (at the client) enabled so it always made sense to have it enabled in lineman.

I am of the opinion that we should rename lineman-angular-template to lineman-angular-example because with all the work you did on the plugin system, we should encourage creating new angular projects from the base lineman and then adding the lineman-plugin than cloning the template and removing all the examples.

What is left from the template is protractor, having a protractor plugin we could just plug the needed plugins to a base lineman project.

Errr, yeah, disable it if it only makes sense for a pushState angular app but leave it if that doesn't matter.

[jasonkarns]

pushState and apiProxy conflict with one another. That's why they are
usually both disabled by default in core. With both off by default, naively
enabling/uncommenting just one or the other doesn't cause a problem. The
prefix property for apiProxy is necessary to resolve the conflict if both
are enabled.

[searls]

I agree with Jason. I'm inclined to shut off the html5PushState in the plugin. We'd have to toggle it on in the template project to keep that working.