Put both show search and run search into the same route. This prevents
Lynx from thinking the search results were from a GET request and
caching the contents of the search page.
Implemented search across statuses and accounts. Replaced the old
search that was for accounts only and never quite worked right.
Don't load empty results when visiting the search page.
Implemented searching for accounts using the /accounts/search API
end-point. For some reason Guzzle consistently throws an exception,
so for now I've commented out the nav link to the search page.
Statuses don't always start/end with block elements, which can
cause them to join up with the previous or next lines of text.
I've wrapped them in a div to make sure they're properly separated.
Added an icon to show the visibility of a status (public, unlisted,
private, or direct). This goes next to the up arrow indicating
a reply, so this area can be used for other symbols regarding the
status' properties.
Created a new page to display account info. Just shows a link
to the user's home instance and their bio, plus indicators showing
whether the user is a bot and whether their account is locked.
Switched from using horizontal rules to divide articles to
making each article a list item. This is invisible to graphical
browsers, but makes identifying posts and reposts much easier
in text browsers.
I was re-using the same paths for a bunch of stuff in order to
minimise redirects (POSTing new statuses to the timeline, or performing
actions on a status), but then this breaks the behaviour of the
browser's refresh button. I've moved all those actions to their
own paths, which helps break up the code, makes the URLs more
semantic, and lets you use the refresh button without accidentally
performing an action.
This is at the expense of an additional HTTP request, but I've
tried to minimise the cost by passing through the status from the
previous action so we don't have to requery for it on the server
side.
Implemented a new page that shows a status context, though I'm
calling it a "thread" in the UI because I think that makes more
sense for users. Also moved the action element from the notification
into the event info component itself because I also want to use it
to indicate when a status is a reply.
Created a new page that displays notifications and added it to the
global nav. Abstracted out the pagination methods from the timeline
controller and put it in a helper class. Abstracted out the event info
(account, timestamp, etc.) into its own component.
Added navigation links to the top of the timeline pages.
Updated the HTML/CSS to be a bit more semantic (using article tags),
and replaced the broken tooltips with HTML title attributes.
Status routes were a bit of a mess and involved redirects,
which is only going to slow things down. I've amalgamated them
into one route and used query parameters to determine any actions
being performed.
St John Karp
Alexander Yakovlev