Material-ui: [Snackbar] Please describe how to easily set the slide direction for a toast

[dandv]

I'm running into another instance of simple things being super-complicated :)

What I'm trying to do is simply display a toast sliding up. I've tried following the Control slide direction documentation section, but it doesn't actually explain how to control the direction; instead, it gives a complicated example with variable directions, and maybe it's too late in the day or I haven't had enough coffee, but I haven't been able to figure out how to set up one simple sliding direction.

And I'm not the only one, see this or #16637.

By comparison, in other UI toolkits, you simply set the direction property as a string.

[oliviertassinari]

@dandv Thanks for reporting this case, I don't see any improvement opportunity. We document how to use a different transition component, with its option. I think that going in the direction of Grommet is a no go, it breaks composition and tree-shaking, without gaining much more simplicity.

Do you see a change in the documentation that could have helped?

[dandv]

Indeed it was too late, and I figured it out this morning:

<Snackbar
  ...
  TransitionComponent={props => <Slide {...props} direction="down" />}
>

What would've helped me is the clarity of documenting how to set up a specific transition (like with the example above), before giving the example with functions returning functions. Most of the time, developers want one transition type in the code, and the reality is that most people copy/paste examples.

[oliviertassinari]

@dandv Avoid the above, you will create a new component at each render, breaking the animation.

Maybe we should add a plain example, just before the demo?

function TransitionLeft(props) {
  return <Slide {...props} direction="left" />;
}

export default function MyComponent() {
  return <Snackbar TransitionComponent={TransitionLeft} />;
}

[dandv]

Yes! A plain example is what I was after, and what I think every component and option should have.

It would also help people avoid traps like the one I fell in, with creating the transition on every render.

[dandv]

Another "first principles" thought on toasts, maybe @dtassone can also opine:

The state-based paradigm feels ill-suited for toasts, IMO. Toasts are displayed imperatively as a result of an action, as opposed to changing their state (shown/hidden/slid out) in response to events. They're not really reactive.

To me at least, it would feel far easier and more intuitive to launch a toast from an onClick handler, rather than have it always present as a component and toggle its open state. The code would be far simpler too: onClick={toast(...options)}; no more separate Snackbar component wrapping a MUIAlert with a Transition parameter and open/close handlers for what ultimately is just an autohiding message with a background.

This is the shortest MUI code I could come up with for displaying a toast:

function Transition(props): ReactElement {
  return <Slide {...props} direction="down" />;
}

const [toastOpenState, setToastOpenState] = React.useState(false);

function handleToastClose(): void {
  setToastOpenState(false);
}

return (
  <Snackbar
    anchorOrigin={{ vertical: 'top', horizontal: 'center' }}
    autoHideDuration={3000}
    TransitionComponent={Transition}
    open={toastOpenState}
    onClose={handleSignUpToastClose}
  >
    <MuiAlert
      severity={myCondition ? 'success' : 'error'}
      variant="filled" elevation={6}
      onClose={handleToastClose}
    >
      {myCondition ? "Success!" : "Error :(" }
    </MuiAlert>
  </Snackbar>
   ...
 );

I know I'm new to MUI and not writing the best code (for example there are two handlers for the same close button?), and I realize the imperative approach that other frameworks take (example) doesn't fit the general approach of MUI; hence, just a thought.

[oliviertassinari]

@dandv you are no the first one to raise concerns about making the toasts easier to use. You can find notistack that fills some of the problems by @iamhosseindhv.

I have been tracking the features we could support with the snackbar in the future in https://trello.com/c/tMdlZIb6/1989-snackbar-more-features:

• #18098 Imperative API. the same for the confirmation modal. The implementation might be a bit challenging. It might require a hook so we can intercept the theme and apply it back into a new React mounting point. However, if we do that, we would lose the style configuration. So it might require a provided at the top of the React tree.
• Stacking support. material design is against it, but it's common enough to support it for the support of other design systems.
• unstyled/hook version. Have a way for developers to opt-out from the default JSS styles dependency and Material design styles.

In the react community, I believe https://github.com/fkhadra/react-toastify is the most used component.

[dandv]

Thanks for listening to my repeated concerns, esp. given how contrarian they have been :)