Improve catalog properties modal tables

[mkralik3]

• Tabs in properties detail modal
• Add headers and api properties for camel components
• Add filter to distinguish between path and query property
• Show more tables in one modal page
• Refactor/generalize filter to use them in all functions (all properties in getTableFromProperties functions can be filtered by IPropertiesTableFilter = { filterKey: string; filterValue: string }
  e.g. get only properties which have kind="path", pass filter like this into function

{
  filterKey: 'kind',
  filterValue: 'path',
}

• Refactor prepareDataForTabs function (lots of spaghetti code there, can be generalized or divided into small pieces)
• fix and add unit tests
• add additional info into table row structure ( e.g. required will be a part of description as in the documentation)
• alignment all tabs style with camel catalog page
• add autowired / enum into description as in camel catalog, e.g.( https://camel.apache.org/components/4.0.x/aws2-ddbstream-component.html )
• go through all catalogs to quickly check that everything looks correct ( Set<..> are not shown correctly as type, will be resolved as part of the next PR, also Maybe a tooltip with the full name of type will be beneficial Invalid type of properties in properties table when diamond operator contains dot #61 )

[mkralik3]

Camel components:
Component properties tab:

Properties tab with two tables according to kind

Headers

API*[1]

No prop in kamelets

[1] - More information about API's are out of scope of this PR, API parameters have more methods with more properties, so the expendable rows with sub-rows needs to be implemented, at least with 3 level (apis->methods->methodParameters) ,, see AS2 or Twilio component => #60

[lhein]

Can we put some blank space between the description of the component and the tabs for the properties tables?

[mkralik3]

@lhein sure, I am currently working to add there also Enum and Autowired info

[mkralik3]

done,

the Doc page: https://camel.apache.org/components/3.21.x/aws2-ddbstream-component.html#_component_options

[mkralik3]

hm I don't understand why GitHub shows This branch has conflicts that must be resolved , since this branch is up to date and rebased with main

and when i create a new PR, GitHub is able to merge it automatically 🤷

Maybe it will be gone after next rebase with main.
But it doesn't matter. Once this PR will be approved, I will created another one [if the github still refuse merge this one] or merge it manually.

[lordrip]

The thing here is that it will make the calculations on every render. It would be more convenient to store the tabs object using a useState hook and then update it using a useEffect that depends on props.tile.type.

The idea would be more or less something like this:

const [tabs, setTabs] = useState<IPropertiesTab[]>([]);

useEffect(() => {
  //  switch logic goes here

  // store the resulting calculation like
  setTabs(CALCULATED_TABS_HERE);
}, [props.tile.type]);

Also, is worth mentioning that unless we plan to reuse the returning array, it would be more convenient (IMHO) to return an array from the function, rather than providing one from the outside.

let tabs: IPropertiesTab[] = [];
transformCamelComponentIntoTab(tabs, props.tile.rawObject as ICamelComponentDefinition);

// vs 

const tabs = transformCamelComponentIntoTab(props.tile.rawObject as ICamelComponentDefinition);

[mkralik3]

Tabs are in a different component, there is no re-render in the modal component However, of course, it can be some in the future so I will move it into useEffect() .

[mkralik3]

@lordrip Isn't there better to use useCallback / useMemo hooks in this case?
Because useEffect is running only after the component is rendered, so, for the first time, the empty table is shown for a few milliseconds (because the table is null for the first rendering). [Also with opening a different camel component, for milliseconds, the table from the previous component is shown ]

In other words, in this case, the computation is needed before the first rendering.
e.g.
https://github.com/KaotoIO/kaoto-next/blob/0fa042ad24b9cd08126d25255e76b682ffbaf238/packages/ui/src/components/PropertiesModal/PropertiesModal.tsx#L20-L38

I have tried to re-render the modal component (via useState and button) and the switch computation is not running before the modal is open again ( with a different camel component ) so it is working correctly.

[lordrip]

You're right, let's go with your approach then 💪