Allow Overriding of Existing Admin UI Components

[liamcsdev97]

Prelude

I encourage everyone to provide thoughts and feedback as I think this feature would greatly enhance the developer experience when working with the admin dashboard.

Related Discussion: #6324

Current Issue / Limitation

The admin dashboard shipped with medusa is a great starting point, and it provides some great defaults that work with most projects. Furthermore it provides injection zones which allows developers (both owners of source code and owners of plugins) to add custom widgets to various sections of the dashboard, thus allowing them to extend the dashboards functionality. Although these injection zones provide valuable utility, they are not enough when it comes to providing a customizable dashboard. These injection zones only allow developers to add utility and do not allow developers to modify existing components or behaviors.

I recently had a simple modification I wanted to make the the admin dashboard. In the variants section of the product details, you have the ability to add a new option. In the resulting modal, you can create a name for a new option, but you can not provide a default value. Thus, when you add the option the default value is quite literally set to 'Default Value'. Then, in order to change said value, you have to manually go through each variant and update the corresponding option value until all variants are updated and the default value is essentially renamed. I ended up creating my own utility to bulk rename option values, but that is besides the point. What is important is that my original goal was to simply replace the options-modal. The admin-ui contains all the sections, components, etc. that are used to build the default dashboard. I wanted to do the following:

1. Replicate the admin-ui folder structure in my own project
2. Copy the source code for the options-modal into the corresponding path
3. Update the component as I see fit
4. Use it as a drop-in replacement for the existing options-modal.

Unfortunately, it proved too inconvenient to justify seeing in through. The first reason is that the admin-ui package does not export any of the components or utilities, so in order to access any of that a webpack plugin is required (I think) which would use node_modules as a path, thus allowing you to import directly from a path instead of the module. Secondly, and more importantly, the admin-ui doesn't support (as far as I can tell) drop-in component replacements for existing components. So, in order to replace this component, I would have to recreate the entire component structure all the way up to the route level. In this case I would basically be recreating the entire page just to modify a single small component inside of it. The final nail in the coffin is that the admin dashboard has prohibited routes. It prevents you from adding components to any of the preconfigured routes (in this case the products route). Therefore, if I wanted to use this modified products section I would have to place it in another route entirely, leaving two almost identical product routes accessible in the dashboard. This is confusing from a users perspective and obviously isn't a workflow that medusa currently supports (intentionally).

One other issue to note is that since the admin-ui doesn't export it's components, plugin developers tend to use the medusa/ui primitives (which I believe is what medusa wants plugin developers to use). The issue with this is that the styling tends to be inconsistent. Modals are a simple example. Creating a modal with the default primitives ends up taking up the whole screen, where as the majority of the provided dashboard modals do not. It's inconsistent from a user perspective, and from a plugin developers perspective it may be too frustrating to develop a component that aligns with the admin dashboards styling.

As it stands right now, the admin dashboard is great until you need to change something. It almost feels like a ticking time bomb, because when the time comes that you do need to replace something your only realistic choice is to create a separate project for your dashboard and go through the process of building it from scratch.

My proposal

Export components, organisms, etc. from the admin-ui package

This would ease the developer experience when developing components as it will make it easier to align with the dashboards design. Furthermore, if any design changes are made to the dashboard and pushed with a package update, the developers components would also reflect the design changes if built using the same components as the admin-ui. And, one last benefit is that it would allow developers to use injection zones in their own components (potentially, depends on load order).

Allow developers to provide drop in replacements for existing components

This would function by allowing the developer to replicate the admin-ui folder structure, and then overriding components that exist at the same path. You could potentially enforce that components implement the same props and such, but I don't think it would be worth it. This obviously would empower developers by allowing them to make the changes they see fit to existing components without being forced to create an entire separate project for the dashboard (which carries it's own issues). Furthermore it could spark a new community of developers providing enhanced, modified, or complete replacements of existing components which could then be directly dropped into medusa projects (similar to shadcn). I will make clear that I don't believe plugins should have the ability to override existing components. That would be extremely problematic and would more often than not break the dashboard when using several plugins. Plugins should only be able to modify the dashboard through injection zones (as is currently implemented). This overriding of existing components should only be possible in the root project by replicating the file structure of the admin-ui project. And, it should all be done at the developers own risk. Making this sort of functionality fool proof would be far too difficult and time consuming. The developer should be aware that it is possible things will break if they are overriding existing components and that everything should be done at their own risk. This way developers have the ability to make changes they see fit but only after all other options are exhausted.

[CST1999]

+1