-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Serve Gatsby Admin from develop parent process #23734
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
Conversation
f925e65
to
be319ea
Compare
be319ea
to
35a7fea
Compare
3064853
to
ac0d414
Compare
083ab63
to
3f03dd6
Compare
8eee572
to
8c31132
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some comments :)
default: `1px solid ${baseTheme.colors.whiteFade[20]}`, | ||
}, | ||
sizes: { | ||
// NOTE(@mxstbr): Hacks around issues with strict-ui that I have to fix upstream eventually |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that you're personally a fan of strict-ui. How different is it from Theme UI?
Because we use Theme UI everywhere else and other people should also be able to contribute. So on first sight it might make more sense to use Theme UI? (And you wouldn't have to deal with bugs from its early stage).
I fear that not using Theme UI here this will converge overtime to a state where it then would need to be refactored as Theme UI gets new features and strict-ui not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the same thing 😉 strict-ui is literally theme-ui, but it throws an error if you try to use a non-theme value.
You can drop down to theme-ui in any file, which I've actually done in some, by simply doing /** @jsx jsx */ import { jsx } from 'theme-ui'
. Completely interoperable!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's fair to say they are the same, since Theme UI works more as a superset of CSS and strict-mode is inherently a subset of that API, which means some things would not work as expected for people coming from using Theme UI -- that said, I don't think this should block the initial release, but we should be considering what the "SDK" for Admin will look like and how easy it is for others to work on Admin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My answer of "they are the same thing" was that strict-ui literally uses theme-ui under the hood to alleviate the mentioned concern that theme-ui will get new features but strict-ui will not, which cannot be the case. Sorry for not being clear!
To clarify, a pseudo-implementation of strict-ui would look like this:
// strict-ui/jsx.js
const jsx = (type, props, ...children) => {
makeSureTheresNoCrapCSS(props.sx)
return themeUiJSX(type, props, ...children)
}
What I mean was that it is literally the theme-ui API, with some extra restrictions applied. That means switching to theme-ui is as simple as replacing all strict-ui
imports with theme-ui
, minus the <Flex>
component which is the only addition on top of theme-ui it adds 😊
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the most questions arising, because the npm package readme is empty and there is no github repo associated :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, looks good to me! Decoupling this as a separate Gatsby app makes a ton of sense to me.
I do have some concerns about mixing Gatsby Interface with strict-ui
-- especially because it doesn't appear to be in a stable place (yet) and lacks some of the documentation and general know-how that Gatsby Interface or Theme UI have. I don't think that should block the initial release, but if there are things that aren't covered in Gatsby Interface or Theme UI that you think we'll need in Admin, we should work towards getting those features into these component libraries
<h1>{data.npmPackageJson.value.replace(/^"|"$/g, ``)}</h1> | ||
<h2>Plugins</h2> | ||
<ul> | ||
<Flex gap={7} flexDirection="column" sx={{ paddingY: 7, paddingX: 6 }}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why you decided to use Theme UI in addition to Gatsby Interface – seems like this might be confusing for other people coming in to work on this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow, those two packages solve completely different problems? One is our design system component library, one is a CSS-in-JS library? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think they solve completely different problems, ideally a design system should provide virtually all of the styles we'd need to build out UI IMO. Curious to hear what @Elanhant's thoughts might be though (this is definitely not-blocking BTW)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I am not completely sure what is the question here 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding, which could very well be wrong, was that Gatsby Interface was a design system/component library that could build out most of the UI without needing other libraries. If that's not the case, and it's intended to work alongside something like Theme UI, then that's all I'm asking about here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think your understanding would be right for Gatsby Interface v1 (correct me if I'm wrong, @fk). For now, however, it is just a library of the components used the most in Cloud, so it is inevitable to have cases where you'll have to resort to a 3rd party or custom solution (in which case, let me and/or Flo know, perhaps it warrants an addition to Gatsby Interface!).
|
||
const serveAdmin = st({ | ||
path: adminFolder, | ||
url: `/___admin`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a limitation of the st
package, but I do like that the /___graphql
path is pattern-based and forgiving for typos. Have you taken that into consideration already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have not taken that into consideration, good call! From a quick glance, it does not look like the st
package supports this. I tried some other packages and they didn't quite work, so I'd rather ship this for now and fix that later?
Co-authored-by: Lennart <[email protected]>
Going to ship this for Gatsby Days next week! |
* Server static admin app from parent process * Start Recipes GraphQL server when running develop and fetch fresh port in admin * Setup gatsby-inteface and strict-ui * Build gatsby admin navbar * Proper headings on the dash * Style rest of dashboard * Add return type to createUrqlClient * Update gatsby admin running instructions * Add instructions to replace ___loader with window.___loader * Remove unused components * Bump strict-ui and test local site dev * Add GATSBY_EXPERIMENTAL_ENABLE_ADMIN feature flag * Resolve type issue by pinning version of csstype to 2.6.10 * Fix package.json for gatsby-admin package * Update packages/gatsby-admin/README.md Co-authored-by: Lennart <[email protected]> * Remove built-in plugin * Add some more technical docs * Fix prettier Co-authored-by: Lennart <[email protected]>
Based on #22759 and #23733, this serves the Gatsby Admin site at
/___admin
from the develop parent process proxy.The
gatsby-admin
package is setup as a standard Gatsby site, which is built and then the proxy serves the static files whenever a/___admin
route is requested.This also sets up Gatsby Admin with gatsby-interface and strict-ui to build the UI, which closes #24451.
For marketing reasons, this is guarded behind a "secret"
GATSBY_EXPERIMENTAL_ENABLE_ADMIN
env variable for now (cc @hashimwarren for visibility).