[dashboard] New, list view (react)

[nytai]

CATEGORY

Choose one

• Bug Fix
• Enhancement (new features, refinement)
• Refactor
• Add tests
• Build / Development Environment
• Documentation

SUMMARY

Replaces the current dashboard list view generated by FAB with one that is client rendered in react using the FAB/dashboard api. Design has tried to stay as close to the current design as possible, with some minor improvements. There have been recent efforts to redesign most of the views in superset, so having pages that are rendered in react will greatly facilitate those changes. The work in this PR is intended to lay the foundation for all list views that are to come.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

old view

new view

TEST PLAN

• The welcome page works as before.
• The dashboards page renders, sorts, and filters

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

REVIEWERS

[aboganas]

This is awesome, I hope this be ported to Flask-AppBuilder lists

[nytai]

so type errors don't cause jest tests to fail (they're still reported though)

[nytai]

the newest version of react-table doesn't have types in https://github.com/DefinitelyTyped/DefinitelyTyped

found these online and adjusted to for the features we're using.

[nytai]

We don't have these rules enabled in eslint and I found them to be very tedious. Opened #8865 for larger discussion

[nytai]

found I had to run superset init after adding this decorator. Not sure if there's a way around it. This is necessary to override FAB's default list view.

[dpgaspar]

One possible way could be to override with:

Class Dashboard(BaseSupersetView):
     class_permission_name = "DashboardModelView"
     method_permission_name = {
        "new": "add",
        "list_all": "list",
    }

Note: This would deprecate the Dashboard.new permission

[codecov-io]

Codecov Report

Merging #8845 into master will increase coverage by 0.47%.
The diff coverage is 80.56%.

@@            Coverage Diff             @@
##           master    #8845      +/-   ##
==========================================
+ Coverage   58.69%   59.16%   +0.47%     
==========================================
  Files         363      367       +4     
  Lines       11417    11679     +262     
  Branches     2801     2861      +60     
==========================================
+ Hits         6701     6910     +209     
- Misses       4538     4590      +52     
- Partials      178      179       +1

Impacted Files	Coverage Δ
superset/assets/src/welcome/App.jsx	0% <ø> (ø)	⬆️
...t/assets/src/views/dashboardList/DashboardList.tsx	58.94% <58.94%> (ø)
superset/assets/src/welcome/Welcome.jsx	78.57% <75%> (-1.43%)	⬇️
superset/assets/src/welcome/DashboardTable.jsx	75% <85.18%> (-2.78%)	⬇️
...perset/assets/src/components/ListView/ListView.tsx	91.17% <91.17%> (ø)
...assets/src/components/ListView/TableCollection.tsx	92.59% <92.59%> (ø)
superset/assets/src/components/ListView/utils.ts	98.14% <98.14%> (ø)
... and 1 more

---

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 ff9bc74...8262355. Read the comment docs.

[nytai]

@etr2460 @graceguo-supercat @michellethomas Would be great to get some 👀 on this from folks who spend more of their time in the frontend.

[dpgaspar]

Tested it locally and looks good, but noticed the following:

• when switching languages the user is redirected to the old dashboard list (previous MVC page)
• column labels are not translated
• Button labels are not translated
• Edit form back button does not work work properly (previous MVC), I would say that it's only usable when using modal forms form add and edit

[nytai]

@dpgaspar I've updated with the changes your requested as best I could.

when switching languages the user is redirected to the old dashboard list (previous MVC page)

looks like the user is redirected to the edit page of a specific dashboard, not sure how that's happening but doubt it's due to any change I made. Seems like that url is exposed in FAB and I don't really understand how that works right now.

column labels are not translated

I've updated the code to use the label_columns data provided by the backend. Looks like we're missing some translations there.

Button labels are not translated

I've updated the code to use the t('....') function from superset-ui/translation which seems to be the way of handling translations on the frontend. We're also likely missing most translations there.

Edit form back button does not work work properly (previous MVC), I would say that it's only usable when using modal forms form add and edit

This is true. looks like that links to /back which appears to be an endpoint in FAB? Somehow it's redirecting back to the charts list. Not sure how that works or how it's configured. -- There's work being done to move that functionality to a modal so that could be the workaround solution for that issue.

[mistercrunch]

I'm unclear about the pros/cons of using interface over propTypes, assuming this is more typescript-friendly (?). Tradeoff seems to be consistency vs being more ts friendly (?)

[nytai]

We could use both. PropTypes are checked at runtime by react in development and log to the console. Interface/types are checked by the typescript compiler/vscode and produce errors at build time and are highlighted in the editor. I'd say typescript is favorable once the entire repo converts to typescript as the types will be available in the editor (on hover, cmd click, etc). For now I'm happy to also add PropTypes until we transition more to typescript.

FWIW: The react dev team recommends flow/typescript over PropTypes for larger projects: https://reactjs.org/docs/static-type-checking.html

[mistercrunch]

t()

[mistercrunch]

Is this the same as setting state in the constructor?

[nytai]

Yes, they are essentially the same thing. The class properties is just sugar for setting variables in constructor. I personally prefer this over using the constructor as the constructor requires a call to super() which can sometimes be overlooked.

[mistercrunch]

Wondered why we haven't used this syntax before and found this:

[nytai]

I've added the babel plugin for transform-class-properties. The proposal for these is currently in stage 3, I believe, which is the step right before formal adoption into the standard. The proposal states that implementation is already under way in the latest chrome and in node 12.
proposal:
https://github.com/tc39/proposal-class-fields#class-field-declarations-for-javascript

Happy to switch back too. FWIW, every react project I've worked on has had this syntax enabled by babel.