Add maxWidth Prop

[gojohnnygo]

This PR adds a maxWidth property to fix JedWatson/react-select#1127.

[MilllerTime]

Looks like a very useful addition! However, maxWidth can only be set to a number of pixels, correct? A value like "100%" wouldn't work judging from the code. In my experience, many inputs are placed within variable width blocks, where a CSS declaration of max-width: 100% keeps an element contained in its block while maintaining fluidity at a higher level.

React-select also happens to be a block-level component. Since this PR is primarily aimed at fixing the bug you mentioned (which would be awesome!), how would you implement maxWidth with react-select? Would it just work. or would it require constraining the width of the react-select component as well? In my use cases I need react-select to be a full-width block in a responsive container, which might even be the norm.

If I'm not missing something, would it make sense to accept a standard CSS length string and pass it into a max-width style somewhere vs. just comparing numeric measurements with JS?

This would surely be inconsistent with the current handling of minWidth, but perhaps that could be implemented the same way. Thoughts?

[gojohnnygo]

@MilllerTime Good points. I'll take another look next week.

[MilllerTime]

After fiddling with the max-width CSS property, it seems there may be an issue going that route: the fact that react-select uses display: table for its internal layout. At least from my testing in Chrome, max-width: 100% does not play nicely with the table layout, and is ignored.

I still think it would be a great addition to react-input-autosize, but I'm not sure how to fix the referenced issue with react-select while maintaining fluidity 🤔

Damn tables.

[gojohnnygo]

The path to least resistance (if react-select is responsive) may be passing in width via JS on resize. 🤷

[MilllerTime]

Haha yeah, I was just really hoping this could avoid an onResize and the extra dependency/wrapper element of something like react-dimensions.

Perhaps that is the way forward until flex layout works everywhere. I'll keep thinking about it.

[JedWatson]

@jossmac do you have any ideas on the best approach here?

[jossmac]

@JedWatson All good points!

I like the idea of moving React Select to a flexbox layout; support is a lot better than it was 2 years ago when we started the project http://caniuse.com/#feat=flexbox

I'm not 100% that it would solve the issue at hand, but a solution can't be fair off. Type into this pen - you can see that Chrome tries to keep the cursor in view, but it's a bit jumpy.

Happy to pair on it when you're free next.

[MilllerTime]

@jossmac @JedWatson Moving React Select to flexbox would surely be awesome! As you noted, support is pretty good these days, but my guess is that shoddy IE support (and no support for IE 9) might be an issue. I for one currently need to support IE9 for basic functionality. Additionally Redux, for example, is only now looking to drop IE 8 support. IE9 seems to still be on the table.

Support aside, I do believe flexbox will solve the issue at hand! As I see it, the problem we're trying to solve is preventing an input element from growing too large in the first place - elegantly handling an input that is too large seems like a difficult thing to do. Here's a pen with a greatly simplified version of what React Select is doing, in both display: table and display: flex flavors. For the examples, I'm using a <textarea> because it's easy to interactively change the width and see how the layout reacts.

As you can see, flexbox is bulletproof, and still allows very easy centering of icons at variable heights (I imagine that was one reason React Select used table layout at all). If we're entertaining the idea of flexbox layout, might it be feasible to feature-detect support and switch to a flexbox layout automatically when supported?

[JedWatson]

Since this is pretty old, I'm going to close it. Styles can now be overridden, which makes flexbox use possible, and we're planning to update react-select to use in in the next major version too 👍