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

fix(Dashboard): Color inconsistency on refreshes and conflicts #27439

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

geido
Copy link
Member

@geido geido commented Mar 8, 2024

SUMMARY

After the changes in this PR #23762 color inconsistency on refreshes was reintroduced.

Fixes #16970
Fixes #26456
Fixes #28104
Fixes #25384 (specifically for metrics changing colors on refreshes. An additional fix is required for charts emitting only COUNT(*) as label and not specific ones)

This PR does the following:

  • Fixes color inconsistency on refreshes
  • Fixes color inconsistency from chart in hidden tab to Explore
  • It helps avoiding color collisions by adding a usage tracker of the colors at the chart level
  • Deprecates AVOID_COLORS_COLLISION feature flag
  • Renames the shared labels color map to LabelColorsMap
  • Centralizes the logics of generating the colors map and color metadata

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N.A.

TESTING INSTRUCTIONS

  1. Set a color scheme for a dashboard
  2. Refresh the dashboard
  3. Colors should not change
  4. Going from any chart in any tab to Explore, should carry the same colors forward

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

@geido geido changed the title fix: Color inconsistency on refreshes and conflicts fix(Dashboard): Color inconsistency on refreshes and conflicts Mar 8, 2024
Copy link

codecov bot commented Mar 8, 2024

Codecov Report

Attention: Patch coverage is 78.66667% with 16 lines in your changes are missing coverage. Please review.

Project coverage is 67.34%. Comparing base (f453d5d) to head (36795f2).
Report is 22 commits behind head on master.

Files Patch % Lines
...d/src/dashboard/components/gridComponents/Tabs.jsx 9.09% 10 Missing ⚠️
...rc/explore/components/ExploreChartHeader/index.jsx 60.00% 3 Missing and 1 partial ⚠️
...frontend/src/dashboard/components/Header/index.jsx 50.00% 0 Missing and 1 partial ⚠️
...src/dashboard/components/PropertiesModal/index.tsx 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master   #27439      +/-   ##
==========================================
- Coverage   69.61%   67.34%   -2.28%     
==========================================
  Files        1908     1909       +1     
  Lines       74543    74649     +106     
  Branches     8316     8330      +14     
==========================================
- Hits        51895    50272    -1623     
- Misses      20595    22321    +1726     
- Partials     2053     2056       +3     
Flag Coverage Δ
javascript 57.20% <78.66%> (-0.06%) ⬇️
mysql 78.00% <ø> (-0.01%) ⬇️
postgres 78.10% <ø> (-0.01%) ⬇️
python 78.23% <ø> (-4.65%) ⬇️
sqlite 77.61% <ø> (-0.01%) ⬇️
unit ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -84,6 +84,7 @@ These features flags currently default to True and **will be removed in a future

[//]: # "PLEASE KEEP THE LIST SORTED ALPHABETICALLY"

- AVOID_COLORS_COLLISION
Copy link
Member

Choose a reason for hiding this comment

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

We might technically need to get consensus on this. @michael-s-molina any problems getting consensus and doing this now, or should we wait until the 5.0 proposals open up?

Copy link
Member

Choose a reason for hiding this comment

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

I think waiting for 5.0 would be a good idea as it allows an orderly evaluation of proposed deprecations. We just need to add a card to the board to remind us to submit the proposal.

Copy link
Member Author

Choose a reason for hiding this comment

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

@michael-s-molina @rusackas this feature flag introduced a regression, so I don't think it makes sense to discuss depreciation. I am keeping it here and not deleting it for now just because we don't have a breaking window open. Thoughts?

@villebro
Copy link
Member

villebro commented Mar 8, 2024

@geido would it be possible to add a brief description of the mechanics of the changes in this PR? This would help grasp the chosen approach without having to dive directly into the diff.

* @param currentColor
* @returns the least used color that is not the excluded color
*/
getNextAvailableColor(currentColor: string) {
Copy link
Member Author

Choose a reason for hiding this comment

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

This is meant to help with color collisions. It orders the colors based on their usage count in the chart. Least used colors will be preferred. This does not guarantee full protection against color collisions, which should be implemented at the individual viz based on their shape.

@@ -256,10 +264,51 @@ export class Tabs extends React.PureComponent {
}
};

// the initial color map is generated on save and catches all rendered charts
Copy link
Member Author

@geido geido Mar 8, 2024

Choose a reason for hiding this comment

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

Currently the initial color map is stored in the dashboard metadata at save but fails to map colors of charts that are hidden within tabs as those are not rendered. This checks for new colors popping in the color map that are not stored in metadata yet when a tab and its charts are rendered. It then updates the metadata accordingly. The stored color map is then used by the viz in Explore to respect the colors of the dashboard context.

@geido
Copy link
Member Author

geido commented Mar 8, 2024

@geido would it be possible to add a brief description of the mechanics of the changes in this PR? This would help grasp the chosen approach without having to dive directly into the diff.

@villebro this is meant to fix the regression introduced in #23762 so there is not much more context to add. However, I added inline/GitHub comments to the parts of the code that I think introduce new behaviours or that might require clarifications.

@geido
Copy link
Member Author

geido commented Mar 11, 2024

A few thoughts about the current state of the implementation and the way forward:

  • SharedLabelColorSingleton was meant to store only those labels that are shared across multiple charts. However, that is not the case since this is used to store all label colors independently if shared or not. This should get a better name, probably LabelColorsMap and change its references everywhere.
  • There are multiple places that are storing the color map in the dashboard metadata, including saving the properties and clicking on tabs (as of the changes in this PR), on verifyUpdateColorScheme and others. A larger refactoring work is required to coordinate and centralize changes to the metadata. For example, we might centralize updating the metadata when individual tabs load.
  • There are instances in which the underlying data of a chart might change and new labels show up or get removed. Currently, the implementation does not store those in the metadata as the saving process only happens when editing properties or when switching tabs. This requires a fix but it makes sense to apply it in the lenses of a larger refactor.
  • CategoricalColorScale and CategoricalColorNamespace, as well as SharedLabelColorSingleton should be refactored to improve the hierarchy and lower interdependencies. This PR attempts to improve on that but more refactoring work is required.
  • While this PR improves issues with color collisions by introducing a color count at the CategoricalColorScale level, specific logics should be implemented at the individual viz types as order and shapes affect collisions and there is hardly a solution that can account for all possible shapes.

CC @eschutho

@geido
Copy link
Member Author

geido commented Mar 11, 2024

/testenv up

Copy link
Contributor

@geido Ephemeral environment spinning up at http://35.86.251.170:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

@geido geido requested a review from kgabryje March 14, 2024 14:07
Copy link
Member

@betodealmeida betodealmeida left a comment

Choose a reason for hiding this comment

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

Looks good to me, and I really like your thoughts on moving forward — this seems very complicated as is today.

Copy link
Member

@kgabryje kgabryje left a comment

Choose a reason for hiding this comment

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

LGTM, sorry for the long delay after my first review!

@mistercrunch
Copy link
Member

Rebasing should fix the issues around required checks

@geido
Copy link
Member Author

geido commented Apr 16, 2024

Thanks everyone for the reviews. After some more thinking, I will continue with the refactoring work on this branch so that we can merge a stable/longer term solution to this problem.

@mistercrunch
Copy link
Member

I'd love to see a user-oriented FAQ entry "How do colors get assigned to my dashboard?"

@geido
Copy link
Member Author

geido commented May 15, 2024

/testenv up

Copy link
Contributor

@geido Ephemeral environment spinning up at http://34.219.194.7:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

@geido
Copy link
Member Author

geido commented May 28, 2024

/testenv up

Copy link
Contributor

@geido Ephemeral environment spinning up at http://54.202.10.57:8080. Credentials are admin/admin. Please allow several minutes for bootstrapping and startup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants