frontend: overhaul validator dashboard fetching logic #1166
Conversation
Deploying beaconchain with
|
| Latest commit: |
60fe37d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2d4474df.beaconchain.pages.dev |
| Branch Preview URL: | https://beds-914-better-dashboard-fe.beaconchain.pages.dev |
LuccaBitfly
force-pushed
the
BEDS-914/better-dashboard-fetching
branch
from
3cbdf1c
to
cab1b5d
Compare
LuccaBitfly
changed the title
LuccaBitfly
force-pushed
the
BEDS-914/better-dashboard-fetching
branch
4 times, most recently
from
190d26c
to
ce80077
Compare
There was a problem hiding this comment.
np:
🤔 if this composable would ever only be used inside one component this might be the wrong abstraction or this might not be pulled out of the component
There was a problem hiding this comment.
I think it makes sense to at least put the fetching logic outside of the component (e.g. a service file), as to not clutter the index component with too much code. I.e. inside the component, the only concern should be what you fetch and not how you fetch it. As we have no pattern for services right now, I'm opting to extract them into composables. Is that an antipattern?
There was a problem hiding this comment.
not an anti-pattern per se, but what you tell the world is:
- here is a
composableplz feel free to implement me wherever you want - I would come in handy in other
contextsas well
| headers: {}, | ||
| query, | ||
| }, | ||
| { dashboardKey: dashboardKey || 'MQ' }, // If guest dashboard has no validators yet (= empty dashboardKey), load small guest dashboard with 1 validator (MQ) |
There was a problem hiding this comment.
this one is nice 👌
As it gives more context and explains the why
There was a problem hiding this comment.
is this what should happen though? (loading validator index 1 if empty?)
There was a problem hiding this comment.
Yes, the goal is to load a very small slot viz and remove the validator information. This is hacky, but the only way to achieve an empty guest dashboard slot viz currently.
| // Helper: Handle errors | ||
| function handleError(e: any) { | ||
| if (e?.statusCode === 404) { | ||
| // TODO: redirect to 404 page |
There was a problem hiding this comment.
why 404 page exists?
| // Helper: fetches all data for the dashboard (overview, slot viz, active table) | ||
| function fetchAllData() { | ||
| if (dashboardKey.value) { // valid dashboard key -> fetch all data | ||
| return Promise.all([ |
There was a problem hiding this comment.
plz think about Promise.allSettled instead: https://dev.to/viclafouch/promise-allsettled-vs-promise-all-in-javascript-4mle
proper error handling would be nice (but I guess is still wip)
| @@ -116,7 +116,7 @@ const addGroup = async () => { | |||
| }, | |||
| { dashboardKey: dashboardKey.value }, | |||
| ) | |||
| await refreshOverview(dashboardKey.value) | |||
| emit('updateAll') | |||
There was a problem hiding this comment.
why is the DashboardGroupManagementModal component emitting a update-all event?
How does this component know about things like all?
There was a problem hiding this comment.
Something like modified-dashboard would prob be better naming, will change.
| 'validator_dashboard_store', | ||
| () => { | ||
| const { t: $t } = useTranslation() | ||
| // TODO: bring ID in here and remove the provider composable!! |
There was a problem hiding this comment.
❤️ love this -> #promotioncantidate
LuccaBitfly
force-pushed
the
BEDS-914/better-dashboard-fetching
branch
2 times, most recently
from
3acad26
to
45e540d
Compare
- Overview and SlotViz data is now fetched in `index.vue` and propped down - SlotViz updates are handled through update emits - Introduces proper SSR fetching - removes all direct sibling dependencies on the overview (including the dashboard group composable) - introduces new validator dashboard store - dashboard modyfing actions now emit an `updateAll` event instead of directly calling `refreshOverview` See: BEDS-914
LuccaBitfly
force-pushed
the
BEDS-914/better-dashboard-fetching
branch
from
45e540d
to
60fe37d
Compare
In the current validator dashboard fetching flow, components will either fetch their own data by reacting to changes in other unrelated components or manually trigger refreshes in unrelated components, making tracing bugs a hassle.
This PR aims to bring back order by making sure that most data fetching happens in the dashboards root component and that these are only triggered through emits. As a consequence of removing sibling component data dependencies, most of the dashboards Pinia stores won't be necessary anymore.