[Dataset Quality] Migrate Dataset Quality Flyout to a Dedicated Page

[achyutjhunjhunwala]

📓 Summary

The Dataset Quality currently offers a Flyout which displays quite some data about specific DataStream.
Goal of this ticket is to migrate this Flyout into a Dedicated Page. This would help us to add more features especially to another flyout for the Fiy It flow to the Degraded Fields.

Designs

Figma Link

Technical Tasks

1. The page would live on a sub-route of Stack management > Data > Data Quality
2. The page should respect the Time Range selected in the DataSet Quality Page.
3. The state machines must be split to support this.
4. A New URL state would be required. This means appropriate URL Schemes would require updates.
5. Update all Tests (Functional, API and Integration) if available

Nice to have

• Create a controller for the page content to be able to instantiated from outside dataset-quality plugin, this will allow us to reuse the page in places like Datastreams > Quality or Docs flyout > Quality

[elasticmachine]

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

[gbamparop]

@achyutjhunjhunwala is this a prereq for https://github.com/elastic/observability-dev/issues/3232?

[achyutjhunjhunwala]

@achyutjhunjhunwala is this a prereq for https://github.com/elastic/observability-dev/issues/3232?

Yes

[isaclfreire]

Issue updated with the latest Figma link + latest screenshots

[yngrdyn]

I've been trying to play around with this idea, basically we have a plugin that needs to be consumed from others.

Consumers have different needs in relation to dataset quality plugin offering

there are two generalist solutions:

Decouple components

Since the components could be individually included in different parts of the platforms, e.g. DataQuality Plugin vs UnifiedDocViewer, it seems more natural to keep the components as standalone components, not generating dependencies between them. In this sense we could have DatasetQualityPlugin exporting these two different components and others plugin consuming/initialising just what they need.

This require multiple changes:

1. Dedicated controllers. A consumer would need to initialise as many controllers as standalone components they are consuming. This will help keeping states contained and consumers could subscribe to individual state changes and manage the changes as they please in their contexts, e.g. syncing with URL services.
2. Dedicated public types. The components will be independent and it’s likely that the internal states differ from one another. e.g keeping the filters for Main components vs knowing which fix it flow is active in Dataset details.
3. Dedicated wrapper components. These are the components that set the context for the individual components, e.g. setting the needed providers for each case.
4. Dedicated state machines. As of now we only have a big machine handling our main component + dataset details (through the flyout), splitting the components would also mean factor out the flyout logic to a new machine that will handle specific flows for the details, e.g changes in the degradedDocs table.

The DataQuality consumer would also need to keep pace with the changes:

1. New route and URL schema for dataset details (?). Maintaining both states in the same URL schema could be challenging and confusing. In any case, if we decide to go this route we need to make sure we create a new version for the routes so old versions still work.
2. Initialisation of the new controller and subscription to state changes.

Keep components together

This could be achieved extending the current controller, but while trying to replay it in my head it became very confusing very quickly, for doing this we would need to either extend the current public state or transformed into a big wrapper where you can define Main state, dataset details state or both. I find this very confusing from the consumer side, also since we are not in version 4.7+ (adhoc spawning actors) regarding xState the implementation will became messy as well, basically we would still need to decouple both big components from our current state machine, but we would need to initialise both of them using the same controller. The main problem with it is that there is no clear mechanism to do that, we would need to treat machines following parent/child relationship which will implicate one of the machines (parent) will be waiting until the second one finished (child), also communication will flow only in that direction parent -> child.

Let's imagine a practical case: unified doc viewer. This consumer would need to initialise a controller with a big state in which mostly of the properties will be undefined, this consumer is not interested in the main component only the dataset details. What if this consumer sets properties outside dataset details piece of state? Maybe nothing will happen or maybe it will get into undesired effects (depending on the implementation).

Conclusion

As far as I see it, our cleanest option is to decouple components. Disadvantages I see, when a consumer needs a 1:1 relationship between all the components offered and needed, they will need to initialise all of them and take care of the status changes, but at the same time this brings flexibility to them to control and decide what to do with each piece of the puzzle.

WDYT?