Skip to content
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

Typed emission #114

Open
Stebalien opened this issue Aug 9, 2018 · 0 comments
Open

Typed emission #114

Stebalien opened this issue Aug 9, 2018 · 0 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature

Comments

@Stebalien
Copy link
Member

Stebalien commented Aug 9, 2018

Currently, the "response emitter" has a single Emit function that magically determines the right thing to do. Unfortunately, this is really magical:

  1. We have a special "single" wrapper to inform HTTP that we're emitting a single value.
  2. If the user "emits" a reader, we copy it as a stream of bytes.
  3. If the user emits normal values (not Single, we emit a stream of values).

This is getting better with the next iteration of the commands lib (this list used to include errors) but it could be improved.

Solutions:

  1. Have different command types. While the nicest from a type safety standpoint, this may not be the friendliest option.
  2. Apply a type-switch to the command's Run (and PostRun) functions. Personally, this is the one I'd vote for.

In the second case, we'd allow the following Run signatures:

// Writes a stream
type StreamFunc func(req *Request, resp io.Writer, env Environment) error

// Streams items
//
// We can keep this "magical" for now but eventually remove the magic and force users to use the other variants.
type EmitterFunc func(req *Request, resp ResponseEmitter, env Environment) error

// Sends a single item
type SingleFunc func(req *Request, env Environment) (interface{}, error)

Thoughts? This should make sending HTTP responses simpler and will likely improve user experience.

@Stebalien Stebalien added the kind/enhancement A net-new feature or improvement to an existing feature label Aug 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

1 participant