[FLINK-38699][ui] Sort jobs by default

[eemario]

What is the purpose of the change

This pull request updates the UI homepage to sort jobs by default: completed jobs are ordered by end time (newest first), and running jobs by start time (also newest first).

Brief change log

• Sort completed jobs by end time (newest first) and running jobs by start time (also newest first)

Verifying this change

This change can be verified as follows:

• Manually verified the change by running a standalone cluster and confirming the ui display.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
• The serializers: (no)
• The runtime per-record code paths (performance sensitive): (no)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
• The S3 file system connector: (no)

Documentation

• Does this pull request introduce a new feature? (no)
• If yes, how is the feature documented? (not applicable)

[flinkbot]

CI report:

• 6fcde26 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[davidradl]

can the this.listOfJob have completed and uncompleted jobs in if so how does the following if handle this?

[eemario]

this.listOfJob won't contain both completed and uncompleted jobs at the same time because we use separate JobListComponent instances for each state, marked by this.completed. And this.listOfJob is filtered to include only those JobsItem whose status matches this.completed.

[davidradl]

this makes sense. A couple of thoughs :

• if we are going to default jobs to a sort order ,then does it maker sense to additionally ask the server for a sorted list of completed and uncompleted jobs? So it comes back in the expected default order.
• does this have a big performance impact for a large number of jobs - if there is one this would be a good test to add. I assume we do not paginate.

[eemario]

Thanks @davidradl, these are really inspiring. I'd like to explain why I've opted to handle sorting on the frontend for now:

• Existing frontend capability: The UI already supports user-driven sorting (e.g., clicking column headers to toggle sort order). Adding a default sort order is a natural and lightweight extension of that logic. It also gives us the flexibility to apply different default sorting strategies for completed vs. running jobs without needing separate backend endpoints or complex query parameters.
• Performance considerations: Based on production observations, it’s quite rare for users to have more than a few hundred jobs at once. At that scale, client-side sorting is still performant and acceptable. If we do encounter scenarios with significantly larger job volumes that cause noticeable slowdowns, we can revisit the approach and consider optimizations (e.g., server-side sorting, pagination, or lazy loading). For now, I think we can keep things simple. What do you think?