Document constructor options more formally #1294
Conversation
Mr0grog
force-pushed
the
docs/formal-constructor-docs
branch
2 times, most recently
from
33db356 to
9466884
Compare
This adds more descriptive and organized definitions for all the available options to the `IPFS` constructor as well as a full reference of events and the `start()` and `stop()` methods. License: MIT Signed-off-by: Rob Brackett <[email protected]>
Mr0grog
force-pushed
the
docs/formal-constructor-docs
branch
from
9466884 to
26633f3
Compare
There was a problem hiding this comment.
This is looking really good. Thank you so much @Mr0grog :)
It would be excellent to have a similar PR to https://github.com/ipfs/js-ipfs-api that separates set up from actually using the Core API
README.md
Outdated
|
|
||
| ### [Tutorials and Examples](/examples) | ||
| **Returns a promise** that resolves when the node is completely stopped. You can also pass a callback like `(error) => {...}` or listen for the `stop` event to determine when the node has stopped. |
There was a problem hiding this comment.
Returns a promise if no callback is passed
License: MIT Signed-off-by: Rob Brackett <[email protected]>
The FAQ repo has been deprecated, so remove the contribution section's link to it. Instead, link to discuss.ipfs.io and IRC at the end of the FAQ. License: MIT Signed-off-by: Rob Brackett <[email protected]>
|
LGTM, thanks @Mr0grog :) |
|
OK, if this is good, do you mind approving and merging, @diasdavid? |
|
@Mr0grog can we have an equivalent PR to js-ipfs-api? It would be good to have both in sync |
|
Maybe someone could use this as an example to start from? It took a pretty good chunk of my day to chase through all the code paths and feel confident I was explaining each thing accurately. I need to preserve some time to actually work on my main focus over in |
|
Thank you for your contribution, @Mr0grog ❤️ |
This adds more descriptive and organized definitions for all the available options to the
IPFSconstructor as well as a full reference of events and thestart()andstop()methods.Some open questions here:
I documented
start()andstop(), but wasn’t sure which of the other methods are consideredpublicthat we should document.I used
nodeto refer to theIPFSinstance throughout example code and in references for methods (startandstop). That matches the pre-existing usage examples. However, the core API reference usesipfs.xyz. I think we should make both the same for clarity.nodesounds slightly better to me, but I do not have a strong opinion.I don’t know enough to say more than what we already had about the
EXPERIMENTAL.dhtoption. Is there anything we can say about why someone might want to turn it on or off?I did not attempt to document all the
configoptions, but I added links directly to the two default config files. Is that OK for now?I noticed that the
libp2poption only supportsmodulesand, inside that, only supportstransportanddiscovery(notconnectionorDHT). You also can’t turn off any of the default transports or discovery mechanisms.src/core/config.jsso it can be validated?