-
Notifications
You must be signed in to change notification settings - Fork 8
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
Introduce shorthand API #35
Comments
To design shorthand APIs, I think we'll need to answer the following questions:
I find this somewhat hard to decide on. Partially because I would likely prefer to use the lower-level APIs directly. |
I don't think that's a good idea. I think we should have equal support (either both shorthand or neither). |
Rather than being a separate method shorthand, this feels more like a config option. |
@getify thanks for chiming in. Given feels, it sounds like you have built intuition on how this could be solved, can we pick your brain on this? Feel free to drop further pointers and brain dumps here so we can iterate on this issue together. Thanks! |
I need to dig further into the API to give more of a authoritative suggestion, by my feel leans this way: lp2p.connect( /* ... */, { transport: lp2p.DATA_CHANNEL } ) What feels better about this option, even if it's "longer", is that config objects don't have to be specified inline at the call-site, whereas method names (or object property traversals) are sort of tied to the call-site (and thus kind of defeat the benefits of shorthand in the first place). Alternately: lp2p.connect( /* ... */, lp2p.DATA_CHANNEL ) |
Introduce a shorthand API for the most common case. This was previously discussed in #33.
The text was updated successfully, but these errors were encountered: