-
Notifications
You must be signed in to change notification settings - Fork 2k
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
move page template modal into its own package #49661
Conversation
Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com D56412-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing the Editing Toolkit Plugin for more info: PCYsg-ly5-p2 |
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~356 bytes added 📈 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~1 bytes removed 📉 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Async-loaded Components (~679 bytes added 📈 [gzipped])
React components that are loaded lazily, when a certain part of UI is displayed for the first time. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
I didn't have much time to give it a proper code review, but I took it for a spin. It works! First time. No JS/PHP errors I can see so far. Will continue tomorrow. Thanks! |
Tested: Page picker appears and functions as expected from: Home screen "Add new page link" Translated previews work as expected. Nice 👌 @roo2 Do you think this PR should be broken up into two PRs:
I'm only suggesting this as a precautionary measure. This PR could be eventually merged with both changes if we were sure of them, but it might be safer for testing since someone might do an ETK release before we are ready. Also for ease of rollback. What do you think? I added @Automattic/team-calypso as reviewers in case there was anything we should be aware of when extracting packages. Context: the page picker has a use case in onboarding as well :) |
74d1d53
to
9555b50
Compare
as you suggested @ramonjd I've updated this change to be in two parts, the new package is in this PR, and then, #49805 updates the ETK to use the package. This does have the risk of potentially losing changes to |
Neat idea! @roo2 just a heads-up I've merged in #49695 which hides the Featured category from the page layout picker in It's just updating:
To become:
|
packages/page-template-modal/src/components/template-selector-preview.js
Outdated
Show resolved
Hide resolved
a75bc25
to
0b7e65d
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.
👍 @roo2
I know you're still working on this, but I had a thought about the <PageTemplatesPlugin>
thing. I actually am wondering whether that logic should be left in the ETK in some way. It details with things like "do this if this version of GB, otherwise do that", and deals with where state should saved. That seems fairly editor specific.
But if we wanted to open the layout picker in gutenboarding, or in the customiser maybe, then we probably wouldn't want to use any of that logic from <PageTemplatesPlugin>
. I think we'd want to just use the <PageTemplateModal>
component and pass in our own props for when to open it.
I'm not sure whether that means <PageTemplatesPlugin>
needs to be split in half and some of the logic stays in the package, or whether all belongs in the ETK.
hmm that's a really interesting point @p-jackson 🤔 I think yea you're right, we should change this to only extract the modal and not the plugin with its gutenberg specific stores etc. Apart from that, the other feedback is addressed, @andrewserong's change is incorporated and I've updated this PR to include updating the ETK to use the package in one fell swoop again in this PR (for ease of testing and git integrity), after discussion p1612845014028000-slack-CRWCHQGUB |
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 curious, what do y'all think about naming this something other than "Page Template Modal"? Template has a very specific purpose in the context of FSE, and isn't the same as what we're doing here. IMO it would be nice to change its name to one of the newer variations (page patterns?) while we have the chance.
I agree. The component might not even be used as modal. Page pattern/layout selector/picker? I think I need a reminder of whether "layout" is appropriate here as well 🤣 Look at PCYsg-t0i-p2 for refs |
Totally! I like "page pattern" way better than "page layout" myself |
@noahtallen I think it's a good idea to rename but not to do it in this PR because I think it will take quite a lot of changes if we keep all of the classnames etc consistent. And @p-jackson is currently working on this part of the code so renaming now would make it harder for him to merge his changes p1612913238087800-slack-CRWCHQGUB |
a527f2f
to
d5d7b8b
Compare
|
||
module.exports = () => { | ||
return getBaseWebpackConfig( { | ||
WP: true, |
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.
edit: this line is necessary because we use core @WordPress components
@p-jackson I've updated the PR to include scss now, I also split the scss file into what's related to the modal and whats related to the button that opens it. |
@p-jackson actually, I'm just going back to work out why I can't build this without adding that custom webpack config file, I shouldn't need it but got errors bundling the scss without it. I thought there was a bug with the default config in calypso-build but I wasn't able to reproduce that so now I'm investigating this again. Thanks for you patience! |
@p-jackson OK, I think I've worked out what was going on, I did need the custom I wasn't able to reproduce the errors that I'd thought were a calypso-build bug that I saw on Friday and everything seems to be working 👍 |
@@ -0,0 +1,56 @@ | |||
{ | |||
"name": "@automattic/page-template-modal", | |||
"version": "1.0.0", |
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 is version 1.0.0
, but ETK depends on version 1.0.0-alpha.0
. They should be the same version, right?
}, | ||
"scripts": { | ||
"clean": "npx rimraf dist", | ||
"build": "calypso-build", |
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 this should be transpile
instead of calypso-build
? transpile
is what other packages use, it produces the dirs dist/esm
and dist/cjs
(declared above in this package.json
) and you won't need a custom wepbkac.config.js
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 was to make sure that the scss
file gets built and output as css
in dist
.
When we use this package form the ETK, we don't actually use the built css
from dist
, rather, we import the scss
file directly, so maybe it doesn't matter?
But yea, the motivation for using calypso-build
was so that the css gets built too
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.
little bit of background up discussion with @p-jackson p1613363841195300-slack-CRWCHQGUB
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.
Use transpile
to build the package
thanks for the feedback & discussion @scinos I've updated to use |
packages/page-template-modal/src/styles/page-template-modal.scss
Outdated
Show resolved
Hide resolved
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 looking good!
As well as the couple notes I made, I think we can also delete the entire webpack.config.js
file now?
@@ -0,0 +1,31 @@ | |||
@import '~@automattic/page-template-modal/src/styles/page-template-modal'; | |||
|
|||
// Sidebar modal opener goo. |
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.
goo? :) As in glue that is holding something together? That might not be clear to next dev who comes along. :)
thanks @p-jackson I've made the changes you suggested, @autumnfjeld I just removed that comment, I don't think it added anything in its new location |
This PR has introduced lots of package duplications. While that is not a problem on itself, it can indicate that the new package is using different versions than it was using before. If it wasn't expected it may suggest a problem in the new dependencies. I fixed the dependencies in #50114 |
Changes proposed in this Pull Request
Moves page layout selector into its own package as the first step of the page layout selector redesign.
In order to enable future reuse and reduce the size of the ETK plugin
I used the same version numbers of dependencies that had been used in the ETK ( most of them use the
*
latest version)Testing instructions
Build the code and sync to your sandbox with
cd apps/editing-toolkit yarn yarn dev --sync
#49240