clean up component folder structure + move components out of the `app` package

[pngwn]

Get the components out of the app. This is the really disruptive part, so I want to keep it simple conceptually.

• No more weird wrappers, everything will be in the core component in its entirety.
  • There was a reason for doing things the way we are currently but it was wrong decision. I thought we should separate the app logic from the component logic but they are inherently linked anyway and all it did was serve some possible future usecase without really addressing our needs.
• create a 1-2-1 relationship between gradio component s and component packages.
  • The current situation is confusing when you are working across the python and javascript
• create a new folder structure inside each package that will contain different component variants
  • /interactive/ this will contain the interactive variant of a component - optional - static used when not present
  • /static/ this will contain the static variant of a component - mandatory
  • /example/ this will contain the preview variant of a component - optional - fallback used when not present
  • We will also need a @gradio/fallback package which we defer to in certain cases.
  • This paves the way for custom components but also brings some order to what is currently quite confusing. Every sub folder will have an index.ts that exports the correct component. The components can be called anything. We won't explicitly use these subfolder for now (we will have an index.svelte in the root) but will be cleaned up in a future refactor. /preview/ will be empty for a short period of time.
• Certain things will just be passed down as props for now (like the i18n helper), this may change in the future but don't want to overthink.

This will get closed when all of this work is done. tracking issue for the first part:

• [x] #5006

[abidlabs]

Nice @pngwn!

I wonder if we should make static the required one and interactive the optional one that uses static as a fallback. As far as I understand it, some components can be used as outputs but not inputs (e.g. JSON or Markdown or Label) -- so they would support a static mode but not an interactive one?

[pngwn]

Ah that's a good point, yeah maybe that makes more sense!

[pngwn]

Well they can be used as inputs but they don't do anything (just emit a change event when the content changes), so this definitely makes sense. Will update.

[abidlabs]

Oh and this might be a minor point, but this is probably best time to bring it up -- can we rename the component modes "input", "output", and "example" instead of "interactive", "static", and "preview"? Naming doesn't matter if we're using these internally but since we're planning on letting users contribute custom components, this naming would be more intuitive (since they're already familiar with inputs/outputs) and be one less thing to remember

[pngwn]

Well, the only reason that might not make sense if you can use interactive as output and static as input if you want to. Since blocks, those distinctions aren't as clear any more.

I wonder would a new user have those distinctions or is this an interface-centric interpretation? SO users who are familiar with gradio pre-3.0 might think that way but does it still translate.

The real distinction between interactive/ static is interactive can accept user-input + responds to that input whereas static does not, but that doesn't dictate their relationship to input/output in gradio itself.

[abidlabs]

Well, the only reason that might not make sense if you can use interactive as output and static as input if you want to. Since blocks, those distinctions aren't as clear any more.

Good point, okay let's leave it as is then!

[freddyaboulton]

Chatted with @pngwn this morning about this refactor. Here is what we discussed.

The work will be split between two PRs.

The first PR will solely reorganize the component directories to match the structure mentioned in the original comment. The current code component follows this structure (except for /static/ /example/). There will have to be an Index.svelte file for each component that delegates between static and dynamic modes based on props. This should mostly unblock @abidlabs and @hannahblair to make improvements to the components.

The second PR will refactor Blocks.svelte so that components can be loaded dynamically based on props, e.g. the static, dyamic, or preview versions of each component. This will be the same infrastructure used for dynamically loading custom components. @pngwn Will take this opportunity to write some unit tests for Blocks.svelte. It might also be possible to do this work piecemeal (at least in batches).

We may need a separate metadata folder or something like that for internationalization and other misc functionality

[abidlabs]

Thanks @freddyaboulton @pngwn, sounds like a plan!