Render Components Only If Available

[tahierhussain]

What

Some of the components may or may not be available in the FE repo. For such cases, we need to gracefully handle it in the UI if the components are not available.
...

Why

We need to handle the UI if the components are not available.
...

How

Using try-catch to import the component or ignore (if not available).
...

Relevant Docs

NA

Related Issues or PRs

https://github.com/Zipstack/unstract-cloud/pull/5

Dependencies Versions / Env Variables

NA

Notes on Testing

Tested it by building the FE with and without the plugins folder. Below are the screenshots for both the cases (Please check the URLs as a proof of the builds),

1. FE without the plugins folder:

2. FE with the plugins folder:

...

Screenshots

Please refer Notes on Testing for screenshots.

...

Checklist

I have read and understood the Contribution Guidelines.

[hari-kuriakose]

@tahierhussain LGTM overall.

However, I still see references to plugin functionalities in FE code. Take eval metrics for example - sortEvalMetricsByType function, evalMetrics variable, etc are still present outside of plugins.

Can we move all such references across all plugins to the plugins folder itself?

[hari-kuriakose]

@tahierhussain Can you also please confirm if the build process succeeded with and without plugins, under Notes on Testing?

[tahierhussain]

@tahierhussain Can you also please confirm if the build process succeeded with and without plugins, under Notes on Testing?

Done, @hari-kuriakose

[tahierhussain]

@tahierhussain LGTM overall.

However, I still see references to plugin functionalities in FE code. Take eval metrics for example - sortEvalMetricsByType function, evalMetrics variable, etc are still present outside of plugins.

Can we move all such references across all plugins to the plugins folder itself?

@hari-kuriakose I have made further changes and moved the logic/functions to the plugins folder.

However, in some cases, it won't be easy to avoid references to eval*. For example, we retrieve the eval results from the prompt run API, which is called inside PromptCard.jsx (a regular component). So, the evalMetrics variable will be referenced, and it will be difficult to avoid. It will still be possible if we smartly handle this case, but after I discussed this challenge with @arun-venkataswamy, he told me that having references to it in the code won't be a problem.

[hari-kuriakose]

@tahierhussain LGTM overall.
However, I still see references to plugin functionalities in FE code. Take eval metrics for example - sortEvalMetricsByType function, evalMetrics variable, etc are still present outside of plugins.
Can we move all such references across all plugins to the plugins folder itself?

@hari-kuriakose I have made further changes and moved the logic/functions to the plugins folder.

However, in some cases, it won't be easy to avoid references to eval*. For example, we retrieve the eval results from the prompt run API, which is called inside PromptCard.jsx (a regular component). So, the evalMetrics variable will be referenced, and it will be difficult to avoid. It will still be possible if we smartly handle this case, but after I discussed this challenge with @arun-venkataswamy, he told me that having references to it in the code won't be a problem.

@tahierhussain Yes, the aim is to move all "defnition" references inside the plugin, leaving only "usage" references at max in the OSS code. This seems to be mostly achieved now, which is good enough.

[hari-kuriakose]

@tahierhussain LGTM overall.