Closed mmckegg closed 6 years ago
Hmm, decided to change this so that it doesn't affect any existing methods.
the various
isBlob
isFeed
, etc only detect the key itself, not the query. First parse withparseLink
then give to ref.type to find out what type of link has been parsed
Okay, I'm going to merge this.
This is much safer than last time as it doesn't affect any existing code. All it does now is add a new function parseLink
that handles parsing query strings on the end of ssb ref IDs.
Released as ssb-ref@2.11.0 🎉
Hopefully less 👻 this time 😆
@mmckegg :+1:
I was a little confused because it looked like parseLink accepts a feed/msg/blob id with a ?
then anything appended https://github.com/ssbc/ssb-ref/pull/16/files#diff-168726dbe96b3ce427e7fedce31bb0bcR5 ?
but then I saw it passes that to Querystring.parse https://github.com/ssbc/ssb-ref/blob/680ed76fea503a60a4dc549a42557456dafbf99f/index.js#L161-L170
hmm, I guess ?anything
is a valid query string with an empty value
am just wondering if this should be more restrictive, what shouldn't this permit? If we let something we don't want sneak in, we'll have to support it down the road if people start using it.
I hastily merged and published #15 as v2.10.0, but now I realise that @dominictarr was suggesting that we allow query on all ref types.
This PR adds support for handling query strings on all ref types, and adds a
parseLink
method which allows you to access this in the form of{link: "id...", query: {param: "value"}}
So I have unpublished 2.10.0 and submit this instead. The reason I unpublished is that this PR contains a breaking change to 2.10.0 where I'm using a generic
parseLink
instead ofparseBlob
.