feat: implement new version of word cloud

[villebro]

SUMMARY

This is a new attempt at bumping Word Cloud to the newest version which was attempted in #9908 . This adds both cypress and jest tests to make sure chart calls initiated from the dashboard contain the property queryFields and that the field is dynamically created based on the current control panel state which might change over time.

TEST PLAN

Local testing + CI

ADDITIONAL INFORMATION

• Has associated issue:
• Changes UI
• Requires DB Migration.
• Confirm DB Migration upgrade and downgrade tested.
• Introduces new feature or API
• Removes existing feature or API

[codecov-commenter]

Codecov Report

Merging #9962 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #9962      +/-   ##
==========================================
+ Coverage   71.35%   71.37%   +0.01%     
==========================================
  Files         585      585              
  Lines       30913    30914       +1     
  Branches     3246     3246              
==========================================
+ Hits        22059    22064       +5     
+ Misses       8744     8741       -3     
+ Partials      110      109       -1     

Flag	Coverage Δ
#cypress	54.10% <100.00%> (+0.07%)	⬆️
#javascript	59.39% <100.00%> (+<0.01%)	⬆️
#python	71.54% <ø> (ø)

Impacted Files	Coverage Δ
superset-frontend/src/explore/controls.jsx	80.95% <ø> (ø)
superset-frontend/src/explore/controlUtils.js	96.90% <100.00%> (-0.04%)	⬇️
superset-frontend/src/explore/store.js	92.85% <100.00%> (+0.54%)	⬆️
superset-frontend/src/SqlLab/actions/sqlLab.js	66.81% <0.00%> (+0.65%)	⬆️
.../src/dashboard/components/gridComponents/Chart.jsx	89.88% <0.00%> (+1.12%)	⬆️

---

Continue to review full report at Codecov.

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

[villebro]

I tried to rename this file to formData.js, but a recently added linting rule preferring TypeScript threw a weird exception that I didn't have time to debug now.

[etr2460]

did you get a screenshot of the exception? It's supposed to post a comment but not block merge if a new js file is added, maybe i missed something though?

[villebro]

@etr2460 I don't think it was throwing a normal comment, it looked more like it borked somehow. Let me redo the rename so we can get a screenshot.

[villebro]

Here it is:

[etr2460]

yikes... so one of the actions the workflow was depending on didn't work :( it doesn't block the PR merge though, right?

[etr2460]

looks like someone else reported this as well (2 hours ago) trilom/file-changes-action#100. I'll wait a few days to see if it gets resolved, otherwise, i can remove the workflow and try to fix it since it's not required to pass

[villebro]

Oh good to know it's a known bug. I can do the rename in a separate PR if we want to debug this further, but for now I'll leave the rename out of this PR.

[villebro]

Ping @suddjian @nytai

[rusackas]

LGTM!

[ktmud]

Hi @villebro @rusackas , I was migrating table chart to use the new API. The more I look at it, the more I feel there shouldn't be the need to include this queryFields mapping to formData.

The information about field mapping is at the visualization type level, and isn't a variable per visualization. formData will be stored in database and passed around in the URL and the URL is already a mess, we should keep it as simple as possible.

There is already a buildQuery hook for visualization plugins, maybe that's a better place for this type of custom mapping logics?

[villebro]

@ktmud My original idea behind adding the queryFields mapping was to make it as simple as possible to create viz plugins, and avoid the need to use the buildQuery hook unless post transforms would be required. Another thought behind it was to make it possible to transfer state between controls when switching chart types (selections from metric and secondary_metric flowing into metrics and vice versa). However, I've also started having similar thoughts, as buildQuery is very simple to construct, and I suspect doing some form of tweaking will be required in practically all viz'. I agree that having queryFields convolute formData that is persisted in the metadata is not a good thing, so in the interest of keeping it as lean as possible I'm all for removing it.