Geo - Generalize Node Progress Bars
What/Why
Related to #219315 (closed)
Current Process
Example of below process: Frontend and Backend
Currently, when we add a new Replicable Type to the Geo frontend we have to manually add:
-
The following keys to the API for
new_type
new_type_replication_enabled
new_type_count
new_type_synced_count
new_type_failed_count
-
Create a new data mapped object in the
geo_nodes_store.js
fornew_type
new_type: {
enabled: rawNodeDetails.new_type_replication_enabled,
totalCount: rawNodeDetails.new_type_count || 0,
successCount: rawNodeDetails.new_type_synced_count || 0,
failureCount: rawNodeDetails.new_type_failed_count || 0,
},
- Create a new template mapped object in the
node_details_section_sync.vue
fornew_type
{
itemEnabled: this.nodeDetails.new_type.enabled,
itemTitle: s__('GeoNodes|New Type'),
itemValue: this.nodeDetails.new_type,
itemValueType: VALUE_TYPE.GRAPH,
detailsPath: `${this.node.url}admin/geo/replication/new_type`,
},
Proposal
This proposal will include backend changes followed up by frontend changes.
backend changes:
-
Add a generic way to generate the counts and enabled logic for each available replicable without the need for explicitly adding each data value.
-
Reorganize the data in a fashion that we no longer need to do step 2 above. What I mean by this is the API currently responds as one giant single level object. It doesn't create any data relationships between the related data.
For example instead of responding like this:
{
// ...
"lfs_objects_replication_enabled": true,
"lfs_objects_count": 5,
"lfs_objects_synced_count": 5,
"lfs_objects_failed_count": 0,
// ...
}
I would like to see if we could respond like this:
{
// ...
lfs: {
name: 'LFS Objects',
enabled: true,
total: 5,
synced: 5,
failed: 0
},
// ...
}
-
Add a user-friendly name (see above preferred response) for each data type in the response. We should have something similar to this being implemented as part of !35443 (merged) called
params[:plural_replicable_name]
-
This above mainly focuses on Syncs, but we should also need to consider doing this for Verification and Checksums as well.
-
There is also the question of transitioning this API to GraphQL as well.
frontend changes:
-
Remove the mapping methods for the Store and Component as the API should return the data already in the shape you expect it (see above).
-
Instead just loop through the response from the API and render directly and generically. Then moving forward, any new data added to the API will just flow into the frontend.