By using a plain object, one does make it easy on the developer of the library to serialize whatever the user provides, but makes it difficult on the actual user of the library to know how to use it (one has to hit the docker documentation, instead of having typescript provide the necessary info).
Now, I can imagine an advantage of the object approach is that it will "future proof" against docker additions, where an interface wouldn't.
I think an interface can cover that though.
i.e. lets take container.create(). Instead of taking an optional opts object, it takes an optional opts interface, where the interface can be something like
Instead of just serializing GenericOpts into a json object (if it exists). we would so something like
const createObj = {}
if (opts.GenericOpts !== undefined) {
createObj = {...opts.GenericOpts};
}
if (opts.Image !== undefined) {
createObj.Image = opts.Image
}
// and so forth
while this is a bit verbose for the library writer, I think it would make the library much more usable for the user.
The only negative I can see is that if docker makes backwards incompatible chagnes to the API, but the user of the library is just as screwed then as thir existing code (i.e. how they define the ppts object), could just as easily break, and I'd argue much easier to provide proper bacwards compatability in the method I described.
By using a plain object, one does make it easy on the developer of the library to serialize whatever the user provides, but makes it difficult on the actual user of the library to know how to use it (one has to hit the docker documentation, instead of having typescript provide the necessary info).
Now, I can imagine an advantage of the object approach is that it will "future proof" against docker additions, where an interface wouldn't.
I think an interface can cover that though.
i.e. lets take container.create(). Instead of taking an optional opts object, it takes an optional opts interface, where the interface can be something like
Instead of just serializing GenericOpts into a json object (if it exists). we would so something like
while this is a bit verbose for the library writer, I think it would make the library much more usable for the user.
The only negative I can see is that if docker makes backwards incompatible chagnes to the API, but the user of the library is just as screwed then as thir existing code (i.e. how they define the ppts object), could just as easily break, and I'd argue much easier to provide proper bacwards compatability in the method I described.