This week, I only have one new pull request for Steemit, Inc. to merge:
This one was particularly time consuming, partially due to the amount of reverse engineering it takes to track down that one field name in order to accurately document it. Sometimes, all I have to go while looking for a method argument is "What does the method argument look like?" (hint: not Marsellus Wallace). Ok, it looks like a timestamp. This object has five of them. So which one? It also depending on who you're talking to, steemd or hivemind.
Anyway, what this recipe does is explain the various forms of pagination solutions. I've grouped them by namespace, which should give the reader a pretty good idea of how they all should work, once you realize that methods in the same namespace work about the same (pretty much):
https://inertia186.github.io/devportal/tutorials-recipes/paginated-api-methods
But there are tiny/subtle differences, even within the same namespace (also depending on steemd or hivemind). Like how one method doesn't allow you to select an order and another method not only lets you select an order, but also a direction. Or how usually the limit is 1,000 objects but once in a while it's not. This is not a critique. Instead of just complaining about the subtle gotchas, I'm just documenting them.
For this reason, I've iterated each method and order type, which may seem like overkill. But I'm approaching this from the standpoint of someone who doesn't know the patterns (or thinks they already know the patterns). They only have one problem to solve from one method they want results from. In that situation, they're going to look for that specific method and not bother with learning the overarching pattern. Why should they? Especially if that pattern doesn't apply to all methods exactly the same.
Welcome to the Steem API. 😂
