Admin foundation about admin HOT 16 OPEN

Updated OG comment with a longer, and hopefully better summary of the idea I'm proposing.

from admin.

Hey @mikemurray , I wonder if you could add a little context/detail about what this means?

from admin.

@kkuzemka @rymorgan

My goal today was to prove that the important components of the admin application, the build tool and configuration, and base UI can be split into a separate NPM package, and then be able to install this "admin" package into any project and have a base Reaction Admin working.

What I have so far is...

I can "install" the "@reactioncommerce/admin-core" package into another project and with two small files (one HTML, one JS) and be able to run the admin without having to manage a multitude of npm packages, configuring build tools and the like.

from admin.

Let me just add that generally we would strongly support this idea. We would really like a way to extend/contribute without having to fork. I feel this benefits everybody in the long run and this seems like a good approach.

from admin.

@zenweasel I added a diagram explaining the theory, and I'll add more context below.

What I want to go for is splitting the core admin UI + build tool + plugin registration into a reaction-admin-core repo and have it be installed via NPM.

Your custom plugin repos would be able to operate like the Catalyst project where we both publish an NPM package of the components, while also serving a self-contained web app with the components for testing/demos.

In the case of the admin, you'd be able to develop your plugin in isolation in your plugin's repo, but also publish a package (or package it some other way) to be able to be used in a unified admin with other plugins.

Reaction Admin as you know it, would just be a showcase/example app containing reaction-admin-core and other plugins installed and registered. You get to control the base project, package.json, and can more easily update the components you want. You'll have control on how you want to register your plugins. There could also be a create-reaction-admin script or generator to do this for you.

In theory, we can have as many or as few admin's as we want, and we don't have to resort to forking repos, git submodules, or npm-link.

Reaction Admin will no longer be a monolithic admin interface if this all works out. It's time to split up the band, but they can come back together for the world tour.

from admin.

cc @kkuzemka @nnnnat

from admin.

@mikemurray If someone wanted to "reskin" the entire look via their own Catalyst library. Will this change make it possible?

from admin.

@zenweasel What does re-skin mean to you? To me, it means just a CSS theme injected into the theme context. You can already do this by extending the defaultTheme from Catalyst before injecting it into the ThemeProvider, but you have to edit the core. This can be made easier in the new world, by putting more control of the app setup in your hands.

We use the MUI styling solution that allows you to change all of the CSS for all of the components from the base theme file with overrides. If this is not the case, then we can work to correct it.

If you mean, forking the Catalyst repo and manually changing components; then, you can also already do this in normal Reaction, again modifying the package.json, but you need to make sure your "package" is built and installed in node_modules/@reactioncommerce/catalyst.

In the new system, you control the package.json so you can install whatever you like. The plugins themselves will only depend on Catalyst as a peer dependency.

If you're forking Catalyst to just change the theme, then I believe that's the nuclear option once all other choices have been exhausted. I don't fully understand your theming needs, I would like to know more details if possible.

from admin.

@zenweasel I second wanting to know more. In general, it's been our assumption that folks will want to lightly theme the Reaction Admin visually. While the big changes would be to extend or modify flows to customize to their needs. Are these changes for more functionality, different UX or visual design?

from admin.

@morgoe can probably provide more detail from a UI perspective

from admin.

Hey guys, here's a little more info in terms of how we are "skinning" Reaction Admin. Skinning is probably not the right word. There are quite a few things going on.

1. We can reskin existing MaterialUI components using the default styling override. This works for a lot of components.
2. Some components, in order to be fully reskinned, need to have HOC. For example, we have a Checkbox component that has a special "preview" state. This can't be achieved by simply reskinning the MaterialUI checkbox component, so we have to have our own Checkbox component that imports the MaterialUI one and extends it.
3. Some components are built from scratch. For example, we have a Tree component.
4. Finally, we have, as you can see, completely changed the layout and design of each page. I imagine this might take place as a plugin, rather than attempting to "skin" the existing pages.

Finally, I have a few questions. Please remember that I'm pretty much pretending to be a developer, and I'm also very unfamiliar with Reaction Admin's codebase, so I may ask stupid questions or say stupid things :)

The visual you posted above @mikemurray makes sense to me. It seems a little like how Shopify handles plugins with Polaris. A few questions:

• How do we handle navigation between plugins? If I install a plugin, does it get placed in the navigation menu? If I have a custom Products plugin, how do I disable the default one?
• How do we handle relationships between plugins? If we install a custom Products plugin, and a custom Categories plugin, can they communicate and share data?
• One thing we landed on through multiple iterations of design was for users to be able to have custom plugins, which have their own customisation screens, etc. but for those settings to be propagated UP to default Reaction Admin. Here's an example, where different Payment Methods are installed via plugins, but the default Reaction Admin chooses which one to use:

from admin.

@morgoe

• Plugins register their own routes through configuration. You are also free to define React Router routes anywhere in your plugin for further control if necessary.
• Along with that, they can add a link to navigation for their pages if wanted.
• Plugins don't need to share data, they have the API to do that. If the Categories plugin needs something from Products, it can just query/mutate product data itself.
• Plugins may be able to define blocks of UI elements that can be shared in other plugins so you can a Products plugin create a UI for searching products and giving a list of those to Categories.
• Plugins register themselves through configuration. They could also define a "settings" screen. The Payment setting you're referring to is mostly for the storefront to tell which payment methods to accept. The list of available methods is based on what plugins are installed in the API.

from admin.

@morgoe Looking at those designs, I feel you'd be better just building your own UI using the current/future plugins as a guide. These are more than just a "skin", and more like a redesign with different UX.

Keep in mind, at this point the Reaction Admin is a front-end only application, despite using Meteor, relying heavily on GQL. With all that it's capable of now with that API alone, you'd be able to build your own admin UI.

The future App could provide ways to choose your own application shell or other light customization options, but we're focusing on limited "theme" customization at the start. Plugins are responsible for their own UX. Ours will adopt Catalyst/MUI. Yours can do the same or use an entirely different UI kit.

... But, to reiterate my first point, you don't "have" to use our admin. You can build your own, like your custom storefront. While there may be some minor gaps, the API is more than sufficient if you want to build your own totally custom admin app.

from admin.

@mikemurray ok. At some point we should have a call and go over these things. Brent might need to be the translator between us :)

from admin.

@mikemurray I like this approach very much, but I also noticed that after a few initial commits the associated repos have been pretty much dormant. So, I'm wondering whether this idea is still pursued. If so, I'd be happy to contribute.

from admin.

@derBretti This idea isn't being pursued. Mostly because we will be shifting to a third-party admin in the near future.

from admin.