Improve explanation for the necessity of Javascript Optimization

[DavidDTA]

Right now, the documentation says that the input element dynamically adjusts its width for "stylistic reasons". However, I can't tell what the motivation actually is from the current documentation. Is there something that would be stylistically different if the width of the input were always the maximum width that fits in the border?

[Confidenceman02]

Howdy! 👋

There are a couple of reasons why the input dynamically sizing makes sense stylistically.

• Multi select variants look a little weird when the input is width: 100%;. The input text renders below the tags instead of inline. In fact the input always takes up that space below when there is at least one select tag and it just looks a little clumsy IMO. Same thing for single select variants.

• By dynamically sizing it allows room on the right for select matches and auto complete (coming soon). This is probably the biggest reason it makes sense. The area to the right of the text is valuable real estate that can be used to enhance the usability. Having the input text take up only the width of the characters present just makes it easier to render stuff on the right.

Elm select was heavily influenced by its React cousin react-select. I did have very similar questions when I saw the dynamically sizing input but understood once I explored all the features it provides.

If you have suggestions on how I can improve the docs for this please feel free to let me know. I really wanted to put forward that it will work fine without the jsOptimize flag but that it was there in case edge cases were hit.

Hope that clears some of it up!

[DavidDTA]

Thank you for the quick response! This answers my question.

The line wrap argument makes sense. I think this means that in the non-optimized version, it will generally wrap to the next line earlier than in the optimized version. Incidentally, it looks like this advantage can't actually be seen in the optimized example since it is not a multi-select.

Regarding autocomplete, I look forward to seeing that improvement. I think it will have some difficulty in non-optimized mode because of the relatively little control we have over the input size.

In terms of documentation, I think it would be reasonable to change "For stylistic reasons" to "In order to be able to be displayed inline with other UI elements".

[Confidenceman02]

The line wrap argument makes sense. I think this means that in the non-optimized version, it will generally wrap to the next line earlier than in the optimized version. Incidentally, it looks like this advantage can't actually be seen in the optimized example since it is not a multi-select.

Precisely! Whilst the non-optimized version still dynamically sizes, as you mentioned, it will eventually wrap earlier than the optimized input.

I think it will have some difficulty in non-optimized mode because of the relatively little control we have over the input size.

Absolutely! It will definitely be a challenge getting things to look right in the non optimized version considering how the input grows. There is of course having the option to make it an optimized only feature as a first iteration. Which is why I called it jsOptimize as it's pretty generic and could include more than one type of optimization. Ideally of course I would prefer for things to be elm first.

Updated the docs in the attached PR, let me know if you feel this is clearer and it should make an appearance in the next release.

Many thanks for the feedback!