Skip to content

Conversation

@ohassine
Copy link
Member

@ohassine ohassine commented Jan 27, 2026

https://wearezeta.atlassian.net/browse/WPB-21606


PR Submission Checklist for internal contributors

  • The PR Title

    • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
    • contains a reference JIRA issue number like SQPIT-764
    • answers the question: If merged, this PR will: ... ³
  • The PR Description

    • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

What's new in this PR?

Issues

Sort tags by alphabetical order

Needs releases with:

  • GitHub link to other pull request

Testing

Test Coverage (Optional)

  • I have added automated test to this contribution

How to Test

Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.

Notes (Optional)

Specify here any other facts that you think are important for this issue.

Attachments (Optional)

Attachments like images, videos, etc. (drag and drop in the text box)


PR Post Submission Checklist for internal contributors (Optional)

  • Wire's Github Workflow has automatically linked the PR to a JIRA issue

PR Post Merge Checklist for internal contributors

  • If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

References
  1. https://sparkbox.com/foundry/semantic_commit_messages
  2. https://github.com/wireapp/.github#usage
  3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

@codecov
Copy link

codecov bot commented Jan 27, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 48.50%. Comparing base (d5ef236) to head (9faa595).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #4549   +/-   ##
========================================
  Coverage    48.50%   48.50%           
========================================
  Files          575      575           
  Lines        19810    19810           
  Branches      3311     3311           
========================================
  Hits          9609     9609           
  Misses        9187     9187           
  Partials      1014     1014           
Files with missing lines Coverage Δ
...id/feature/cells/ui/tags/AddRemoveTagsViewModel.kt 96.15% <100.00%> (ø)

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d5ef236...9faa595. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ohassine ohassine requested a review from saleniuk January 28, 2026 10:47
viewModelScope.launch {
getAllTagsUseCase().onSuccess { tags ->
_state.update { it.copy(allTags = tags) }
_state.update { it.copy(allTags = tags.toList().sorted()) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Does it makes sense to return the sorted tags from the use case already ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We changed the return type in the usecase to avoid duplicated tags
https://github.com/wireapp/kalium/pull/3572/changes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is no need to call "toList().sorted()". "sorted()" should just be enough.

viewModelScope.launch {
getAllTagsUseCase().onSuccess { tags ->
_state.update { it.copy(allTags = tags) }
_state.update { it.copy(allTags = tags.toList().sorted()) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is no need to call "toList().sorted()". "sorted()" should just be enough.

val addedTags: Set<String> = emptySet(),
val suggestedTags: Set<String> = emptySet(),
val allTags: Set<String> = emptySet(),
val allTags: List<String> = emptyList(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to keep set here? All tag collections (added, suggested) are defined as Set, I think we should keep this for allTags as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default, a Set does not preserve the order of its elements

@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants