[SIP-48] Using Ant Design as our primary component library

[nruhe]

SIP-48: Using Ant Design as our primary component library

Motivation

Speed, consistency, and clarity.

Since the adoption of SIP-34 means a significant amount of view layer code is overdue for an update, there is ample justification to reevaluate our current UI library choices. As such, this SIP recommends introducing Ant Design to Superset and migrating away from the majority of our current view focused dependencies (e.g. React-Bootstrap).

Why Ant? Out of the box, Ant Design supplies over 60 different enterprise-ready React components, all of which are richly documented, cleanly styled, and accommodate a wide range of use-cases. That's right, this isn't just another markup wrapper like React-Boostrap; these components actually manage some of the stateful UI logic for you. We even get Typescript typings for all of the props. That's a lot from just one library, but that's why Antd has the most stars of any component library on github.

As a direct side-effect of this feature set, we can cut our view layer's dependency tree significantly. You'll see the exact packages we can replace further down in this SIP. Fewer dependencies means fewer things to manage. Fewer things to manage means fewer things to learn. In the long run, we'll end up with one primary source of docs to read and one standard way of building things.

From a visual standpoint, Antd is already pretty close to the designs proposed in SIP-34. We won't really need to create new styles like we were planning, just adjust some theming variables. This also saves designers work since it comes with mockup kits for Sketch, Figma, etc.

Its also worth mentioning that Antd just has some really great patterns for things that I hope the community will absorb by osmosis. If you want an example, have a look at the Menu and Button components.

Proposed Changes

Replace the majority of our UI view-layer dependencies with Ant Design components.

Changes to Public Interfaces

None that I know of.

New Dependencies

The only new dependency is ant-design, which will add a comparably small footprint of 2.2mb compressed. Given one of the goal of Antd is to remove dependencies though, let's take a look at how we'll be able to shrink our dependencies list.

Now	Future
re-resizable	ant-design
omnibar	re-resizable
react-ace	react-color
react-avatar	react-dnd
react-bootstrap	react-dnd-html5-backend
react-bootstrap-dialog	react-json-tree
react-bootstrap-slide	react-markdown
react-checkbox-tree	react-router-dom
react-color	react-virtualized (or react-window)
react-datetime	syntax-highlighter
react-dnd	react-ace
react-dnd-html5-backend
react-gravatar
react-json-tree
react-jsonschema-form
react-markdown
react-router-dom
react-search-input
react-select
react-select-async-paginate
react-select-fast-filter-options
react-sortable-hoc
react-split
react-sticky
react-syntax-highlighter
react-table
react-transition-group
react-ultimate-pagination
react-virtualized
react-virtualized-auto-sizer
react-virtualized-select
react-window
Reactable-arc

Note: As a follow up to this SIP, we should establish a process to regularly review and deprecate unwanted or obsolete packages.

Migration Plan and Compatibility

Ant Design should be incorporated incrementally.

• Old components will be rewritten to use Antd as we incorporate the SIP-34 designs.
• New components should start using Antd right away (where designs permit).

Dependencies should be dropped as soon as they are no longer needed, but we should regularly review the dependency tree and prioritize deprecation of packages as needed.

Temporary Namespacing

Antd wasn't designed to play with other large design systems like Bootstrap, so as an extra precaution, we'll need to go with a namespacing strategy to prevent conflicts.

Since Antd is LESS-based and makes use of the "&" selector though, we won't just be able to throw it behind a classname.

As a work around, the LESS files will need to be preprocessed with our theme variables into a CSS file and then included in the app's LESS under the ".ant" namespace. This will involve some additional build process overhead, but we can eliminate it as soon as we've removed the major sources of conflict, like Bootstrap. 😃

Using Antd under the namespace

Each entry point should wrap the app in an Antd Config Provider component that passes down the global antd config.

import { ConfigProvider } from 'antd'
import antdConfig from '../antdConfig.ts'
const App = () => {
	<ConfigProvider {...antdConfig}>
		{// ...}
	</ConfigProvider>
}

Each component that uses antd will need to ensure there is an ancestor element with the ".antd" class applied.

Turns out, none of this is necessary thanks to some clever overwriting of Ant's globals. Just include Ant components directly.

Styling Overrides

Antd components can have their default styling overridden using Emotion (per SIP-37) just like the existing React-Bootstrap components can. I recommend modifying the Antd theme variables first and only using Emotion if fine-tuned customization is required.

Storybook

The work comprising this SIP closely parallels that of the Superset design system under construction as part of SIP-34. This opens up an opportunity to maintain a Superset component library that's kept in step with the design system as it develops in Figma. We recommend, as part of this SIP, creating a Storybook in order to continually check the engineering implementation against reference designs, and to act as a "toolbox" of sanctioned Superset components that engineers can leverage to build interfaces. There needn't be "stories" for every component of Ant Design, but they would be useful for either composited components (e.g. cards, controls, lists) or for highly-customized key components (e.g. the Button, in all its varied permutations).

Rejected Alternatives

Using another library

Material UI

Material is probably the best alternative to Antd, but it ultimately loses out because it doesn't integrate with Typescript as well. I also tend to find the patterns it offers are less mature.

Semantic UI

Semantic's repo is isn't very healthy with the core leadership now focused on Fluent. That aside, Antd does more and has better documentation.

Fluent UI

Since I mentioned it, I might as well address it. This could be good in the future, but the library looks a bit too much like Microsoft Office and isn't as feature rich. Next.

Building our own

The reasons for rejecting this are pretty obvious, but to make a case against it, it all comes down to reinventing the wheel. We will never be able to achieve the same level of richness and quality that a library like Antd offers without investing countless hours into recreating the work they've already provided. Let's spend that time making Superset awesome instead.

[issue-label-bot]

Issue-Label Bot is automatically applying the label #enhancement to this issue, with a confidence of 0.74. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[etr2460]

This seems like a great step forward to design standardization and developer ergonomics within the frontend! I'm very excited to see it move forward. A couple questions regarding the SIP and implementation:

1. How does Antd play with the Jinja templates we still have in certain views? Will we be able to replace the bootstrap components there with Antd components, or will updating those views be blocked on moving all rendering to the client side?
2. I see you removed react-ace from the new dependencies list, does that mean Antd contains a fully featured code editor as one of its components? I know @ktmud has also been thinking about replacing AceEditor, so I'm curious to hear his thoughts here too.
3. A clarifying question: will we need the ConfigProvider after Bootstrap is gone? Or is it only required to add the .antd class?
4. Could you add some details to the SIP about what upgrading Antd is like? Do new releases usually come with a lot of breaking changes? Is this something we'll need to put in a lot of effort to keep up to date? I ask because we've been stuck on an old version of Bootstrap because the new ones have a bunch of breaking changes and no one's put in the time to do the full migration. I'd like to avoid a situation like that.

[ktmud]

I can answer 2 and 4.

Antd does not come with a code editor. It recommends react-codemirror2 and react-monaco-editor in their official doc. We don't have to replace it if we don't want to. Replacing Ace should be another topic unrelated to this SIP.

Take a look at Antd's historical migration guides: v2 to v3, v3 to v4. I'd say the breaking changes are quite manageable. Every time they also provided codemod tools to make migration easier.

[nruhe]

Re 1; Blocked on moving things to the client side (barring server-side JSX rendering). This should be extra motivation for getting those into the SPA. :)
Re 2; Looks like that was just an oversight. Good catch. No plans to change react-ace for the time being.
Re 3; After bootstrap is gone, you won't need ConfigProvider or a ".antd" class wrapper. We might still use the ConfigProvider for other purposes though.
Re 4; See @ktmud.

[rusackas]

Closing since it's voted through, and in progress. Lots of steps ahead, but we're well on our way! 🚀