nimblehq / rails-templates

Our optimized Rails templates used in our projects

Home Page:https://nimblehq.co

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Draft] Add an opinionated CRUD add-on

malparty opened this issue · comments

Why?

a. Provide a lot of value with less "addons compatibility issues"

The template starts to have many addons, but this brings new problems:

  • what add-ons depend on each other? How to prevent the user to select an incompatible config?
  • when updating an add-on, how to ensure the dependencies won't be broken?
  • testing complexity increases exponentially (the more add-ons, the more combinations of selected/unselected addons exist) and we cannot test all features for all combinations

This suggests we should NOT add too many add-ons. Instead, we can add a few add-ons that include a "pack" of features. This "pack" can be discussed and decided ahead to maximize the compatibility and allow project kick-off to be even faster! 🚀

b. Provide value even AFTER the project creation

The template helps us at the start of a project: It handles the first generic setup actions (scaffold the app, set authentication, CI/CD, wiki, ...).

However, it does NOT help us during the project because it is a one-shot scaffold.

Solution? What about including custom Rails Generators that would allow coding faster (and reduce the copy/paste of existing files).

If our projects include generators, future teams will also be able to maintain these generators so they fit with the specificities of the current project and keep providing value, even after the project deviates with the basic template configurations 🚀


Combining a. and b. would save us time DURING the project, not just at the start. But it would also remove the distraction as a team lead of having to decide about things we already decided so many times during the previous projects. For example:

  • When to set-up pagination? which of the 2 gem to use? (Pagy / Kaminari)
  • How should we name the resource helpers in ApplicationController? (authorized_ressources, paginatied_resources, ordered_resources, ...?)
  • Should these helpers be controller concerns, or small PORO?
  • What code conventions for the view? (slim or erb, single/double quote, setupt a formatter, ...?)
  • What test strategy to adopt for basic CRUD?
  • ...

So what?

We often need the same "CRUD" features. Most of our full-stack projects don't need to deviate from a pre-defined config. This config will need to be discussed and approved by teammates, but for example, it could be something like:

  • Bootstrap SCSS
  • Devise
  • Pundit (authorize and scope)
  • Discard
  • Pagy
  • Slim format
  • CRUD actions without the show action (edit serves as show)
  • Tests strategy for basic CRUD (see an example of Testing Scope)

Note
This issue is a draft to help me clarify my ideas and get feedback. I will progressively create issues for smaller increments toward this goal (e.g. create the addon, add soft delete, add discard, add pagination, add ApplicatonController helpers, ...)

TODO:

Warning most of these sub-features will come with their discussion to select the opinionated approach. There are tons of ways to implement each part. Our strength would reside in adopting a shared way and deciding once for all.

Setup Gems:

  • Pundit
  • Pagy
  • Discard

Add capabilities:

  • Controller - Searchable
  • Controller - Filterable
  • Controller - Orderable
  • Controller - Authorized resource
  • Model - Discardable
  • User model already setup (this also allow to have 1 first model to tests and demo all the CRUD features)

Enhance Generators:

  • Controllers (no show action, right implementation, request tests)
  • Pundit Policies with tests
  • Models (include Discardable module)
  • Views (remove show, add pagination, bootstrap base style, no item placeholders...)

Other features ideas:

  • Modal component with Turbo
  • Tooltip stimulus controller (or any other config that enable Bootstrap tooltip to work)
  • Form error messages inlined with inputs
  • Side-bar menu

Who Benefits?

Developers when starting a new project AND during the new resource scaffold.

Tests strategy for basic CRUD like https://github.com/onward-venture/flexi-payroll-web/wiki/Testing-Scope

@malparty We have no permission to see the repo, could you link to our backup repo instead?

Updated 👍