You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Why?
a. Provide a lot of value with less "addons compatibility issues"
The template starts to have many addons, but this brings new problems:
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.
andb.
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:ApplicationController
? (authorized_ressources
,paginatied_resources
,ordered_resources
, ...?)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:
show
action (edit serves asshow
)TODO:
Setup Gems:
Add capabilities:
Enhance Generators:
show
action, right implementation, request tests)Discardable
module)Other features ideas:
Who Benefits?
Developers when starting a new project AND during the new resource scaffold.
The text was updated successfully, but these errors were encountered: