1.0 Proposal - Please read & comment!

[draftbit]

1.0 Proposal - Please read & comment!

[peterpme]

@kokarn is there any reason you're not into typescript / flow? Microbundle automatically supports stripping types in prod so the only thing that is truly missing is the types themselves

@tylerbuchea ah good call bringing up streams! I think streams for the most part will have to live in their own domain. If we can utilize a makeRequest fn, lets go for it! If not, no point in forcing it to work 😄

[kokarn]

Mainly it's a bit of a roadblock to onboard new developers with no actual gain. Especially for such a small library.

I do have concerns that in time it will be the next coffeescript as well but that's more just personal preference.

[tylerbuchea]

Although it will create an extra hurdle for contributors, having Typescript and Flow support will greatly increase the attraction from consumers of this library who use those technologies and it will have no negative effect for those who do not.

Since we are developing a library here I think valuing the consumers above the contributors (within reason) is always a smart move.

[peterpme]

How do ya'll feel about making this a server-side only module for the time being? After reading a bunch about this, it seems like its a safer alternative than allowing requests to take place on the client

[tylerbuchea]

I'm commenting on this from the perspective of updating the stream method mostly. So here goes:

1. Turn all request arguments into keyword arguments - should be an easy change and makes sense to me 🙂
2. Return results, response, error from requests - Streams is kind of special case since we're returning the stream immediately, handling the fetch request in the method, and then the stream delivers any responses or errors. But we can discuss what and how the stream fires events and what those events return.
3. Error handling - I feel like letting the user handle these cases might be the way to go especially in a lite library. If we start doing error handling it could get pretty bulky. Maybe someone could make like a twitter-smart in the future that uses this lib as dependency.
4. makeRequest sounds nice, I'll have to think about it more and see if I can come up with anything that is sleek and functional.

Also 💯for Flow and/or Typescript I don't have much experience with either, but have been wanting to cut my teeth on it. If someone else is a pro please show us how 👍

[kokarn]

I agree with the focus on consumers ofc but how would Typescript or Flow increase the attraction?

Especially in the Node ecosystem having an unnecessary transpilation is a bit alienating to consumers and contributors alike.

In my experience neither TS or Flow actually lead to better libraries in the grand scheme of things either, it just moves problems to other parts. I do see the value with huge, complex libraries but this is nowhere near that.

I'd rather have a much more comprehensive test-suite and better documentation as a consumer.

With that said, I still think you should switch to TS & Flow simply because you feel motivated about it. As long as you don't feel it's something that will stop you from working on this say a year down the road.

[peterpme]

Great points!!

I work with Flow on a regular basis and would be happy to get everyone started with. Microbundle will strip flowtypes automatically so there's not much setup. Flow allows you to type as little as you'd like which makes it flexible.

[peterpme]

👋

Documentation is what will help make this library shine! I deleted my 1.0.0 PR because enough has changed since then.

When it comes to handling the client vs. server thing, we can also deliver a different file to different environments.

Alternatively, when defining the function, we can redefine the ones that don't work on a specific environment and throw an error, perhaps.

Interesting to see twit coming back alive. Sounds like thats happening because of us 😄

[kokarn]

Looks good. Will follow what's happening along this ticket.

One thing i'd like is to move the error object to the first parameter to be more node-ish.

[peterpme]

Hey @kokarn thanks for the feedback! I'll be returning an object:

{ error, results, response }

so technically the order doesn't matter 😄

[kokarn]

I'd rather you not go Flow and/or Typescript, but everything else sounds great.

[kokarn]

Shit, re-read your post now and realised you said: "who use those technologies".

I strongly disagree with the point that it has no negative side effect on those who don't. Having a library in a "language" your platform isn't in where you'll have a much bigger hurdle debugging is a huge issue for any consumer imo.

EDIT: Also leaving the previous post just for history because my final point still stands :)

[tylerbuchea]

Great arguments, I agree with you that we should move forward with TS & Flow ultimately.

I would love to get someone contributing to this repo that uses one or both type systems on the daily. They could help implement this faster and shed some light on the situation.

There are still a lot of things I'm ignorant on with those technologies.

[tylerbuchea]

I think that makes sense. Are you talking about implementing a check or just stating it's server-side only in the documentation?

[peterpme]

just stating it in the docs

[tylerbuchea]

Kew, I think that's best too.

[dandv]

A bit late to the game, but perhaps this will reignite conversation and get a new minor version out at least.

1. Request arguments into keyword arguments - agree, in the light of #15 (comment). Ideally, for drop-in compatibility with other modules, we might want to support calls with two parameters as well (endpoint and parameters).

2. makeRequest function - this library is tiny already; how many lines of code would factoring out the common code save? 10? Bundle size matters on the client way more than on the server, yet on the other hand we were pondering making this a server side only module. :)

3. sever-side only module - what would we gain by limiting where the module can be used? Now that ttezel resumed maintaining twit, we have one less differentiator (being actively maintained). twit doesn't work in the browers. We should.

4. "Return results, response, error from requests" - what happened to the changes from #17?

[tylerbuchea]

The only caveat being that event streams aren't supported in the browser so we'd have to conditionally require events and throw an error if you try and use the stream method in the browser.

Unless there is some way to interface with streams from the browser which would be ideal, but I don't think that there is.

[dandv]

Pinging everyone on this thread now that I've just released v0.9.0.

What still needs to be done before 1.0?

• makeRequest was implemented
• keyword parameters are no longer necessary, because both get and post only take 2 params
• the docs state that streams only work on the server

Returning result, response and error should still be discussed. Currently we're adding a _headers property to the response, but there might be better approaches.

[tylerbuchea]

For the docs state that streams only work on the server do we just need to update the docs to make the point that streams only work on the server?

I can take that on.

[dandv]

@tylerbuchea, that's already documented in the README. Did you mean you wanted to work on some sort of stream support in the browser?

[peterpme]

This could be ambitious, but typescript / flowtype definitions for those that want them. I'm a flow person, but if somebody here uses typescript, perhaps there's a way to output both.

[tylerbuchea]

@dandv I think I just got confused by your post "What still needs to be done before 1.0?" but then all the things you list are past/present tense. Maybe I missed some context, but either way, you can disregard my last comment.

For what it's worth I like @peterpme's idea of serving two different files. Like twitter-lite/node and twitter-lite/browser or something like that.

[dandv]

Alright, looks like this issue got too out of date and confusing, so let's close it and please feel free to create specific, more targeted issues for each of the remaining items!