react-toolbox Future components / wishlist

Future components / wishlist

Open javivelasco opened this issue 7 years ago • 45 comments

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 here
[ ] FAB as discussed here
[ ] BottomNavigation as documented here
[ ] BottomSheet Implemented by Angular Material here
[ ] Stepper as specified here

Out of the spec

[ ] PaperScrollHeaderPanel implemented by Polymer here
[ ] Timelinedefined by @dlebedynskyi here
[ ] FAB Circular loading indicator as detailed here
[ ] DataPickerInput component used to parse text and control the DatePicker as discussed here

I 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.

Jul 10 '16 15:07 javivelasco

@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:

Make a .row class with 100% of width.
Take 100% and divide between 12 then each columns have 8,3333333333% of width.
Make CSS classes for 1,2,3,4,5,6,7,8,9,10,11 and 12 columns like col1, col2, col3.... col12. (8,3333333333% * column number). for example
Make mediaQuerys for .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

Jul 10 '16 18:07 vmsoftware

+1 out of the spec should be created in a separated repository, but in the same organisation.

Jul 10 '16 22:07 ghost

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

https://material.google.com/components/menus.html#

Jul 11 '16 14:07 kossel

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

Jul 11 '16 16:07 wtgtybhertgeghgtwtg

@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

Jul 11 '16 16:07 dlebedynskyi

@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.

Jul 11 '16 17:07 vmsoftware

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, [email protected] 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 .

Jul 11 '16 18:07 ghost

@javivelasco what do you think?

Jul 12 '16 05:07 vmsoftware

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 ?

Jul 12 '16 14:07 thomasnaudin

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.

Jul 13 '16 07:07 JeroenNelen

Adding a grid will make the effort to migrate bootstrap sites to RT much simpler.

Jul 16 '16 13:07 abigtoe

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.

Jul 16 '16 18:07 javivelasco

@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.

Jul 20 '16 01:07 vmsoftware

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 :)

Jul 20 '16 07:07 javivelasco

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!

Jul 22 '16 03:07 skirunman

New components should probably be second to #565, if only to avoid doing things twice.

Jul 22 '16 11:07 wtgtybhertgeghgtwtg

@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.

Jul 24 '16 10:07 javivelasco

BTW, new components would have to wait for #666 as @wtgtybhertgeghgtwtg said!

Jul 24 '16 10:07 javivelasco

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

Aug 10 '16 23:08 ro-savage

What about navigational transitions? Although that might take some work on figuring out how to play nice with react-router.

Aug 24 '16 02:08 wtgtybhertgeghgtwtg

+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).

Aug 24 '16 06:08 acornejo

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 😱

Aug 24 '16 18:08 javivelasco

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

Sep 02 '16 00:09 neekey

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.

Sep 02 '16 07:09 javivelasco

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.