Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ui option sort by newest does not work #942

Closed
jmcp opened this issue Dec 8, 2021 · 2 comments
Closed

ui option sort by newest does not work #942

jmcp opened this issue Dec 8, 2021 · 2 comments
Labels
bug Something isn't working good first issue Good for newcomers topic data Kafka Topic data

Comments

@jmcp
Copy link

jmcp commented Dec 8, 2021

I had a request from my userbase to make the default topic message sort option "sort by newest". I found the entry in the docs for akhq.ui-options.topic-data.sort and set that to NEWEST and applied the configuration - there was no difference in the behaviour.

I thought that making this change to RecordRepository.java would solve the problem, but it does not:

--- a/src/main/java/org/akhq/repositories/RecordRepository.java
+++ b/src/main/java/org/akhq/repositories/RecordRepository.java
@@ -1155,7 +1155,7 @@ public class RecordRepository extends AbstractRepository {
         private Long timestamp;

         public Options(Environment environment, String clusterId, String topic) {
-            this.sort = Sort.OLDEST;
+            this.sort = environment.getProperty("akhq.ui-options.topic-data.sort", Sort.class, Sort.OLDEST);
             //noinspection ConstantConditions
             this.size = environment.getProperty("akhq.topic-data.size", Integer.class, 50);
@sam0r040
Copy link
Contributor

We are using AKHQ quite a lot and I was always annoyed by AKHQ not changing the default sorting even if I configured
the default sorting to be NEWEST. After I found this issue I choose to dig a bit around to find out what's actually going on.

My observations are based on AKHQ 0.21.1, but the git history does not look like there has changed much in that area, so
I guess it's still the same behavior on dev.

I started with a simple test, to figure out if the setting the default sort via the configuration key is actually working.
In general, it's good to know that AKHQ uses local storage for ui state, because it's needed for a clean test setup.

Setup of my test:

  • docker-compose.yml from dev with version set to 0.21.0
  • make sure your local storage is empty for localhost:8080
  • akhq.ui-options.topic-data.sort is set to NEWEST
  • start AKHQ by running docker-compose up
  • create some test data that enables you to see if sorting is actually working
  • go to localhost:8080

AKHQ will automatically store the default ui options in local storage:

{"docker-kafka-server":{"topic":{},"topicData":{"sort":"NEWEST","dateTimeFormat":"RELATIVE"}}}

If you go to the application and view the messages for a topic, you can see that NEWEST is prefilled as the default sort option and the messages are sort correctly from newest to oldest.
If you go to the settings screen, you will also see that NEWEST is already set as the default sorting.

I also checked that this is also working the same way if you have multiple servers configured.

So far so good, it seems like it's actually working and I can not see that there is really a bug in the application.

However, there is behavior that could make it look like it is not working, especially if the configuration option was set
after the first use of the application.

If the installation did not so set akhq.ui-options.topic-data.sort and a user goes to AKHQ for the first time,
then the default will be OLDEST, but OLDEST will not be stored as default in local storage.
The ui option will not contain the sorting option and look like this:

{"docker-kafka-server":{"topic":{},"topicData":{"dateTimeFormat":"RELATIVE"}}}

There will be no change to the ui options unless the user selects one of the options on the settings screen.
Even if akhq.ui-options.topic-data.sort was set to NEWEST for the AKHQ installation later on, it will not change the
ui options unless the user selects one of the options on the settings screen (or delete the ui options in localstorage).

Emptying the cache and hard reloads will not help because it will not change the ui options in local storage.

Another thing that I noticed is, that the settings screen will neither display nor store the ui options in local storage
(unlike the topics screen for example). It will just be empty until you either visit another screen or manually select options
and click update. The actual default that are set are not visible there.

My suggestions for improvements would be:

  • change the behavior of the settings screen to match the other screen: store default configuration in local storage on first visit and show the defaults that have been set.
  • update the ui settings in local storage with the defaults from the backend if they have not been changed by the user already

I provided a PR #1161 for my first suggestion, for the second I'm unsure if this is the desired behavior because it would effectively always trigger a backend request to see if there is new configuration.

@tchiotludo
Copy link
Owner

close in #1161

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers topic data Kafka Topic data
Projects
Status: Done
Development

No branches or pull requests

3 participants