Introduce a new pattern to extract data handoff between the backend and frontend
Problem
There is a common practice in CDot views where ruby variables are prepared at the top of a view file, then later organized into a hash, passed to the frontend via data attributes. Here are some examples:
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1bbc5a161bc07335bf46c08b4b2364f3a73c8849/app/views/shared/customer/_edit.html.haml
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9aa9f695d0df918de5ad3697ba4f6321d8258eef/app/views/subscriptions/_add_more_seats.html.haml
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/85ea14e3a9977f351b8180a43370e6d92c45db05/app/views/subscriptions/index.html.haml
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ef343d6e5dff9230e22146f4f4514e3b4399ea8b/app/views/subscriptions/_new_ee_subscription.html.haml
This is problematic for a few reasons. In some complex cases, there are many of variables prepared just to be passed to the frontend, and this logic may not be well tested.
Proposal
Instead of following this pattern, it might be neat if this logic was extracted into a Ruby class that could be more easily tested. These classes could be in their own category/folder for "data_presenters" (probably a better name for it
Follow-up issue
The following discussion from !7282 should be addressed:
-
@tyleramos started a discussion: (+2 comments) Thought (non-blocking): This pattern of having variables defined at the top of a view, to then pass to the FE, isn't new to our app. Seeing this got me thinking about potential for refactoring in the future. Not sure what others think about it.
Instead of defining these variables at the top and then use in the data hash below, it would be cool if this logic/prep was extracted into a Ruby class that could be more easily tested. These classes could be in their own category/folder for "data_presenters" (probably a better name for it
😄 ). It might make these views much nicer simpler (e.g.#js-subscription-new{ data: NewSubscriptionDataPresenter.build(...)
).