How have people found using the material-ui npm package with Meteor (specifically 1.3)? Does Meteor bring the CSS in correctly? It seems like the material-ui package is the one the wider JS community has landed on?
Also, am I right in thinking you need to add in your own grid system if you want something like the one in bootstrap? If so, any recommendations?
Finally, would your recommend it, any gotchas or warnings?
I’m starting a project with material-ui. It was trivial to load using the directions on the site, and adding a test button gave me a properly styled component. I’ll have more to share when I get a little deeper - I hope others will add here as well. I might just use the bootstrap grid since I know it, but I’ll be curious to hear if there are advantages to using something else.
For the grid I use http://flexboxgrid.com. I don’t suggest using the bootstrap grid mostly due to size, although it might be possible to just import the bootstrap grid, so less of a size worry there.
Using it on 1.2 from NPM. I think all the styles are inline. Here is my app.browserify.js file:
Using right now material-ui + React seamlessly. I’m a newbie with CSS so not yet using / testing any grid. However, I’m feeling some difficulties with implementing material-ui selectable list with a Mantra app and controlling your state. I ended up doing as the docs suggest and using state into the component.
If you are using state, then don’t call it a Mantra app.
To replace state as in the docs, I use actions.
For example, lets say that in your main layout, you have a AppBar and a LeftNav. The doc tells you to use state to toggle the offcanvas left menu.
To achieve the same result using the Mantra specs, create a layout.js action file with an action like so:
Ah that looks good, if I’m reading that right it uses the same classes as Bootstrap, so hopefully my existing (bootstrap-based) layout stuff should carry on working and I can carry on laying things out the way I’m used to?
Well, the first thing I always do when evaluating a new toolkit is to check how well it supports keyboard navigation, which is a key part of supporting accessibility. Open a dialog and see if tab navigation works - can you tab between buttons, and is focus properly trapped in the dialog (i.e. tabbing shouldn’t activate other parts of the doc). The demo page for material-ui fails both of these tests. Of course, most JS widget libs fail in the same way.
Thanks @elgusto. I was thinking to use right now this approach. So the main layout container will be in charge to manage all state of childrens. But I noticed this is only possible if the component or the layout (in this case) is being called from the router. Right ?
I think you should be able to use the container layout directly as long as you inject the app dependencies in it.
const LayoutDefaultCtx = injectDeps(LayoutDefault);
I didn’t have time to look in details how that works yet, I think it comes from the mantra-core in your main.js:
Unfortunately the props and actions isn’t passed into layout component.
I have this structure of components: MainLayout -> Sidebar -> SidebarList.
My goal here is to store the link’s index clicked by the user on a selectable list and changed that accordingly, but taking out the state management of the list and putting this on the actions.
Has anyone managed to stop the AppBar scrolling off the top of the page? I’d like the same behaviour you see on the docs page where the AppBar doesn’t scroll and the LeftNav is below the AppBar, but I can’t work out how to achieve that.
I hadn’t heard that layouts aren’t supposed to use state in Mantra. Is there documentation about this? What are the benefits of using context() vs. state?