Open mikemurray opened 4 years ago
Hey @mikemurray , I wonder if you could add a little context/detail about what this means?
@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.
cc @kkuzemka @nnnnat
Updated OG comment with a longer, and hopefully better summary of the idea I'm proposing.
@mikemurray If someone wanted to "reskin" the entire look via their own Catalyst library. Will this change make it possible?
@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.
@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?
@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.
@morgoe can probably provide more detail from a UI perspective
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.
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:
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.
@morgoe
@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.
@mikemurray ok. At some point we should have a call and go over these things. Brent might need to be the translator between us :)
@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.
@derBretti This idea isn't being pursued. Mostly because we will be shifting to a third-party admin in the near future.
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 likenext.js
(but will most likely NOT be built on next.js. time will tell.Maybe there will be a
create 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.