Support use of both Fragment Abuse plugins?

[JamesMGreene]

After noticing that you can't select both "Fragment Abuse" plugins on the Download Builder, I started to wonder why. The URI styles obviously contradict but do the code internals?

Brief Twitter conversation with @rodneyrehm would suggest that the API accessor methods conflict for these two plugins conflict. So, I guess at least one of the two plugins APIs would have to be altered in order to support both use cases with a single build of URI.js.

I'm in a situation where I am consuming 3rd party URIs w/ "fragment query strings" but parsing 1st party SPA "fragment paths"/"URL fragments".

Does this use case apply to anyone else? Other discussion points?

[rodneyrehm]

yes. The plugins are mutually exclusive due to their overloading the fragment accessor. Back when I built them, I wasn't sure what to accomplish with either of them except for showing how it's done. Looking both of them today, I would suggest we drop overloading the fragment accessor and add fragmentUri() and fragmentQuery().

What are your goals? How did you get to this question?

[JamesMGreene]

Like I said, I'm in a situation where I am consuming 3rd party URIs w/ "fragment query strings" (#?state=ugly) but also wanting to parse 1st party single page application "fragment paths"/"URL fragments" (#!/path/to/nowhere).

I would hope not many people get into this situation without it being caused by a 3rd party source... I guess it's possible that they could if they had multiple teams/devs not following a standard URI approach.

[rodneyrehm]

… yeah, you changed the issue while I was answering.

to "fix" the problem yourself, rename p.fragment to p.fragmentQuery on line 56 and remove the lines 42 - 43. Make sure to set the prefix accordingly, ! and ? only exist by convention…

[rodneyrehm]

Maybe URI.fragment is more like what you're looking for. While completely untested, it would return a URI instance for both #?foo=bar and #!/foo/bar. For the query part, you could go on using URI('#?foo=bar').fragment(true).query(true) - it would also update seamlessly

[JamesMGreene]

For the query part, you could go on using URI('#?foo=bar').fragment(true).query(true) - it would also update seamlessly

That's acceptable to me!

[rodneyrehm]

… there's still an infinite recursion bug in that gist… no time to figure things out right now… maybe I'll get to look at it tomorrow…

[JamesMGreene]

Not sure what gist you're referring to.

[rodneyrehm]

the URI.fragment duck punch thingie?

[JamesMGreene]

Oh, my bad, I thought you were referring to URI.fragmentURI.js. Didn't hover/click on the link to see it was a gist.

[rodneyrehm]

Resolved the issue. the gist should work now. use in place of fragmentURI and fragmentQuery. Tell me what you think.

I think it's small enough to have it merged into URI.js core and forget about both plugins completely.

[globis-ethz]

I'm not sure whether this is fully resolved:

URI('#hash?test=true').fragment().toString() === "hash?test=true" // CORRECT

URI('#hash?test=true').fragment(true).toString() === "ash?test=true" // WRONG? shouldn't it be same as above?

URI('#hash?test=true').fragment(true).query() === "test=true" // CORRECT

URI('#hash?test=true').fragment(true).path() === "ash" // WRONG: there should be no path.

URI('#!hash?test=true').fragment(true).path() === "hash" // CORRECT

[rodneyrehm]

besides there being a bug (first character missing if the ! was omitted) all output is expected. I fixed the gist to not drop the first character. The issue remaining is that ! is always prepended to fragment-URLs that are not query-strings.

so »WRONG? shouldn't it be same as above?« yes, this is the bug I just fixed. »WRONG: there should be no path.« no, this is expected.