[UI v2] feat: Updates loader for concurrency limit route to include active task runs logic

[devinvillarosa]

1. Updates loader and data for concurrency limit route such that it includes the parent flow run and flow details. This is so it prefectches data to populate the upcoming active task runs UI

Checklist

• This pull request references any related issue by including "closes <link to issue>"
  • If no issue exists and your change is not a small fix, please create an issue first.
• If this pull request adds new functionality, it includes unit tests that cover the changes
• If this pull request removes docs files, it includes redirect settings in mint.json.
• If this pull request adds functions or classes, it includes helpful docstrings.

Relates to #15512

[desertaxle]

Do you think you could use some of the mock generators in this test to decrease the verbosity?

[devinvillarosa]

ya, I think we might be able to centralize some of these mocks to use faker (with options to ovrrride), similar to how some storybook stories does it.

Just need to centralize them in a place so its known to be re-used between storybook and vitest

[devinvillarosa]

Updated latest push to:

1. Centralize mocks using faker/js so they can be used between Storybook and Vitest
2. Replaces verbose mocks for mocks above

[desertaxle]

Looks like this is hitting our long-standing challenge of n+1 requests to the API. This handles the challenge well, but I'm a little concerned that all these calls are contained in one query, which is then used to suspend rendering until they've all been resolved.

There are a couple of things I'd like to explore:

1. Breaking these calls into separate queries and only suspending rendering for critical data (like the concurrency limit info). We can also investigate using deferred loading with @tanstack/router to continue using data loaders without blocking rendering.
2. Update the task run routes to include the flow run name to avoid needing to make another call for the flow runs filter route. I don't know how feasible this is since we'll need to take DB performance into account.

I'll do some exploration in the deployments list, but let's make sure we compare notes because we'll want a consistent approach to this in the application!

[devinvillarosa]

Sounds good. I can do some more exploration as well.

I opted for this route because the prefetching and loading mechanism comes out of the box. Also, it seems like this is more data critical stuff too

This way seems to give a faster UX because the data is loaded upon hovering over the Links

[devinvillarosa]

I think this video is a good explanation on the different options to sync data to the client: https://www.youtube.com/watch?v=AuHqwQsf64o&t=566s

Just need to determine how critical our data really is

[devinvillarosa]

Latest push uses the await/defer approach. I do see a bit better UX performance, but it feels minimal compared to throwing it all in useSuspense

[desertaxle]

This looks really great! Thanks for the exploration and finding the right levers to pull to balance fetching critical data vs. not blocking rending!