Shorten pagination lists

[jamesbrewerdev]

Here's a screenshot from the demo homepage:

That's a bit of an eye sore.

A more visually appealing approach would be to show a max of 5 pages, plus a link to page 1 and a link to the last page.

Thoughts?

[EricSimons]

Lol yeah, Conduit's original frontend spec never planned for having to elegantly nav for thousands of blog posts :)

At this point it would be difficult to implement this across all the frontends — maybe we should have the public API only list a max of 20 pages of blogs? Obviously this is a bit hacky, but I don't think that it's worth adding scope onto any of the frontends for this specifically (esp because scope of frontends is already quite large)

[anishkny]

Lol yeah, Conduit's original frontend spec never planned for having to elegantly nav for thousands of blog posts :)

😃 i think that's what they call a "good problem to have"?

Alternately, you could specify something akin to an "extra credit" section in the API. So like various implementations can optionally choose to implement the extra credit stuff e.g. shorter pagination lists etc - but its perfectly acceptable if they don't.

But if it makes things too complicated and dilutes the message, then not worth it.

[EricSimons]

But if it makes things too complicated and dilutes the message, then not worth it.

Totally, totally agree with your sentiments here. And I love the idea of having "extra credit" specs!

[jamesbrewerdev]

I think this is a symptom of a larger problem. How do we decide what should be part of every realworld implementation?

When new things come up that should be in every implementation, how do we get that done?

It's a lot of work, but this is worth thinking about now. Otherwise we will have to think about it when there are 20+ implementations, instead of the ~10 there are now.

[EricSimons]

How do we decide what should be part of every realworld implementation?

Very carefully, on a case by case basis. @apai4 and I spent a lot of time (and iterations) creating the 1.0 spec and it has reliably stood the test of time against the 6 major frontend & backend frameworks. So right now we know that 1. the spec works (generally speaking) and 2. there are some warts that we need to deal with.

By default, we should seek solutions that avoid updating the spec unless it's blatantly obvious that the spec itself needs to be changed. Why? Because the cost associated with changing the spec is enormous; all frontend and backend implementations would have to be updated by hand. This is simply the nature of large software projects and those upgrade costs will not change, no matter what we do. And that's why @apai4 and I spent a considerable amount of time writing the spec, and the first implementations of it, ourselves :)

[EricSimons]

Additional thought: if/when we release a new spec, we should follow semver for this repo. That would allow "old" implementations to continue pointing at the old specs/API docs.

[jamesbrewerdev]

We're on the same page as far as implementation costs are concerned.

What I'm getting at is that the implementation cost should be considered separately from whether a feature is desirable. Implementation cost is better used to dictate priorities after a yes/no decision has been made for a specific feature.

Example:

Should the pagination list be shortened?

Does shortening the pagination list add value to the Realworld project? We all know that looks matter and that shorter pagination looks better. From a UX standpoint it's a solid yes. But do we want to optimize for UX? I don't know the answer to that.

From another perspective, I think this is a good thing for developers to know how to do. In particular, the algorithm for deciding which pages to show is non-trivial. It's not insanely difficult, but it's not a basic CRUD feature either. Does this learning opportunity add value or (as @anishkny mentioned) would it just distract from the overall point of Realworld?

What is the cost of adding this feature to each Realworld implementation?

If shortening the pagination list for every implementation is worthwhile (and it very well may not be), what is the cost of making this happen? It's definitely a lot of work. But how does the value of this work compare to the value of other work we could be doing?

---

The key thing to take away here is that the cost question is (in my opinion) irrelevant until the value question is answered.

TL;DR Does shortening the pagination list add value to the Realworld project? Discussion is always welcome, but we should come away with a binary Yes/No answer. If yes, then we can consider resources and prioritization separately. If no, then there is no work to be done and this ticket can be closed.

[EricSimons]

Got it. Maybe this will help:

The key value of RealWorld is the ability to pop open a brand new codebase you've never seen before, explore it, and walk away with a high level understanding of how it works within 10 minutes.

Any time we add to the spec we risk increasing every codebase's complexity, and thus risk failing on our 10 minute promise. And that's why we need to discuss every spec change very carefully, on a case by case basis.

(PS - lets take further discussion related to how we change specs into gitter.com/realworld/main as we're currently a bit off topic for this issue :)

[EricSimons]

Looping back to the main topic here, @apai4 what do you think? Think hiding pagination on prod is a reasonable solution here for the time being?

[apai4]

@EricSimons Yeah I think that makes sense. I don't think it's worth applying a change to all the codebases since this isn't something they'll run into often if they're running the entire stack locally.

[EricSimons]

This is now running in prod 👍