feat(@clay-components): Localized Input

[kresimir-coko]

Issue: #2894

Hey @bryceosterhaus this is a draft for the Localized Input component, so far the only functionality it has is the selecting of languages in the dropdown. I've been investigating the implementation in DXP to try and understand the demands but so far most of the props defined there seem obsolete, but I might be mistaken.

I'm unsure of how the implementation in DXP handles a lot of it's logic, and how exactly the component is supposed to function. I assume the translated values are supposed to be in the availableLanguages object provided by the user and then displayed under the input when the user chooses a language.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[bryceosterhaus]

Hey @kresimir-coko, sorry I didnt get time to properly go through this PR today. I got caught up in some other tasks and forgot about this.

As far as design goes, I wouldn't worry too much about what people are doing in portal quite yet since its possible that the existing implementation isn't the best design for a library.

From a cursory glance at the component I would imagine a controlled API that looks something like a select + an input.

<ClayLocalizedInput
     languages={array_of_languages} // {label, value, symbol} type structure for each language
     selectedLanguage={selected} // {label, value, symbol}
     translatedValue={translatedValue} // value for the selected language + inputValue
     onLanguageChange={setSelected} // callback function 
     onChange={setInputValue} // callback for input
     value={inputValue} // input value
/>

Let me know what you think

[kresimir-coko]

@bryceosterhaus I like your API proposition, makes sense. It led me to do some deep investigation of how the component works. I fired up a portal instance, checked where their version of the component is used and reached a following conclusion:

The way it works

It allows the creator of some content to define custom localized values for their content, e.g. a title.

Default state

• Input Field is empty
• DropDown has everything untranslated except the default language’s value

Selecting a language

• When an untranslated language is selected:
  -- the Input Field gets reset
  -- The previously selected language’s value get’s updated, making it “translated”

Example of UI in use before adding any translations

[jbalsas]

Hey @kresimir-coko, I'd say we don't need to implement the Locale change business logic here. As I said, it would be good to look at the whole integration path to understand a little bit how to model the API and components here to make our lives easier down the road. As @bryceosterhaus said, though, we should also only put here what makes sense for a library API. Those 2 things shouldn't be at odd, we need to find a proper balance.

In this case, I'd imagine something like:

[@clayui/input-localized]     [liferay-portal/taglib-clay]     [liferay-portal/taglib-clay]
    ClayInputLocalized    <-        InputLocalized.js        <-   InputLocalizedTag.java

Where you could imagine something like:

export default function InputLocalized({inputName, locales, selectedLocale, values}) {
    return (
        <div>
            <ClayInputLocalized
                locales={locales}
                onLocaleChange={onLocaleChange}
                selectedLocale={selectedLocale}
            />
            
            {locales.map(locale => 
                <input name="{`$inputName_${locale}`}" type="hidden" value="{values[locale]}" />
            )}
        </div>
    );
}

[kresimir-coko]

Hey @jbalsas does that mean the selectedLocale={selectedLocale} would just change which language icon is shown on the DropDown trigger, and onLocaleChange={onLocaleChange} would just set the selected locale to whichever one was clicked. Is that all the functionality the component is supposed to have?

In the API you proposed, the developer would define their own onLocaleChange function, and the state for the selectedLocale?

My next steps were:

1. Handle the default language's value, as it's supposed to match inputValue
2. When a new language is selected and inputValue is changed, put that value into the selected language's value

But that can all be left to the developer using the component? I just need to make sure that his callback functions get called with proper arguments?

If that's the case, I think I'm starting to understand this pattern we have in Clay.

[jbalsas]

Hey @kresimir-coko, I know you've read it, but I'd re-read our Clay Foundations again in light of this conversation.

In a nutshell (@bryceosterhaus or @matuzalemsteles can correct me), I'd say:

• Focus on the Low Level components and Composition first.
• Provide High Level components only when the abstraction is clear and makes sense
• Leave complex business logic out of the components to maximize reusability (but think about how it will need to be implemented to provide ergonomic APIs and components)

[kresimir-coko]

So in this latest commit I've tried to bring it down a bit and change my approach. I've taken some inspiration from the DualListbox component to achieve that. Most prominent change is the that I've made the connection between the usage and implementation like this:
Usage:

<ClayLocalizedInput
	defaultLanguage={languages[0]}
	languages={languages}
	onLanguageChange={(languages: Array<any>) => {
		setLanguages(languages); // updates the languages array with the updated array with new value
	}}
/>

Implementation:

<ClayDropDown.Item								
	key={language.label}										
	onClick={() => {											
		setSelectedLanguage(language);											
		setInputValue(''); // resetting the inputValue to make space for new language value									
		onLanguageChange(languages); // languages = updated languages via inputValue									
	}}
>

I didn't manage to get a working example of functionality done today, my last experiment was a bust, but I have some more ideas to work with tomorrow.
The idea is to, on changing the selected language > locate the changed language > update the languages > and let the developer of the component hook their own functionality to it?
Is that low-level enough, or should the component be even more generic? I feel like with the fact that we need to have working stories I can't just not make the locale switching work.

[kresimir-coko]

Hey @pat270 can you please take a look and see if this requires any markup/css from you before we finalize the PR?

[bryceosterhaus]

updated PR #3034