-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use parseLink instead, and allow query on all refs #16
Conversation
the various `isBlob` `isFeed`, etc only detect the key itself, not the query. First parse with `parseLink` then give to ref.type to find out what type of link has been parsed This no longer changes the behavior of any existing method.
Hmm, decided to change this so that it doesn't affect any existing methods.
|
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 |
Released as ssb-ref@2.11.0 🎉 Hopefully less 👻 this time 😆 |
@mmckegg 👍 I was a little confused because it looked like parseLink accepts a feed/msg/blob id with a but then I saw it passes that to Querystring.parse Lines 161 to 170 in 680ed76
hmm, I guess |
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
.