Skip to content

Latest commit

 

History

History
201 lines (155 loc) · 11.4 KB

ROADMAP.md

File metadata and controls

201 lines (155 loc) · 11.4 KB
Raw

Roadmap

The roadmap is a living document, and it is likely that priorities will change, but the list below should give some indication of our plans for the next major release, and for the future.

Version 1 (published on NPM under the next tag)

Releasing stable v1 is our top priority. It's going to be huge ✨. We are just at the beginning, we hope to make it:

  • the simplest React UI library available for new Front-End developers to start with.
  • very customizable so highly UI demanding production applications can save time building on top of it.

Material-UI was started 3 years ago. The ecosystem has evolved a lot since then, we have also learned a lot. @nathanmarks started an ambitious task, rebuilding Material-UI from the ground-up taking advantage of this knowledge to address long-standing issues. Expect various breaking changes.

The core team has been dedicated to the rewrite effort for one and a half years. If you are interested in following our progress or if you want to help us reach that goal faster, you can have a look at the following milestones:

Q&A with the v1 version

The v1-beta version has matured, so we think that it's time to communicate more on this effort. The following Q&A is an attempt at answering some of your questions.

Summarizing, what are our main problems with CSS?

The CSS (cascading style sheets) specification emerged in 1994. At that time, a bunch of others specifications were competing. It was the cascading concept that made CSS succeed over its competitors, by allowing users to provide their own style-sheet, that will be later combined with browsers and authors style-sheets. That feature was removed 2 years ago from the most popular browser. My point is, our needs have evolved quite a bit since then.

Back in the beginning of Material-UI, we had many issues with the first LESS approach. Aside from the problem with CSS at scale raised by @vjeux, we had the following ones:

  • We had a dependency on the LESS build chain with no way to abstract it away. Users needed to change their theme variables. @gpbl was maintaining a SASS version. (Today, we could be using cssnext).
  • The theme was computed at build time but a Material component must be able to render quite differently depending on his context that can only be known at runtime. (Tomorrow, CSS variables will help a lot)
  • We were shipping a big monolithic CSS file. That's not great for performance (for example it goes against the PRPL pattern suggested by the Polymer team). That was also an issue for users wanting to use a single component without paying for all the CSS upfront.
  • We used multi-level selectors, making the override of styles challenging.

We later came up with an inline-style approach solving the majority of our issues. But:

  • We had lost around 25% of the performance 🐢. Computing the inline-style at each render with no caching isn't really efficient.
  • Some more advanced CSS feature weren't available, e.g. keyframes, pseudo-elements, pseudo-classes 💅.
  • Media queries weren't available on the server. At least not yet.
  • Debugging was really challenging. Browser dev tools aren't tuned for inline-styles.
  • React v15 has changed the method of injecting styles into the DOM meaning, for example, that prefixing all browsers for display:flex is no longer possible 💥.

Does JSS solve them?

Yes, it does. You can have a look at this presentation for more details.

When do we intend to release stable v1?

We don't have an ETA for the release of the v1, however, we are going to try to follow this plan and hope for a Q1-Q2 2018 release:

  1. We completely address the styling issue before moving from alpha to beta.
  2. We publish our first beta releases.
  3. We merge the v1-beta branch into master
  4. We publish our first pre-releases, if all goes well, we move to the next step.
  5. We publish v1 🎉

At that point, some features and components from Material-UI v0.x will be missing in the v1. So, what about them?

  • First, both versions can be used at the same time, people can progressively migrate, one component at the time.
  • Then, with the help of the community and over time, we will support more and more components.
  • We would rather support few use-cases very well and allow people to build on top of it than many poorly.

Have we ever considered using the best libraries for each piece of functionality and provide only a wrapper for the UI?

We have, it really depends on the problem we are trying to solve. For UI related things, providing a wrapper for the functionality is often the wrong approach. We think that it should be done the other way around, i.e. providing a low-level API that can be combined with third-party libraries, e.g.:

On the other hand, using a smart date library for the DatePicker / TimePicker would probably be much better as date management is tricky and not a core business.

Breaking changes before v1

It's time to look at the last breaking changes needed before releasing Material-UI v1. Users trying out and using v1-beta and giving feedback has been a tremendous help. Thank you!

This feedback has guided the following list of important breaking changes that are needed for the stable version:

  • Remove the fontSize property from the Icon and SvgIcon components in order to make it the default behavior. It's already the default behavior of the Icon component. You will still be able to change the size of the icons with the width and height CSS properties. The difference is that they can use the font-size as a shorthand.

    -<SvgIcon style={{ fontSize: 20 }} fontSize />
+<SvgIcon style={{ fontSize: 20 }} />

  • Do not prefix the classes keys when used for a variation. >80% of the components enforce this rule, let's make this figure 100%.

    -<TableCell variant="head" classes={{ typeHead: 'typeHead' }} />
+<TableCell variant="head" classes={{ head: 'head' }} />

  • Remove the xxxClassName properties when already covered the classes property. These properties were introduced beforeclasses. Using a single pattern makes things more predictable and easier to work with.

    -<Tabs buttonClassName="buttonClassName" indicatorClassName="indicatorClassName" />
+<Tabs classes={{ scrollButtons: 'buttonClassName', indicator: 'indicatorClassName' }} />

  • Rename Reboot to CssBaseline #10233. The new wording should clarify the purpose of the component. For instance, it's not about adding JavaScript polyfills.

    -<Reboot />
+<CssBaseline />

  • Grid with no spacing by default #10223. The negative margin implementation solution currently used comes with serious limitations. Material-UI is the only library with a non-zero default spacing between the items. Having zero spacing by default will ease the usage of the component.

    -<Grid />
+<Grid spacing={8} />

  • Flatten the import path #9532. Knowing the component name should be enough for being able to import it.

    -import CircularProgress from 'material-ui/Progress/CircularProgress';
+import CircularProgress from 'material-ui/CircularProgress';
    -import { ListItem } from 'material-ui/List';
+import ListItem from 'material-ui/ListItem';

  • Change the CSS specificity rule to solve #10010 and #9742 at scale. It's inspired by the Bootstrap approach to writing CSS. Basically, it follows two rules:

    1. A variant has one level of specificity. User overrides can be considered a variant, so we can keep things as simple as possible, e.g. color or variant.
    2. We increase the specificity for a variant modifier. We already have to do it for the pseudo-classes (:hover, :focus, etc.). It allows much more control at the cost of extra complexity. Hopefully it makes it more intuitive.
    const styles = {
-  checked: {
-    color: green[500],
+  root: {
+    color: green[600],
+    '&$checked': {
+      color: green[500],
+    },
   },
+  checked: {},
};

<Checkbox
  classes={{
+   root: classes.root,
    checked: classes.checked,
  }} />

  • Use @material-ui npm scope name #9673. The pros have been raised in the linked issue.

-import Button from 'material-ui/Button';
+import Button from '@material-ui/core/Button';
  • Look into the Render Props API over the Component Injection API. This one is an area of investigation. For instance, there is potential for simplifying the customization of the transitions.

These breaking changes will be spread into different releases over the next few months to make the upgrade path as smooth as possible. Not only does the Material-UI project have to be upgraded for each breaking change, but we also have to upgrade our own projects. We don't take making breaking changes lightly, it's very costly with UI components. For users, test coverage is hard to raise without tools like visual regression tests.

Let us know by commenting on this PR what you think we should or shouldn't do, what's important, and what's missing!

After stable v1

  • Theming. We will invest in the theming solution. We would love to see non Material Design UI built with Material-UI. @oliviertassinari is working on a proof of concept.
  • Type checking. We need to improve TypeScript and Flow coverage of the library.
  • Bundle size. We need the library to be as small as possible. We already monitor the bundle size with size-limit. We need to think of the solutions. For instance, supporting preact can help.
  • Performance. We can't optimize something we can't measure. We don't have any CI performance benchmark. We will need to build one and start investigating bottlenecks.
  • Learning materials. The documentation is equally as important as the quality of the implementation. We could be authoring a learning tutorial like Next.js is doing, or some egghead.io courses.