React-MD – React components built with Sass
react-md.mlaursen.com
react-md.mlaursen.com
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.
I haven't had time to fully test that claim yet with a screen reader, but it does seem to work well using the key oars alone which is something often overlooked.
I'm starting a project that is more or less material, and this post of making me realize it could definitely use a number of material UI elements.
It's too difficult to overwrite styles, they are changing their style "system" for the 3rd time in under a year right now (SASS -> postCSS), and the lead maintainer has started posting updates both minor and a major bump without any kind of changelogs or info on what changed, and there is no real roadmap to speak of.
I hate being overly critical of FOSS projects, especially ones where it's clearly a passion project, but I can't rely on React Toolbox any more in a professional way. If it were a smaller library i'd be more okay with it, but the "theme" or "UI framework" of our application is not something easily replaced, so it becomes a bit more important.
I shied away from Material-UI as inline styles just won't work for us for a bunch of reasons, and they aren't far enough along their "conversion" to the new style system at this time for us to take it on faith, so we struck that down too.
This library is looking like a good replacement. If some of those performance issues aren't the libraries fault and are the "app maintainers" fault (in this case the same person, but the main dev has told me that it's because he was lazy when making the docs website that it's sluggish), then it's looking like it'll be a winner!
I've only given each of them a brief look this morning. I certainly would not have gathered that about react-toolbox - and those among the kinds of issues that really tend to bother me.
Also, for Material-UI, I don't particularly like the idea of relying so heavily on inline styles and already know where it will cause some issues in the future of this project.
The library is originally, and still, built with SASS. We've migrated already to PostCSS (there is a beta published) to fix issues regarding customization and building. I'm releasing a new package in a couple of days so you will see the reasoning behind this migration.
Cutomization is a problem really difficult to solve and it needs dedication. I'm putting a lot of effort on it but I can't review issues, solve doubts, fix bugs, work on new components, maintain the docs site, release new versions, keep dependencies updated, writing changelogs... and at the same time figuring out how to solve major problems like customization and workflow.
I'm one person without any funding or retribution. I have no help apart from sporadic contributions and some people helping with issues from time to time. I also have a full time job that keeps me away from dedicating as much time as I wanted.
Instead of being critical (and to hate being critical), you can contribute to the project. There is no need to write code or to fix bugs to contribute. It's enough responding issues, solving doubts... But please, don't be unfair. Open Source is built by everyone. If you see weaknesses, just try to help fix them, not just pointing at them. :)
About the changelog... there are no breaking changes, no major releases. You can see what's changing just by checking out the git history. I get is easier to check a note with the highlights but I need to assign priorities to move on. In any case I want to let you know that I plan to release a roadmap, along with an article and a new package during the next week.
I want to start off by saying I didn't mean for anything I said to come across as bad mouthing you as a person or a developer, or your work. I was trying to give my experience and what we were looking for/having issues with.
I fully understand that this is largely a passion project for you. It's a fantastic library, and I really mean that. It's a project that I like to point people to when they want to see an example of a well put together ES2015+ setup. And without your library we would have either rolled our own which would have taken a pretty significant amount of time and wouldn't have been as polished or tested, or we would have went with Material-UI which would have had a tough learning curve to us who are used to CSS and SASS.
That being said, we are still looking at options for replacement of React-Toolbox in it's current form (or perhaps just a change in how it's used). As you said, styling and customization is a really difficult problem to solve. I haven't used any other react UI libraries in any major way, so i'm not sure if this is the best or if it's just not a good fit for us, but we felt the pain from trying to customize styles and started looking. I didn't mean to have it come across so negative, and I apologise for that. Rereading it now it's just a list of complaints, and I generally try to avoid doing that (although clearly not well enough).
I have contributed in a very small part to React-Toolbox through a few bugfixes and very small PRs, but not in any significant way. I opened an issue[0] this week about the issues we have been having with updates without changelogs and the lack of direction. I'm willing to help, but I need some direction on how you want that help. I get that it's tough to prioritise and that some things need to fall through (Prioritization is my worst skill, I am terrible with it and have to lean on others all the time to help me, so I know this all too well!), but at the least I just wanted some information on if this was intentional, a mistake, that I was missing something, just an oversight or something else.
I know you think there aren't any breaking changes, but to me updates without any kind of information on why or what was fixed or changed are an issue. For example, a change you made almost a month ago added a default `type="button"` to all button elements. This broke all of our forms where we were relying on that. We saw that forms didn't work correctly when updating, but didn't have time to look into why so we held back the version. I spent an hour or so looking through commit logs to see if anything jumped out at me, so then I started to look through a log of the code that changed, however since there were over 80 commits between 1.2.5 and 1.3.0, I gave up looking since it would have taken more time than I had at the moment. Finally just today I stumbled upon an issue[1] where you explained what and why it was changed.
That's something where if there were a line along the lines of "added property `type` to buttons (defaults to "button"). Done to avoid having every button submit a form." it would have saved us a few hours at least. And in 5 or so minutes the fix was made for our codebase and we can update. It's a small thing in the end, but it's just one of many little issues we have felt like that, and often times there is already a fix, but it's hidden in github issues under strange titles and they take a long time to find.
This ended up getting a lot longer than I thought it would, so to close it up...
I'm very much looking forward to the roadmap/article you will be releasing, and I am still more than willing to help with changelogs, documentation, testing, or even some light features/fixes. I really do like the library, it's a large part of our app that has saved us a significant amount of time. So thank you.
[0] https://github.com/react-toolbox/react-toolbox/issues/1043
[1] https://github.com/react-toolbox/react-toolbox/issues/953
The components that are given are "building blocks" Buttons, "cards", dialogs, text input fields, etc...
Once you get them, you can just override the color, size, shape, and sometimes a few other little things and it "just works".
So I don't need to worry about getting an input box to correctly style on all platforms, I don't need to come up with the animations and JS to make the fancy "floating input field" or the inky splash effects or the 2-step shadows.
That's also why the issue around styling these things is so contentious. It's a major way that you'll be interacting with them, and with the way CSS works it's not easy to "overwrite" default styles without using !important which feels like using a sledgehammer to crack an egg.
We aren't designers, and being developers we have a tendency to nitpick which is only worse when the subject is just outside our area of expertise...
Picking a design "platform" and using a toolkit to implement it pretty much stopped most of that in it's tracks and let us focus on the actual application.
It's obviously not for everyone, but it was exactly what we wanted and needed.
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.
- 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.
-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.
Contrary to Bootstrap, you can't just drop in Material Design and expect it to look decent. You actually have to adhere to the design and usage guidelines that come with Material Design to really make something good looking and functionally coherent with it.
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.
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.
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.
[0] https://www.interaction-design.org/literature/book/the-gloss...
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.