Polka: Response helpers

[lukeed]

There are a few options here... 🤔

1. Add a standalone package that releases basic send, json, etc helpers

   send(res, code, data);
   

   This would mean removing app.send from the core server, which isn't too bad since it's only accessible if you define a app = polka() ahead of your route handler(s).

   A) Do we want to be explicit & require everything to be set?

   js send(res, code=200, data='', headers={}) { res.writeHead(code, headers); res.end(data || STATUS_CODES[code]); }

   B) Or do we want to infer Content-Type based on the data type (zeit/micro does this)?

   ```js
   const TYPE = 'Content-Type';
   const LENGTH = 'Content-Length';

   send(res, code=200, data='', headers={}) {
   let len, type=headers[TYPE];
   data = data || STATUS_CODES[code];
   // pseudo-code
   if (data instanceof Stream) {
   type = type || 'application/octet-stream';
   } else if (data instanceof Buffer) {
   len = data.length;
   type = type || 'application/octet-stream';
   } else if (typeof data === 'object') {
   data = JSON.stringify(data);
   len = data.length;
   type = 'application/json';
   } else {
   type = type || 'text/plain';
   len = data.length;
   }
   // update
   headers[TYPE] = type;
   headers[LENGTH] = len;
   // write
   res.writeHead(code, headers);
   res.end(data);
   }
   ```

2. Add a middleware package that attaches helpers directly to the res object?

   This would mimic Express, potentially offering all/most of them.

Please vote 🙏

Please know that all options would live as external packages and not inside Polka directly.

[Youngestdev]

I think the third option is okay i think as this will make it easy for those with express knowledge to build apps with polka.

[lukeed]

Thanks! My current idea is to do (1) first and then do (2) later, which would rely on (1).

That way people can choose the minimal route or the full-blown helpers.

Now trying to decide on A or B.

[icebob]

If you want to stay a minimal server, I think the A is better. And maybe you can create a middleware which implements the B logic.

[lukeed]

Thanks @icebob 😄 I updated the original post with a Poll, which is what I should have done from the beginning.

[sabrehagen]

My experience with Option 2 is that the json function is bound to the res instance and can't be passed to another context easily. This has caused my many res.json.bind(res) headaches in the past.

[lukeed]

@sabrehagen Understood, I've seen that too. The way this would work inside Polka is by attaching the middleware early or first. Then everything else that follows will have access to the same method(s).

This is because the loop mutates the request and response streams directly, so everything has access to the information that precedes it.

[terkelg]

I vote for B. It's still pretty simple. I always have to look up content-types anyway

[lukeed]

Same 😅 It feels sorta like, "Okay, how many are we gunna auto detect?" but then I think that this 4 are really good defaults, and can always be overridden inside the headers if need be.

[lukeed]

_UPDATE:_ I managed to get the polka organization on NPM! 🎉

This means I can start rolling out helper packages & _without_ making the same mistake I made with taskr, which was to release packages with the taskr-{name} at first, and then rename everything to @taskr/{name} later. Crisis averted!

[lukeed]

Okay, so first of all, thank you all for your feedback! 😃

I've decided to release sub-packages that you all can install _a la carte_, depending on your values and needs.

• Option 1A exists as @polka/send

• Option 1B exists as @polka/send-type

• Option 2 doesn't exist yet, but I'll open an issue to track it.

Thank you again for all your help! 🙏 I'm going to try and release a few more sub-packages before releasing everything as a 0.3.0.