Feature/Browse Books #15
Conversation
| @@ -1,3 +1,6 @@ | |||
| Rails.application.routes.draw do | |||
| # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html | |||
| namespace :v1, format: :jsonapi do | |||
There was a problem hiding this comment.
This namespacing with v1 is one way to go about it.
An alternative will be to use custom content-types, have you used that before?
There was a problem hiding this comment.
Yes, you're talking about same route responding to both (for example) html and json, right?
There was a problem hiding this comment.
no, not really, in the context of jsonapi using links and versioning the api in routes might be tricky.
| @@ -0,0 +1,6 @@ | |||
| class V1::BooksController < ApplicationController | |||
| def index | |||
| @pagy, books = pagy(Book.all) | |||
There was a problem hiding this comment.
Marrying a framework will bite you down the line one way or the other. Do you know why / options to limit the impact?
There was a problem hiding this comment.
I don't exactly know what you mean. Can you be a little more specific, please? Is is the single line assignment or is it the way I declared the BooksController class?
There was a problem hiding this comment.
Let's imagine that your application grows over time. You end up at some point with pagy in all controllers. At some point, pagy is no longer supported / has some issues and we want to avoid using it. What do we do? We need to either modify all controllers or implement a pagy method on the application controller.
There was a problem hiding this comment.
Nothing to do, just wanted to make a point that dependencies should be as much as possible isolated and not propagated through the codebase.
There was a problem hiding this comment.
Totally right about that one. If more that one controller was needed, I would've definitely move it to application controller 👍
This PR does the following: