Open javivelasco opened 8 years ago
@javivelasco
Really a great idea. I think RT is the best MD library that I have seen never and congratulations for it. great work!.
However I think the actual implementation of MD need some changes that would be excellent before think about new components or external components, I mean responsive components, a 12-columns based grid system to organize the content and a theme switcher with 'light theme' and 'dark theme', proposed by MD specification.
I think those changes are more important at this moment and I'm going to suggest my personal opinion about how it should be:
For responsive components we only need to set the width of each component external wrapper to 100% and organize the internal content relative to this wrapper. You can say it's not usefull, but if you think about 12-columns based grid system really is the best option. Why?
let me try to explain it,
The 12-columns grid system, work as follow:
.row
class with 100% of width..row
and .colxx
classes if necessary..col3 {
width: 25%;
}
Then the components with the 100%, fill .colxx
wrapper and organize the components easy.
It looks like a hard work but if we take advantage of existing libraries it's really easy.
I suggest flexboxgrid.com. because it's ready to use and there is a react implementacion of this that use CSS Modules: Flexboxgrid react. Then I think is easy to merge with RT structure.
flexboxgrid include CSS classes for horizontal and vertical alignment, offset columns, distribution and it's really easy to use... the final user should use as follow:
<row>
<col> any RT component</col>
<col>another RT component</col>
</row>
...
About theme switcher, I think that is very useful and will reduce the issues about theming because the people will have a real example about how to customize the components (generally instead individually).
let me know what do you think
+1 out of the spec should be created in a separated repository, but in the same organisation.
I agree with it needs to be fully responsive and have a grid system. currently using external grid lib Also menu component needs to enhance, I think it's missing label menu , cascading menu and menu item nesting
I don't know about grid systems, but I think grid lists should be added. Since they're part of the spec and all. https://material.google.com/components/grid-lists.html
@wtgtybhertgeghgtwtg Agree with you. We have whole app without any grid system and have no problems. I do fill like it was not used in material design for a reason. Flex is really saving the day here. Grid lists should probably be in main react-toolbox
@wtgtybhertgeghgtwtg, @dlebedynskyi
Of course, you can make UI without grid sistema but 12-columns grid system is more EASY and FLEXIBLE than manual layout design and MD have included the spec for it.
Take a look: https://material.google.com/layout/responsive-ui.html
There are 2 important sections: BREAKPOINTS and GRID.
I agree with victor.
The md spec has a nice way of doing it.
I used it with polymer a year ago and it was very nice because it's baked into polymer and just works.
On Mon, 11 Jul 2016, 19:35 Victor Molano, notifications@github.com wrote:
@wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg, @dlebedynskyi https://github.com/dlebedynskyi
Of course, you can make UI without grid sistema but 12-columns grid system is more EASY and FLEXIBLE than manual layout design and MD have included the spec for it.
Take a look: https://material.google.com/layout/responsive-ui.html
There are 2 important sections: BREAKPOINTS and GRID.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/react-toolbox/react-toolbox/issues/626#issuecomment-231806570, or mute the thread https://github.com/notifications/unsubscribe/AAJgKq9W2zzEOaIzPwCwYCMhoW2qQp7Xks5qUn7KgaJpZM4JI21K .
@javivelasco what do you think?
I agree for the grid-system. Currently we're using react-grid-layout, which integrates pretty well with React-Toolbox ; maybe something to take inspiration from ?
concerning suggestions, can it be that there currently only is a iconMenu? No popover/menu with just text? So you can click text and it will open a menu? If not, that would be very nice as well.
Adding a grid will make the effort to migrate bootstrap sites to RT much simpler.
It looks like everybody is claiming a grid! I agree with you, it's useful, but there are some tools to make a custom grid with just a few lines. I'm using at work lost.io and it's really easy. You just define your CSS grid, postcss adds the styles and you can just require the CSS module and add the classes you've defined with divs or whatever you choose (because you shouldn't use always wrapper divs!).
I personally do not miss a grid usually but I think it could be cool to define one fitting MD spec. I'm adding it to the list and it should be top priority.
@vmsoftware Thank you so much! I agree with you, the light theme should come. I hoped somebody to work on it, it shouldn't be difficult just changing variables. I wouldn't make a switch as it is, usually you have one theme or another but it's easy stuff. Responsive components are really important as well, I'm going to track it with an issue to study components that fit just anywhere and components that actually need some changes.
@JeroenNelen Did you try to create a custom component opening a Menu? It should be pretty straightforward if you check the IconMenu
component code.
@javivelasco, about "somebody to work on it"... I'm absolutely ready to work with you. let me know how can I help you and I'll make it with pleasure.
I'm happy to read it! I'm scheduling a little and right now I'm working on the PostCSS migration. I have some ideas for the website playground and the integration process that are going to give the final touch to make react-toolbox the easiest ui-kit to configure and customize.
My idea is to open issues to track components development from here and to use this thread as a way to keep up with people requests. As soon as we migrate to PostCSS we are opening issues for each component and tracking the progress from there. Anyway if you want to start already to draft an implementation or gathering ideas from already-implemented components it would be great :)
I agree that getting full responsive support with a Material compliant grid should be #1 goal, mobile is just too important. I would also say that non-compliant Material spec components should not be in this library. Finally, there are a couple of key spec'ed components that are missing and key for mobile.
Bottom Navigation Bottom Sheets
Also, where is support for Subheaders?
Great package and keep up the good work!
New components should probably be second to #565, if only to avoid doing things twice.
@skirunman I think BottomSheets
were already added but I moved it to the spec components list. Subheaders look like a very small component for me. Lists for example already supports them. Probably each component able to have them in context should has its own.
BTW, new components would have to wait for #666 as @wtgtybhertgeghgtwtg said!
I didn't actually read this before making the datepicker accept keyboard inputs. So hopefully #704 is suitable for DataPickerInput component used to parse text and control the DatePicker as discussed here
What about navigational transitions? Although that might take some work on figuring out how to play nice with react-router
.
+1 for bottomnavigation and bottomsheets.
I would add, expand-collapsable lists (already available in material-ui), spec here: https://material.google.com/components/lists-controls.html#lists-controls-types-of-list-controls
And fullscreen dialogs, spec here: https://material.google.com/components/dialogs.html#dialogs-full-screen-dialogs
Also, having the hide-on-scroll behavior for the navbar would be great! (same for bottomnavigation, if/when its added).
BottomSheets
are easy to implement I think. They will come soon but first I need to finish #666 you are going to love it.
@wtgtybhertgeghgtwtg looks like quite difficult stuff but 😍 Now I want to implement a test with dialogs 😱
Can we have Popover ? For the moment may still need to use menu to work around it, and menu always tries to cover the trigger itself. Here are my user cases:
I implemented these using Material UI's popover, http://www.material-ui.com/#/components/popover
Yeah, some components currently implemented are going to be splitted, an example is the Menu which will be separated so you can use the ClippingBox
as a popover to be used in just any other context. First we have to update the docs and release the PostCSS version so we don't dup work.
The FAB is a tough one, since it fits into general questions about material motion and transformation. https://material.google.com/motion/transforming-material.html https://material.google.com/motion/choreography.html
There isn't really anything about the FAB that makes it different from any other transforming or moving material - except possibly speed dial, which is a simple staggered translate. The examples given in the Material docs are just examples, and I think it makes sense to keep complex animations as composable as any other component.
Should this library try to come up with solutions for material transformation, or does that belong in a separate dependency? Some animations are extremely difficult to pull off while being fast enough for mobile - a thumbnail expanding into image is the hardest problem I've tried to tackle so far, given the bad performance of anything other than translate/rotate/scale.
Is there some plan for a stepper ? Like defined here https://material.google.com/components/steppers.html
Bottom Nav is top of the list with a bullet.
Hi! Since issue about responsiveness #804 is closed in favor of this one, here is how react toolbox official website is rendred on mobile:
Responsive is part of the plan :) It will come with 2.0
The grid system isn't too much of a need for me. I'd rather have the grid list tiles with all these spiffy variations.
+1 for Stepper component
+1 for theme switcher, responsive grid, and a simple Paper
component. Navigational transitions
would also be very handy.
I'm ok for Paper
, maybe navigation transitions, but Grid
can be imported from other small projects but I guess it's ok to have one with the MD spec widths and breakpoints. Theme switcher? It should be supported just by changing a prop in the ThemeProvider. The upcoming migration will allow it!
It's ok to have Grid
outsourced. But I suggest adding some options in README and Layout examples (links to suggested grid components, examples). So that end user sees why it's not included (Separation of concerns) and how to use other libs together with react-toolbox.
I think grid
is rather pointless to implement. If you look at Play Music which is in polymer or Firebase which is in Angular, there is no grid. The grid is part of the design process, that there is consistent spacing between elements. But it doesn't materialize in the dom thanks to flex-box and that most components are opinionated about their width.
I do need stepper for the current thing I am working on. I can take a stab at it in a week's time.
I think the same. As soon as we get the migration ready there will be need for tons of examples. The documentation has to be improved showing some use cases... I usually get questions where the solution is just to tweak with some CSS.
The future playground will import files from gists to mount examples, this way anybody will be able to contribute with examples. I need some time to get it properly working :(
@javivelasco any plans on including stepper component, it exists in the Material Design specs
Yes @devarsh looks like a fun component to work on. Just added it to the list
@izakfilmalter @devarsh @javivelasco: We have built a stepper component that we're using with react-toolbox. Currently not so much documentation but will add some soon. An example is present though.
That's so cool @drager ! Feel free to send a PR to add a link in the readme as related projects/additions
@javivelasco: We need to get some better documentation for it first I think. But after that we can fix that :)
Writing documentation took a bit more time than one might prefer but I finally pushed at least some initial examples and API docs. In terms of material design and react-toolbox, what's currently there is basically the mobile steppers but we are interested in adding more. If anyone would like to contribute parts of the other steppers that would be great!
For components that are outside the spec, PaperScrollHeaderPanel, Timeline, Stepper, etc. what is the separate repository that these components will be placed in?
There seems to be quite a few different repos available, and was wondering if react-toolbox
had a dedicated repo for this?
https://github.com/MaximKomlev/react-toolbox-additions https://beanloop.github.io/react-step/ mentioned above by Pajn
There are also quite a few different Grid components and links mentioned above. Is there a conclusion as to what react-toolbox would be implementing?
Any chance to see Grid in nearest release or any plans to add it? If not, what's the best alternative? Thnx
hey :smile: I noticed that you're working on (or, at least, thinking about) building a Stepper. The react-ui-roundup has a lot of other examples of Steppers that might be interesting or useful points of reference to you while you're developing it for react-toolbox.
https://react-ui-roundup.dimitrimitropoulos.com/#Stepper
Tip: if you view from the website you can open click
OPEN ALL IN NEW TABS
and see them all at once.
I'd like to list in this issue components that are wanted but not implemented yet. I'd distinguish two kind of components: defined by the spec but not included/not defined by the spec, but useful and implemented by other frameworks.
From the spec
Grid
components as specified hereFAB
as discussed hereBottomNavigation
as documented hereBottomSheet
Implemented by Angular Material hereStepper
as specified hereOut of the spec
PaperScrollHeaderPanel
implemented by Polymer hereTimeline
defined by @dlebedynskyi hereFAB
Circular loading indicator as detailed hereDataPickerInput
component used to parse text and control theDatePicker
as discussed hereI want to use this thread to discuss if components out of the spec should be created in a separated repository (react to this post with 👍) or inside the same repository under a different folder (react with 👎 ). I'm more with the first approach. Also the list can be used to track the progress and to hold references to other issues and PRs where the components are developed.
Consider this kind of a roadmap of new components. Make your requests replying to this instead of opening new issues.