v6 thoughts

[SevenOutman]

I guess this is the proper place to share with you my fragmentary thoughts about v6.

This is not a fixed v6 roadmap, feel free to add your thoughts and ideas as comments.

Thoughts

Minimal breaking changes

First thing first, I want to limit the breaking changes in v6 (and future major releases) to as few as possible. 14 months have passed since rsuite v5 was released. During this period of time using and maintaining rsuite v5, we have seen features/fixes/improvements we want to add, some of which may introduce unavoidable breaking changes.

Some OSS I've used managed to make major upgrades so smooth and I really want to make upgrading rsuite an experience of that level.

Cleanup deprecated APIs

Drop compatibility support for APIs that are deprecated in v5 and before.

Drop IE support

It will allow us to move on to newer technologies, e.g. :has and :where CSS selectors.

Regard react <18 as legacy support

Keep up with latest react major releases.

Stylesheet -> CSS in JS

I've been authoring and maintaining lots of libraries - which are based on rsuite components - for our team members at work, and my library users and I did suffer from always having to import separate stylesheets. Most importantly it makes customization not as smart. MUI is doing great with its component customization APIs, which benefits from CSS in JS. I'm impressed by the flexibility MUI provides and wish we can have them in rsuite too.

Development

After some codebase cleanups (soon), we're going to explicitly start the development of v6 by checking out a 5.x branch from main. It does not mean immediate stop of v5. On the contrary, any backward-compatible changes added to v6 development should also be back-ported into 5.x, making v6 least different with latest v5 at its release time.

[simonguo]

Currently there are many issues and discussions about the mobile, and I am thinking about whether the mobile adaptation can be improved. There is no need for a full refactoring of interaction design, at least to make existing components work on mobile.

And mark all components with symbols(📱 🖥) to avoid finding out that they are not supported after use.

[SevenOutman]

Hi @Bayworld, please open a separate discussion for your topic. I'm going to delete this comment soon as it's off-topic from this discussion.

[SevenOutman]

Better API for passing props down to nested components

Many of RSUITE components are composed out of some other components, and it has been difficult to pass props to those underlying components. Often we simply spread props of underlying components directly on upper components, e.g. Uploader accepts some of Button's props and passes them down to the underlying Button component. But it gradually becomes hard to tell which props are supposed to be passed down, and which props are supposed to be applied on the component itself. For example a className prop on Form.Control component will be passed down to the accepter component, but what if I want to apply className on the Form.Control DOM itself? This has also caused real issues like #2944 (fixed in #2950) where props for Overlay was spread onto Input.

Therefore, I would like to introduce new APIs that allow user to explicitly specify what props should be passed down to what components. Here's one possible signature:

<Uploader
  action="/api/upload"
  ButtonProps={{ // or buttonProps
    appearance: 'primary',
    size: 'sm'
  }}
/>

<AutoComplete
  value={value}
  onChange={onChange}
  OverlayProps={{ // or overlayProps
    onEnter,
    onExit
  }}
/>

[simonguo]

It is indeed better in terms of maintainability to merge the props of the component into an object and pass it to the internal component. We can first evaluate the scope of such changes, because I am more worried about causing trouble for users to upgrade. In addition, if the design of props is reasonable enough, users do not need to perceive the dependency reference inside the component.

[simonguo]

#2493
CustomProvider supports setting the defaultProps of the component, which can be added to the plan list.

[medmin]

Please don't migrate to CSS in JS. It's horrible.

CSS in JS looks interesting, but it will surely make engineers write more inline css code mixing with the props. That's messy.
And there will be lots of !important, which never is the best practice, in the inline css code, because with css in js, there rarely are good ways to override UI framework (rsuite) style. I'm really not a fan of CSS in JS.

I hope you can keep using the current css class name system.

[SevenOutman]

Thanks for your suggestion! Let me explain some thought behind the intention to migrate to CSS in JS.

Theme variables as ES modules

The key point of adopting CSS in JS is to take advantage of JS.

In cases like styling elements in a <canvas> based charts, which can't be styled with CSS, we need to reference the color values in scripts. It's currently not possible to do with Less stylesheets.

const primaryColor = noWayToAccessALessVariable('@primary-color');

render(
  <Charts primaryColor={primaryColor} />
);

It immediately makes sense to move the color constants from Less variables to ES modules. Something like:

import { theme } from 'rsuite';

const primaryColor = theme.colors.primaryColor;

It's also possible to achieve this with CSS custom properties, which can be accessed via CSSStyleDeclaration.getPropertyValue() API, but there won't be editor hinting for what properties are available, in contrary to ES modules.

If we finally wrap the theme variables as ES modules, the best way to integrate them with styling system is CSS in JS.

DOM unaware

As we apply refactors and fixes to a component, its DOM structure may change. The selector based stylesheet won't be aware of the DOM change and would fail silently.

Take Sidenav item for example, a Sidenav item used to render an <a> within a <li> element.

<li class="rs-sidenav-item">
  <a href="/link">Sidenav item</a>
</li>

To customize the link style, user writes CSS like:

.rs-sidenav-item a {
  color: red;
}

Assume we remove this <li> element, letting the <a> become the root element of Sidenav item:

<a href="/link" class="rs-sidenav-item">Sidenav item</a>

The CSS would be broken without any message.

In contrary, if style customization is done via a JS based approach, it's not going to be affected.

<CustomProvider
  components={{
    SidenavItem: {
      styleOverrides: { // DOM-unaware customization API
        color: 'red'
      }
    }
  }}
>
  <App />
</CustomProvider>

Easier path import

For now, when users want to import a single component with path import, they always have to add an extra import of its stylesheet.

import Button from 'rsuite/Button';
import 'rsuite/Button/styles/index.less';

It gradually becomes onerous as the number of used components grows.

With CSS in JS, the styles can be bundled with the component and the separate import of stylesheet will be no longer needed.

No more Less support setups

Most build systems don't have first-class support for Less. Users always have to manually setup Less support for their build system if they want to customize rsuite.

---

As for existing best practices, I believe MUI is offering a practical approach in customization via CSS in JS. It also manages to adopt CSS in JS while still allow selector based stylesheets. If we can also achieve this feature we could make migration easier for users who already did customization via stylesheets.

[jspears]

Use CSS Variables, you can get the color from the element and you can override in the dom

getComputedStyle(document.documentElement)
    .getPropertyValue('--my-variable-name')

CSS Variables solve almost everything CSS-in-JS without throwing out the baby.

[vitalijalbu]

When reactsuite will be 100% responsive?

[SevenOutman]

There's no particular plan to make rsuite responsive as it's designed for desktop views.

[jspears]

My 0.02$. I'm new to rsuite but have been super impressed. One of the main draws was its not using CSS-in-JS. I have wrestled that beast for almost 2 decades now, and can tell you there is no winning.

With CSS Variables with CSS Modules you can accomplish 99% of what CSS-in-JS does, without re-inventing the universe. Every project I have seen with CSS-in-JS is a maintenance problem and a performance problem.

I have a lot of experience with this approach and would be happy to share some architectural ideas that would make it super nice to develop with.

[SevenOutman]

Hi @jspears , thanks for sharing your ideas!

My thought about moving to CSS-in-JS arose during my experience in using MUI and Mantine, both of which provide a user-friendly yet flexible API to control component looks via props. The advantage of styling via props is that, with a Provider, you can fully customize the library to be you unique one by overriding default look of every component in one place. An example use case is like:

<ThemeProvider
  components={{
    Paper: {
      defaultProps: {
        radius: 'none',
        shadow: 'md'
      }
    }
  }}
>
  <App />
</ThemeProvider>

I was so impressed by this kind of feature (powered by CSS-in-JS) and wanted to have it in rsuite to allow users achieve more.

You're right though I neglected possible maintenance and performance problem. I'd appreciate it if you could share more with us about your insights into the trade-offs of CSS-in-JS.

[jspears]

So I plugging my own thing (ts-emeth)(https://github.com/jspears/ts-emeth) for handling loading dynamic typesafe style sheets. This allows for downstream users to install there own style sheet for a component. It doesn't require a bunch of context and is really just a map look up.

I also then create 'Surfaces', that are a collection of 4-6 colors depending on whatever

.surface-header {
 --border-color: red;
 --background-color: blue;
 --hightlight-color: purple;
 --text-color: beige;
}

.surface-body {
--border-color: black;
 --background-color: violet;
 --hightlight-color: green;
 --text-color: white;

}

Then in the components I reference the the variables. So if the component is on a different surface it will inherit the correct colors. Think you want a button to have same background color.

.button {
 background-color:var(--background-color);
}

then when it is used it will inherit the right color.

 <div class='surface-body'>
    <Button/> <!-- background is violet -->
</div>

 <div class='surface-header'>
    <Button/> <!-- background is  blue-->
</div>

With this technique, and with CSS Modules you solve nearly the entire spectrum of CSS-in-JS does without the nightmares.

[SevenOutman]

I tend to move away from Less because it requires extra build system setup from users. CSS variables can cover most "variating value" situations. But it doesn't seem to be able to replace Less for cases like controlling whether some styles should be included, e.g. this one #1953 (comment) .

[jspears]

Would you consider a change from schema-typed to an abstraction that allows Zod, or others to be used? I've been working a bit with/on it and while its a great early attempt at object validation, I think its a bit of a distraction for a component library. I just started working on this abstraction for my own use, but would be happy to share.

[SevenOutman]

I've always been thinking of separating form state managements from this UI library - they're different points of concern to me - at least decouple the state management logic from the UI component. But I need to find a way to make it less breaking because my team projects rely on Form components so heavily. Maybe it's a good chance to follow up in this major update.

[jspears]

They are different but I really kinda like that there is a solution. So many of the component libraries give input components, but skip on everything else. Formik and friends are fine but are yet another library, and more decisions to make. I think abstracting the validation bit, but otherwise keeping form stuff is all that is really needed.

Moving from schema-types to Zod which is super similar, lowers the amount of documentation and work you have to do to maintain both.

What I would really like to be able to do is shove a Zod model into a Form. This is not really different than what you have now.

const onSubmit = useCallback((user:User)=>saveUserAsync(user), []);
<Form model={UserZod} onValidSubmit={onSubmit}>
//error handling handled automatically. disabled state while submitting.

</Form>

Maybe I'll open a PR

[simonguo]

I hope rsuite users will not have too much workload when upgrading from V5 to V6, so it is necessary to maintain API compatibility as much as possible.

In addition, I think that the combination of Form and Zod is a good form validation solution, but it is best not to create a dependency on Zod in rsuite, because some developers may prefer to use other validation libraries, such as Joi or Yup .
Therefore, my recommendation is to make extension components around rsuite ecology, such as @rsuite/form-zod, so that users can freely choose which verification library to use.

[jspears]

It would be nice to support a bunch of validators — just a matter of how much effort it is. It may not make sense to support your own validation lib. I think any of the existing are workable. Not picking one means a lot of paths of support but also future proofness. Picking one is a risk also. Obviously not my call.

The only reason I suggest Zod is I looked at all of the ones mentioned and others a week or two ago and Zod seemed the over all winner.

[simonguo]

I think you are right that the cost of maintaining schema-typed is too high compared to validators like Zod and Yup. However, for compatibility reasons, it will remain as the default validator.
I saw a solution in Formik that I quite like jaredpalmer/formik#3458 (comment) , maybe we can refer to it and provide a createValidationSchema method in the Form component of rsuite.

import { Form } from "rsuite";
import { z } from "zod";

const user = z.object({
  email: z.string().email(),
  name: z.string(),
  age: z.number(),
});

const validationSchema = Form.createValidationSchema(user);

return () => {
  return <Form model={validationSchem}>...</Form>;
};

[vitalijalbu]

🚀 I really want rsuite to be responsive, if yo uguys will introduce at least a copy of Bootstrap grid, BOOM 👀. Material is forgotten for me, but I think also for ther people...

[iska9der]

Yes! The only drawback of this library