Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
chore: add typedefs #802
chore: add typedefs #802
Changes from 15 commits
26c40c8
7e05c4a
28b9f85
4b309ad
149c19a
d3d6b35
89fd524
2109ef0
32dd055
a5f5160
77a0257
55910c8
1992609
9b863bd
b221e97
9966c6c
aa98bc2
f568f16
ed2d10a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: In js-ipfs we settled on calling injected deps with
Config
suffix e.g. AutoRelayConfig`. Might be worth following same convention across both code bases.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably mentioning in the one below, right?
The current approach is:
xProperties
to libp2p references needed andxOptions
for user options, so that we can usexOptions
on the top level config docs. We can definitely changexOptions
toxConfig
and I would be happy in having a better name forxProperties
if you have any suggestionsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bo I was referring to
xProperties
actually, maybe I’ve misread the code, but it looked like dependencies injected intoAutoRelay
and we called such things withxConfig
e.g.:https://github.com/ipfs/js-ipfs/blob/530767d85d85b5932abdb87721e395c0a214b148/packages/ipfs-core/src/components/dag/get.js#L8-13
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to get a good way for here. So, in the libp2p stand point we have lots of places where we inject libp2p, or some libp2p components on other libp2p components. Moreover, these libp2p components have configurations that users can modify.
We need to differentiate between them. My initial approach was to make
ComponentNameProperties
for the libp2p components we provide, andComponentNameOptions
for user options. Naming config for dependencies that are not "configurable" does not seem the best naming to me. However, I am not totally happy withxProperties
, so if we can find a better convention would be greatThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe
AutoRelayComponents
then ?The reason I end up calling those config in js-ipfs is because it is configuration of the component. It is true that user can't modify those but who ever creates a component can provide alternative configuration e.g. in memory repo vs on disk repo etc...
Things that user can configure are referred as
PrefixOptions
.I don't have strong feeling about naming convention itself, just would love to settle on the same convention across ipfs and libp2p
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Components seems a good alternative. Will wait for other people to weight in before renaming everywhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think we should block this due to naming convention. Lets just have a separate discussion thread somewhere instead and we can always come back and rename things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I agree. But let's keep the discussion open until hugo/jacob comments