Multiselect - select2 support

[Gytjarek]

How should we handle support for select2? We could install the react-select library, but styling it isn't as straightforward. Do you have any better ideas @robmarshall ?

[robmarshall]

Guessing this would be used alongside the multiselect/drop down field?

Gravity Forms does not provide select2 as default on their end - and it could be restricting to force users to use a certain way of styling their inputs when we do not know their use case. Especially as there would be no option within the GF settings to turn this on/off.

Thinking outloud...

I wonder if we create a separate component can be imported from the package and passed into the form. That way users that don't want the functionality don't get the additional weight on their site. This would allow different ways of showing the data in a flexible way.

react-select looks like a good idea. We can use the unstyled prop, and then use a base classname to give a class to provide the styles to. Styling would be up to the end user - but we can include examples of these either in an examples folder in this repo - or I can update the example repo: https://github.com/robmarshall/next-gravity-forms-example with the needed CSS.

[sjaakbanaan]

I'm currently working on this. Don't you think the unstyled prop should be optional (and defaults to true)? The default style is already pretty basic and also inherits your font-family for example. I do agree a user should be able to fully style it him/herself, but fully getting rid of it seems a bit much, because i can imagine there are situations where devs are ok with the default style and don't require customisation. What do you think @robmarshall ?

[robmarshall]

Happy New Year @sjaakbanaan!

I can see where you are coming from, however the Next gravity Forms package does not provide any default styling for any other inputs. If we include specific stylings for just the select box it means the user has to overwrite, rather than build from scratch. This could lead to excess CSS.

Additionally, the default "styled" setting has focus colours and select states that are not particularly "native".

By making hardcoding unstyled it means that the experience will be consistent across all installs. It also means no extra work when/if the package maintainers change the default styling.

The unstyled select component is still "usable", just not opinionated: https://codesandbox.io/p/sandbox/react-select-example-forked-ny84qk?file=%2Fexample.js

As long as there are specific CSS classes set up for the different states and we provide a default CSS setup that can be easily copied then this should be the cleanest path. Example of adding state specific classes: https://github.com/JedWatson/react-select/blob/master/storybook/stories/ClassNamesWithTailwind.stories.tsx

[sjaakbanaan]

Ok makes sense! And happy new year to you too :) We're working on multiple issues btw (15, 16 and 17), but hard to say when we'll create PR's for them since we want @Gytjarek to double check our work before we present it as a PR, and he's off this week.

[robmarshall]

@sjaakbanaan No worries. I am happy to give feedback if it helps.

[sjaakbanaan]

I think this one can be closed now?