
React-MD – React components built with Sass - lionep
https://react-md.mlaursen.com/
======
Egidius
Even though I'm not completely satisfied with its state, I've recently picked
Material UI over React Toolbox. Too bad React-MD wasn't around at the time
because it seems like a fierce competitor at first glance.

Things I like about React MD over Material UI: * Fully tested * Separation of
styles * Grid included

On a sidenote: the page's styling messes up during loading. It takes one
second before it morphs into the actual state.

~~~
renshenhe
Have you run into any significant issues with the overhead of "bloat" that
comes with inline styles? Injecting so many styles inline especially for
complex list items might potentially have some performance issues despite
having a virtual dom.

I have been considering refactoring my personal ui lib to use css for static
styles with css modules while all themable/dynamic styles inline. Many might
say the mixture gets increasingly complex scaling but I have not run into such
an issue.

~~~
harlanlewis
This is a very fair point. We've followed a similar approach to what you're
considering, with styles living in a couple places:

\- Scss library of variables, mixins, and functions that can be imported in
whole or piece-by-piece into components that can use them. Doesn't compile any
CSS classes on its own.

\- A lean global “browser reset”, uses some of the global style variables from
the library.

\- A simple React component (we call it `Cell`) that is used absolutely
everywhere. This component has its own .scss file which imports the global
scss library, and is essentially a one-stop-shop for `functional` CSS for
colors, dimensions, typography, elevations (drop shows and zindexes),
scrolling, etc. React authors use it via props instead of writing class names.
Eg `<Cell color='action-primary' elevation={2} fontFamily='header'>`. Heavily
reusing this component is what most directly addresses the performance
concerns you note.

\- While Cell is sufficient for composing most layout and aesthetics at all
levels of the page, one-offs are often needed for fine detail work:

\--- Simple cases are handled directly where needed via inline styles (easy to
read when everything is in one place). We don't do anything fancy here for
authoring (no radium etc), just an inline style autoprefixer that runs through
postcss loader via webpack.

\--- Per-component scss files for more complicated needs (unique animations,
novel compositions, complex interactions, etc). The component scss imports the
global scss library so all our standard theme/helpers/etc are available
everywhere. The component scss outputs to unique hashed classnames via
webpack, so there is no risk of class name collisions between components. This
allows for very focused scss files with short, straightforward names.

A lot of this works very well - in particular the global scss library, the
Cell component, and the ability to opt-in to more fine grained control per
component. However, there is some duplication between the scss library and a
few javascript utils we've made to help keep inline styles consistent. These
issues are somewhat made up for by how transportable our style layer is - if
we were to switch away from React, or start a new project on a different
stack, having the style vars and class library defined in scss already would
make it easy to simply drop in and get rolling.

~~~
renshenhe
Interesting insights, though I wish much of these practices to be viable
outside of closed source.

-A Scss library for functionality rather than compiling definitely seems interesting as a halfway point between pure css or pure javascript.

-When I was using pure inline-styles I rarely ran into cases where I couldn't get away with using divs or other style-less elements. The downside was div soup and bloat when rendering large quantities of components that had resets.

-I would be very interested, if allowed, to see the design of your Cell component. Rather than a component itself I find it simpler to define certain highly reused styles in the global scope, such as grid layout. Styles like these generally don't need encapsulation and are highly reusable since they are mainly containers.

-

\--I must admit that prefixed inline-styles are atrocious to look at it
definitely is enjoyable dealing with a component in roughly a single file. Big
loss was targeting an n:child for styling

\--Since I don't write any production code I can get away with the web
animation api or any resource still in early stages or have not been highly
adopted yet. I generally have a prefix for the global css classes e.g. 'qp-
grid' and my projects are hardly big enough to have naming collisions.

It is unfortunate mixing css and inline-styles make it quite difficult to
apply to an open source lib but I am quite hopeful for a solution or practice
to address the issues.

------
farax91
What I like about this library over Material UI is the complete separation of
styling, I really don't like how styles are written and passed as an object in
Material UI and the requirement of getting muiTheme() from context for most
components is just maddening, especially painful during testing. But what I'd
really like to see from a material ui library is one that uses ITCSS for
styling, check out the grommet UI library which is just an amazing library to
work with, and the ITCSS makes editing and customising components a breeze.

~~~
kross
Check out the material-ui `next` branch. It uses JSS and is much easier to
customize.

------
vasco
Nothing to do with this project per se, but I still do not understand the deal
with material design on the web. I can understand the case for it's use in
small screens and maybe falling back to it based on media queries makes sense
but I'm yet to see a good looking website on a laptop using material design.

~~~
Klathmon
I tend to enjoy it, mostly because it's a good "baseline". The phrase "nobody
ever got fired for choosing IBM" comes to mind.

It might not be the most beautiful, it might not be the most information-
dense, it might not be something that an actual designer would want to
implement everywhere, but it works consistently, and it works pretty well on
all screen sizes and shapes and input types.

It's a set of guidelines to hold your hand in making something that's not
terrible even if you have literally no design experience, and I think it's
doing a great job in that.

But, I also really like the look of MD. The animations, the "inky" taps, the
shadows, the movement. It looks nice to me, it helps give a sense of "where"
parts of the app live, and it tends to be consistent enough that if I notice
an app doing it, I can generally grasp the "where would I go for this" much
faster than other designs.

------
Klathmon
One thing the author has pointed out on reddit was that many of the components
have a property to wait to fire until the ink animation is done.

That looks like the cause of the delay and "sluggish" feeling some people are
reporting. If you don't set that prop, it's very quick even on a nexus 4 which
tends to be my baseline device for "web apps" right now.

Why you'd want to set that I'm not sure, but it's there.

------
patates
Did the author try to use the components from a low end phone? Generally it
looks good but all the jumping, flashing and crashing do not signal version
1.0.0.

~~~
bestest
Totally. 64% of my users are on mobile. Can one really afford to ignore that
crowd?

Of course, mobile web development is, as I tend to say, the IE6 of modern
days. So many older devices, and we also need to more or less support all of
them.

Graceful degradation is the key, yes, but React-MD doesn't even seem to cope
well with high-end devices.

------
rco8786
Perhaps the name could be re-thought? I expected something Markdown related.

------
andr
This is awesome! Any plans for TypeScript support?

~~~
avtar
Looks like that might happen: [https://github.com/mlaursen/react-
md/issues/175](https://github.com/mlaursen/react-md/issues/175)

------
tgroutars
I would be curious to know how this compares to Material UI. Has anyone tried
both?

------
adnanh
Somewhat relevant: It seems like Google is using [1] for some of their
projects...

[1]
[https://getmdl.io/showcase/index.html](https://getmdl.io/showcase/index.html)

~~~
dchest
Huh? This is a list of sites that use Material Design Light, which is not
React-MD. Also, I don't Google even uses React.

------
Numberwang
Wow very pretty. I love material design.

------
CombatCode
sweet, I have just yesterday implemented MaterialUI to my react app... I will
change it asap :)

------
elcct
Am I the only one who thinks Material Design and its derivatives is just plain
ugly? If I see a website created with this style, I press Ctrl+W close to
speed of light.

~~~
sapeien
It probably makes sense in Google's own ecosystem of apps, but as an aesthetic
style it seems to be intentionally bland and tasteless.

~~~
andybak
I think you can defend your use of the word 'bland' here but 'tasteless'? That
seems a little overblown.

~~~
Spivak
I mean, they they are synonyms after all ;)

~~~
andybak
Ah. I guess I was reading 'tasteless' as implying that you had to lack taste
yourself to like it rather than 'this thing has no flavour in itself'.
Hmmmmmm....

------
kibrad
what a slow, clumsy, and flickering website of a modern ui framework

------
arekkas
~deleted~

~~~
Klathmon
Because even their CSS implementation will still be css-in-js, not to mention
that this framework seems to be going in a slightly different direction than
material-ui.

Not everything can be done in a PR. I doubt the callmeall people would enjoy
someone switching them to SASS, or rewriting some of their components entirely
to work with a keyboard easier, or any other major changes.

And what is "half baked" about this? Besides being newer, it doesn't look any
worse to me at first glance.

------
6mirrors
MD is not a clean UI....

~~~
camus2
What's a clean UI ? Gcloud admin implements material design, it looks clean to
me.

