marrus-sh / laboratory Goto Github PK

Right now the handler for LaboratoryAuthorizationGranted needs localStorage in order to do its work. We're already relying on local variables with recalledOrigin; why not ditch the localStorage dependency and use local variables for everything?

Labelled a bug because localStorage wasn't supposed to be a dependency.

On one hand, authorization is stored in localStorage so there's no use in trying to hide it from other scripts. On the other hand, firing events (for Clients at least) seems overkill.

Sometimes valueOf gets called but you don't know that valueOf is getting called and a super sneaky demon has wriggled its way into the valueOf and now is running rampant inside your code. This is only an issue when dealing with semi-naïve privileged/non-privileged code boundaries but this is already what we have going on with Enumerals so.

Even just letting the notification store be flushed might be suitable enough, idk.

Having different failure events for each module doesn't make sense when they all do the exact same thing and you can check the module by looking at what the Failure is responding to. Bring them all under one tent as a "Failure" module even.

I don't know why we should be thinking about this I just wrote - Events dispatched from within handlers on my sticky note so think about it, idk

I mean for programmers mostly because this is an API and not like, a client after all. But it'd be cool if stuff was variables and not strings and hey if we're doing that why not make some of those variables overwritable.

I can't believe I just typed Linked Lists for timelines/rolodexes but it would make join() faster.

There are ECMAScript 6 ways to do this but ECMAScript 6 is for people who live in flowery meadows and love their lives. But yeah if I don't trust computers I don't trust users extra.

Right now Requests especially are guilty of this. Functions should be declared outside of constructors and then bound to their proper arguments inside. This may take a little work though.

It'd be cool if Requests had some form of progress monitoring at least to the extent of XMLHttpRequest.

Hmm. Just ponder it.

I mean it kinda makes sense but just to make sure nobody gets confused

right now it is very copypasta. make it less. #23 might help

I mean it would be great if we could just trust each other to get along but never trust computers amirite

In case #10 wasn't wild enough for you we can actually override hasInstance if we're not on IE. That's silly and weird but hey maybe if we're feeling rebellious

I don't like LaboratoryAuthorizationGranted. It feels bad. Part of this is due to OAuth being cumbersome to deal with in browsers. But maybe we can clean up the exterior a little.

To constructor pages at minimum, and maybe everywhere. I'm thinking a triumvirate of Usage, Examples, and Implementation here right now.

Especially if #27 happens a lot of events will be fired and gosh that will be a ton to wade through if we're not metering them and removing duplicates in an orderly fashion. This would be some little bit of trickery through dispatch() and probably requestAnimationFrame or setTimeout or who knows.

Of course, these aren't hard for people to write themselves, but a prototype method to make this easier might be useful.

Not sure if this should be done or not, but a "make unfollow" request might be useful. IDK if friend request confirmation can happen through the API but if it can that would be a plus too.

That's /api/v1/site. Should be a part of initial verification probably.

If the only one using the function is us, and we don't ever use the return, then the return really just takes up room now doesn't it. Think about that why don't ya

I mean, don't assume responses have anything.

It'd be great to have a Request.State enumeral with the values

STOPPED: 0
RUNNING: 1

so that you can do eg do request.stop if request.state

This could be as simple as passing an account parameter to a SetFollow() request instead of an id.
I mean, the API request would be different, of course.

Right now the requests for Post and whatnot kinda assume that any Post etc will have a compare function, but someone could hypothetically overwrite this value (why? don't ask me) with a non-function and then the code would break. Sad day.

Right now Laboratory.Client() takes this weird ambiguous params argument that isn't really documented. Do something about that.

This is probably not hard but who knows these days

idk how i feel about letting users just nuke their entire notification timelines but hey i guess its their feeds or whatever more power to them

If we're going to let extensions maybe create their own posts and accounts, then we should provide a mechanism for namespacing them in our Store so there aren't id conflicts. Obviously Symbols would work well for this but there might be a way to make it happen by registering Enumerals. Maybe in an array.

It'd be great if Laboratory.dispatch returned a numeric ID that could be verified against responses/errors. If we keep this all on our side then we can even guarantee uniqueness.

Post deletion is one of those things where you kinda really wanna know if it went through or not. Mastodon isn't the best about this but we can at least check for that empty-object-response or whatever.

Timelines and Rolodexes act like XMLHttpRequest() and they aren't designed to be shared, unlike most other Laboratory data. It would be better to have them return objects which are valid EventTargets if that is in any way possible, or spoof it somehow if it isn't.

all of these issues i'm writing should be documented in the code, yo

ECMAScript 2015 exports might not ever be supported due to how CoffeeScript interacts with them, but a CommonJS exports object might be feasible. Look into it.

Right now Request events are tied to XMLHttpRequest but maybe they should be tied to Requests instead; cf #43 and who knows if they should be dispatched on the document or just the individual requests tbh.

Right now code gets unreadable af on Github.com since it doesn't do line-wrapping.
Get it more verbose and spread it tf out.

Apparently there aren't just local/global timelines, but also local/global hashtag timelines. Look into this.

This should at least be mentioned somewhere apart from the forthcoming examples in 0.4

i think it is requesting a token when it doesn't have to tho

Maybe laboratory-style or something idk.

These can just be implemented as Timelines but at least implement them.
To go the extra mile provide advanced processing/linking in the Timeline constructor.

This means maybe n = Object(n) instead of n instanceof Object and who even knows what with Arrays my goodness. And then with all our magic constructors… idk. Think of something.

I actually don't know what the API gives us in terms of this. But at the very least it seems you should be able to do a follow-request rolodex, if that's helpful to anyone.

that's why god invented commas babe

The 0.4 Authorization.Request() is set up to handle this, the Store just isn't.

If you know that there isn't a LaboratoryOAuth window open, you should be able to opt out of closing it when you call LaboratoryAuthorizationGranted. Otherwise

do (window.open "about:blank", "LaboratoryOAuth").close

will open and close a window unnecessarily.

A lot of miscellaneous events have responses so link them up yo. You should be able to use Laboratory.request() with misc stuff too.

yeah yeah this isn't really necessary but writing "LaboratorySomeEvent" 50 bajillion times is boring and what if the event name changes and so on. It'd be cool if there was just a keyword that just always referred to the current event or whatever. You'd probably have to do some magic in dispatch to make this happen.