Thanks. I'd originally written up a wishlist of server-side functionality here, but at this point I'm thinking maybe I'll just do the sorting and filtering on the client, since this endpoint seems able to provide a superset of what I'm looking for. It's less efficient and definitely an evil hack, but it means not needing server-side code changes.
I'll note that filter: "SSC" doesn't work in the GraphiQL page; events that don't match the filter still get returned.
More generally, the way the API works now basically means that you can only ask for things that correspond to features of the lesswrong.com web client. In effect, the server-side implementations of those features are what you're exposing as the API. There's an additional problem with this besides it just being limiting: you're likely to want to change those features later, and you risk breaking third-party clients if you do. If you want to support those clients, maybe they should instead use a more general API for querying the database (although I'm not sure exactly how to implement that while maintaining security).
Ah, sorry. I made a small error in the query above. Here is the corrected one (I wrote "filter" instead of "filters"):
Also, two other questions:
It would be pretty trivial to implement individual prefilled options via the URL. Solving the problem generally though might turn out to be harder (i.e. generally allowing you to prefill forms based on URL parameters and available fields).
Time zones are currently all saved in the DB as UTC+0. So that's what your queries should translate to, though I haven't needed to test this extensively.
On a higher level: I think it would be more valuable to have a sidebar of nearby local groups instead of nearby events. Most groups don't get around to publishing all of their events on LessWrong, and while this is something I want to fix in the long-run, right now we only have a single upcoming SSC meetup listed, even though I know of many SSC groups that have weekly meetups and are listed.
Re: local events: Although I haven't checked this with Scott, my default assumption for the SSC sidebar is that keeping it free of clutter and noise is of the highest importance. As such, I'm only including individual events that a human actually took explicit action to advertise, to prevent the inclusion of "weekly" events from groups that have since flaked or died out.
(This is also why the displayed text only includes the date and Google-normalized location, to prevent users from defacing the sidebar with arbitrary text.)
LW proper may have different priorities. Might be worth considering design options here for indicating how active a group is.
Yeah, it would be great to somehow know how active a group is. Though it's definitely non-trivial to make that happen. Right now all groups were created in the last few months, so you know at least that if they are dead, they haven't been dead for long.
My model is that showing a group that is actually in the same city but might or might not be active is more important than showing far away events that are guaranteed to be real. In both cases the user will be disappointed, but I think your hit rate is going to be higher for the groups, since there are so many more of them, and most events don't get advertised. I don't think this means you have to show more clutter or anything, as long as you can get the user's rough location (via IP if necessary) you should be able to show nearby groups with nothing else but the location.
So correct me if I'm wrong here, but the way timezones seem to work is that, when creating an event, you specify a "local" time, then the app translates that time from whatever it thinks your browser's time zone is into UTC and saves it in the database. When somebody else views the event, the app translates the time in the database from UTC to whatever it thinks their browser's time zone is and displays that.
I suppose this will at least sometimes work okay in practice, but if somebody creates an event in a time zone other than the one they're in right now, it will be wrong, and if you're viewing an event in a different time zone from your own, it'll be unclear which time zone is meant. Also, Moment.js's guess as to the user's time zone is not always reliable.
I think the right way to handle this would be to use the Google Maps API to determine, from the event's location and the given local time, what time zone the event is in, and then to attach that time zone to the time stored in the database and display it explicitly on the page. Does this make sense?
Yep, that is how it works. This seemed to make the most sense for potential remote events, i.e. when people want to Skype into an event. I think it could totally make sense to instead display the time in the local timezone, but it's not obviously better to me and would require a bunch of engineering effort. But if someone else feels strongly about it, I would definitely merge a PR and help getting them set up with the codebase and everything to make that change happen. Also if enough people feel that the other way would be better, then I can get around to fixing it.
I do think that in general, focusing on listing events over groups was a mistake. When I get around to fixing our UI, I think the community page should feature groups a lot more prominently than events, which also mostly sidesteps this problem.
Taymon Beal was pinging us about some help with using the LessWrong API to construct a sidebar for SSC with upcoming meetups. I figured I would write up my response publicly so that other people might be able to learn from it.
As I understand the thing correctly (though Taymon can correct me in the comments) he wanted a way to query the API to get a list of all upcoming SSC meetups. This is the the GraphQL query that I would construct to make that happen (note to myself to fix the code embedding editor component):
You can also play around with this interactively on our GraphiQL page.
The "nearbyEvents" view right now requires you to specify a location, and returns all upcoming meetups (to any point in the future) ordered by their distance from that point. You can find the full definition of that view here.