Hey everyone who is watching! How do you like the extended introduction I just wrote?
The request ecosystem gets more diverse as we speak:
request-promise joined in and gets its place in the documentationrequest@next will become highly configurable – especially considering the Basic API and the Chain API it will provide- And
request already provides two very distinct ways of using it: callbacks and streams
This all leaves us with a rather significant issue: New users must make some choices about how they want to use request.
IMHO the best way to break it down is:
- How do I want to configure the request?
- Via an options object (only option today, Basic API in the furture)
- Via chaining (Chain API in the future)
- How do I want to handle the response?
- Via a callback
- Via a promise
- Via a stream
Since (1.) only becomes a choice to make once request@next is ready I wrote the new introduction showing a little about the options and then helping to decide whether to use callbacks/promises/streams.
Accordingly, I would structure the rest of the documentation in a way that the available options get its own chapter – because they apply equally to callbacks/promises/streams – and then a chapter for each of callbacks/promises/streams.
Let me know what you think before I proceed. Thanks!
Hey everyone who is watching! How do you like the extended introduction I just wrote?
The request ecosystem gets more diverse as we speak:
request-promisejoined in and gets its place in the documentationrequest@nextwill become highly configurable – especially considering the Basic API and the Chain API it will providerequestalready provides two very distinct ways of using it: callbacks and streamsThis all leaves us with a rather significant issue: New users must make some choices about how they want to use request.
IMHO the best way to break it down is:
Since (1.) only becomes a choice to make once
request@nextis ready I wrote the new introduction showing a little about the options and then helping to decide whether to use callbacks/promises/streams.Accordingly, I would structure the rest of the documentation in a way that the available options get its own chapter – because they apply equally to callbacks/promises/streams – and then a chapter for each of callbacks/promises/streams.
Let me know what you think before I proceed. Thanks!