Geocoder Combox in WeGue3 is no longer able to adjust its size

[bhubergeomer]

The Geocoder combobox in Wegue2 was able to adjust its size according to the available space in the toolbor.

In WeGue3 the width is hardcoded to 320.

Is it possible to reestablish the dynamic width?

[chrismayer]

Hi @bhubergeomer, thanks for reporting this. I can confirm the described behavior.

Indeed it would be better to have something like a min-width on the v-combobox component level. Then you could adjust the width by CSS with

.wgu-geocoder-combo {
  width: 500px;
}

which is not possible at the moment.

Would you be willing to bring up a Pull Request for this @bhubergeomer ? The change should really be easy by changing this line to min-width="320". Would be very appreciated.

[bhubergeomer]

Hi @chrismayer !

If i change to min-width the combobox looks fine and shows with the size of min-width, but it is not able to dynamically set its size according to the space available.
The Wegue2 version had a "flex" behavior, it gets smaller if there is little space.

In Wegue3 it was either the with of width paramter or of min-width parameter. It does not adjust its size. Some elements of the Combobox DOM have display: grid.
May this be a hint?

[sronveaux]

Hi @chrismayer, hi @bhubergeomer,

Well, this one is more complicated than it sounds at first as behaviour in Vuetify2 and Vuetify3 are really different with this one. I'll try to summarise what can be observed:

In Vuetify2, the combobox had some kind of flex behaviour but with some limits as can be seen in the following screenshots taken fullscreen and with the screen diminished in size as much as possible:

Moreover, if you type even a single character inside the combobox, this size is changed:

As you can see, it takes more space if even a single character is input but doesn't take all the remaining space. Moreover, the size it takes is influenced by the focus status which we'll not consider here.
Please note the snapshots have been taken with default Wegue app running inside Firefox.

There was no properties on the component to change its size in Vuetify2 except the full-width one.

In Vuetify3, default behaviour is completely different. Here's what you get:

The empty combobox will be too short while and for sure it will take as much space as needed once filled. However, you now have some properties to constrain the size or give it a min and max size.

While porting to Vue3 and Vuetify3, it was at first constrained to a fixed size to avoid this and to limit another problem linked to the title written in the toolbar which was cut off when the combox took more space even if some free space was still available:

I just wrote a small PR correcting the latter problem (#440) and giving a proposal to set a min and max size to the combobox which would then come really close to what could be observed in the previous version using Vuetify2.

Can I kindly ask you to try this PR and give your impression ?

P.S.: The grid you saw on some DOM elements is linked to the new approch used inside Vuetify to render the prepend and append slots on the v-input components. Perhpas this has an influence but there's no way to get rid of these...

[bhubergeomer]

Hi!

The above improvement set the size to min-size and it will expand if a long text is entered.

Do you see a possibility to accomplish the old behaviour "combox initially takes a wide size and will shrink if there is little space" ?

[sronveaux]

Hi @bhubergeomer and thanks for your comment.

I see what you mean but I must admit I don't see how to do it in a clean way (at least for now...)

There is a hacky way which could fulfill your needs but I would personally not include it in the codebase and amend the PR with it.

I attached the Geocoder.vue amended with the hack. However, I had to rename the file as .vue extension is not accepted by GitHub. So you just have to rename it and replace the file in the src/components/geocoder directory.

Geocoder.txt

Please give it a try and tell us whether it suits your needs, then we'll see with @chrismayer what we'll do and choose whether it should be included or not in the PR...

[bhubergeomer]

Hi @sronveaux!

I tried your hacky way and it looks good. It shows the behaviour i want to have.
Thanks for the code lines!

Are there any downsides or risks, i my test it looked pretty good.

[sronveaux]

Hi @bhubergeomer and thanks for the feedback!

Well, this very simple request is in fact quite complicated to give an answer as it has implications at multiple levels...

Are there downsides or risks... the main problem comes from the fact that we have to tamper with internals of Vuetify to do this.
Following Material Design specifications, current behaviour is more conform as the toolbar items should take the minimal needed space and not the maximal one. One could argue that Wegue doesn't follow the rules anyway as the items should contain only icons and no more than three which is true...

The risks I personally see are that:

1. It could break with forthcoming Vuetify updates
2. Whether it works as expected or not depends on what a user puts inside his toolbar. If you have only icons and the Geocoder (which is certainly the majority of use-cases) it will work as you experienced, but if people add other components inside the toolbar, there could be conflicts with those other components.

These are the main reasons why I'm personally reluctant to add this in Wegue codebase and would let users adapt if needed.
Another reason is that Wegue's intent is to be lightweight and avoid to be feature creep. The Geocoder is already one of the source components which has the most complicated configuration object. Should it be complicated more ?
On the other side, Wegue philosophy is that you should write your own code in the app directory and try not to modify code inside the src one. But as Geocoder is part of src what should be done ?

I'm only a collaborator on Wegue and won't take a decision about this one, but I have to say I'm personally not in favor of implementing it. However, it's open for discussion...

To conclude the comment, please understand that PR #440 will not implement this. But it could be in another PR afterwards... if #440 is accepted in its current state, one cleaner way to implement what you'd like to see afterwards would be to add a new configuration boolean option called something like fullWidth and to then use state-driven dynamic CSS to keep in sync the max-width of the v-combobox component and the max-width of the .full-width CSS class... that's, from my point of view, the minimal requirements to have something clean and stable enough to be included in the codebase.

[fschmenger]

I just compared the behavior to google maps, which uses a fixed size search bar. So I don`t see anything wrong with it. Maybe the default size (at least for larger breakpoints) could be a little bit wider, e.g. like ~350px ?

[sronveaux]

Completely agree and don't see anything wrong with current implementation neither. No problem I think to make this a bit wider as you suggested, except if it becomes problematic on mobile phones for example. I have to admit I don't have real experience with Wegue on responsive devices so can't give a pertinent advice for this one and rely on others there...

I don't see why it would behave badly though as this would be the max size which would be defined. The component should shrink itself if there's not enough room for it.