Application settings management

[rohinp14]

No description provided.

[linux-foundation-easycla]

• ❌ - login: @rohinp14 . The commit (5d4b65b, 7ac4ca0, 16b3cf9, d1b0d92, d5d1d62, f90c1d4, cf69cc4, 1e9f2d5, 1f09020, 3ec3d08) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[netlify]

✅ Deploy Preview for papaya-valkyrie-395400 canceled.

Name	Link
🔨 Latest commit	1f09020
🔍 Latest deploy log	https://app.netlify.com/sites/papaya-valkyrie-395400/deploys/667d497a257407000827c143

[heswell]

naming conventions - files that contains a UI component or a class should be named to reflect the component name exactly, so ApplicationSettingsPanel.tsx exports the component ApplicationSettingsPanel.
An associated css filr follows the same naming, so we would have ApplicationSettingsPanel.css

Files with other content begin with lowercase. I generally create a somenameTypes.ts file if I find I'm amassing a large number of TypeScript definitions which are obscuring the actual code ina. file, then I might create such a file to contain all the shared types across multiple files e.g layoutTypes.ts, listTypes.ts.

In this case, we only have a small set of Type definitions, I'd suggest we just keep them within the ApplicationSettingsPanel.tsx file.

[heswell]

needs to accept the current value of the properyy, which will come from the applicationSettings prop

[heswell]

splitting the component into two (ApplicationSettingsPanel/SettingsForm) is a good idea, they will likely grow in complexity.

The SettingsForm should go into its own file. Sometimes I host more than one UI component in the same file if they are really tightly coupled, but not often. If we might ever want to use the SettingsForm in its own right, for example (and I think we might) then it definately warrants a file of its own

[heswell]

we want the SettingsForm itself to deal with the differences between the changeHandlers of various different form controls. I'd suggest the SettingsForm can take exacctly the same props as ApplicationSettingsPanel for now.

So, the SettingsForm could look something like this,

export const SettingsForm = ({applicationSettingsSchema, applicationSettings, onSettingChanged }) => {

const selectHandler = useCallback((evt, [selectedValue]) => {
const propertyName = getPropertyNameFromElement(evt.target)
onSettingChanged(propertyName, selectedValue)
),[])

const changeHandler = useCallback((evt) => {
const propertyName = getPropertyNameFromElement(evt.target)
 const value = getTypedValue(evt.target, propertyName, applicationSettingsSchema )
onSettingChanged(propertyName, value)
),[])
}

  return (
    <div>
      {applicationSettingsSchema.properties.map((property: string | number | boolean) => (
        <FormField data-field={property.name} key={property.name}>
          <FormFieldLabel>{property.label}</FormFieldLabel>
          {getFormControl(property, changeHandler, selectHandler)}
        </FormField>
      ))}
    </div>
  );