-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reusage of web components in extensions limited #8281
Comments
As responded later to you in chat (when you probably already called it a day) we need to hear more explicit use cases and what exactly you want to achieve. If you give us more details about what exactly you want to achieve, we can help laying out an architecture. |
@kulmann from a cursory read it seemed like there has been basically a re-implementation of the ResourceTable for spaces in the admin-app recently, moving ResourceTable (and potentially ResourceTiles also 😇 ) to the |
@dschmidt We want to be able to reuse things from Example: backups extension that has a logic, similar to As I understand, the only way would be to move needed components to |
|
realtes to: 2714602 |
Please provide a list of components and composables (as complete as possible) which you would like to use from the files app @elizavetaRa |
@elizavetaRa @diocas can we close this issue as superseded by #9267 ? 🤔 or do you have requirements for component reusability in other cases as well? |
ping @elizavetaRa |
Background:
Developing feature rich extensions like backups extension that lists backup resources similar to web-app-files
Issue:
A lot of components from web-app-files are needed for the extension: ResourceTable, AppBar, breadcrumbs, useSort, useResourcesViewDefaults etc.
According to @dschmidt reusage of components from web can only be done from web-pkg and web-client. Moving all of these components would require also moving of their imported components, almost the whole web-app-files.
Keeping the extension inside of the web is long term also a bad solution as changes in imports would cause a lot of effort in maintainability
The text was updated successfully, but these errors were encountered: