Admin foundation

[mikemurray]

Split base admin UI, plugin registration, block API to a new repository and lib. This is a means to separate what makes the Admin UI tick, from the current repo and Meteor and allowing a future.

Goals

The Admin UI core, which currently is the base UI, routing, apollo, authentication, and the build tool, will be split into a separate library to become a reusable component in admin UI projects. Think create-react-app but specifically for Reaction Admins. It is responsible for all the mundane stuff needed to get started that no-one really wants to do... like configuring Webpack and installing a million npm dependencies for testing/building.

Plugins that once lived in Admin UI monolith will be split into separate plugin repos and be deployed via NPM.

Plugins will also be standalone. The repo will contain both the package to be built and deployed to npm, as well as an integration environment of the Admin UI Core for building, testing, and if wanted, production builds/deploys.

This means that plugins can be standalone UI's completely self-contained from a monolithic user interface, but can also function as plugins in a monolithic UI. This solves the problem of, how do I test my plugin without the admin, among many others.

You will own your admin project and are in control of your own package.json for your dependencies. It will be your responsibility to install the admin core package, all the plugins you want, and with a very lightweight directory structure, be able to register the plugins for the admin. It'll work very much like next.js (but will most likely NOT be built on next.js. time will tell.Maybe there will be acreate reaction-admin` script to automate the basic setup.

Reaction Admin, this repo, will be an example of that base folder structure with the OSS plugins installed. It would then be a template repo and a good starting point for your own UI customizations. Your updates to the major portions of the app will come from various npm packages, and not checking out / pulling from GitHub.

I want to get away from having to fork repos, using git submodules and npm linking.

For you visual people

Just keep in mind...

This is my theory deduced from all of the UI work we've done so far. We do have the precedent of this working in Catalyst, and Component Library, as well as in the API with adding plugins from NPM.

I believe this is possible, but it's theoretical until it made a reality.

[brent-hoover]

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

[mikemurray]

@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.

[mikemurray]

cc @kkuzemka @nnnnat

[mikemurray]

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

[brent-hoover]

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

[mikemurray]

@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.

[rymorgan]

@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?

[mikemurray]

@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.

[brent-hoover]

@morgoe can probably provide more detail from a UI perspective

[morgoe]

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:

[brent-hoover]

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.

[mikemurray]

@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.

[mikemurray]

@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.

[morgoe]

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

[derBretti]

@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.

[Akarshit]

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