Skip to content
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

Merged
merged 13 commits into from Feb 15, 2021

Conversation

roo2
Copy link
Contributor

@roo2 roo2 commented Feb 3, 2021

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

@roo2 roo2 requested review from lsl, autumnfjeld, ramonjd and a team February 3, 2021 14:20
@matticbot
Copy link
Contributor

@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Feb 3, 2021
@matticbot
Copy link
Contributor

Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com
Please ensure your changes work on WordPress.com before merging.

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

@matticbot
Copy link
Contributor

matticbot commented Feb 3, 2021

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~356 bytes added 📈 [gzipped])

name                 parsed_size           gzip_size
entry-gutenboarding       +169 B  (+0.0%)     +356 B  (+0.1%)

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])

name             parsed_size           gzip_size
woocommerce            +64 B  (+0.0%)       -1 B  (-0.0%)
settings               +64 B  (+0.0%)       -1 B  (-0.0%)
reader                 +64 B  (+0.0%)       -1 B  (-0.0%)
plugins                +64 B  (+0.0%)       -1 B  (-0.0%)
jetpack-connect        +64 B  (+0.0%)       -1 B  (-0.0%)
hosting                +64 B  (+0.0%)       -1 B  (-0.0%)
account                +64 B  (+0.0%)       -1 B  (-0.0%)

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])

name                                                 parsed_size           gzip_size
async-load-design-wordpress-components-gallery           +1339 B  (+0.2%)     +679 B  (+0.4%)
async-load-quick-language-switcher                         +64 B  (+0.0%)       -1 B  (-0.0%)
async-load-design-playground                               +64 B  (+0.0%)       -1 B  (-0.0%)
async-load-design-blocks                                   +64 B  (+0.0%)       -1 B  (-0.0%)
async-load-design                                          +64 B  (+0.0%)       -1 B  (-0.0%)
async-load-calypso-components-web-preview-component        +64 B  (+0.0%)       -1 B  (-0.0%)
async-load-calypso-blocks-nav-unification-modal            +64 B  (+0.1%)       -1 B  (-0.0%)
async-load-calypso-blocks-editor-checkout-modal            +64 B  (+0.0%)       -1 B  (-0.0%)
async-load-automattic-search                               +64 B  (+0.1%)       -1 B  (-0.0%)

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.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

@ramonjd
Copy link
Member

ramonjd commented Feb 4, 2021

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!

@ramonjd ramonjd requested a review from a team February 8, 2021 01:46
@ramonjd
Copy link
Member

ramonjd commented Feb 8, 2021

Tested:

Page picker appears and functions as expected from:

Home screen "Add new page link"
Side bar "Add new page link"
The new page button on the pages

Translated previews work as expected.

Nice 👌

@roo2 Do you think this PR should be broken up into two PRs:

  1. The first on adds the code to the packages directory (to be deployed first)
  2. The second implements the new package in the ETK

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 :)

@roo2 roo2 force-pushed the update/move-layout-picker-to-package branch from 74d1d53 to 9555b50 Compare February 8, 2021 04:23
@roo2
Copy link
Contributor Author

roo2 commented Feb 8, 2021

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 /apps/editing-toolkit/editing-toolkit-plugin/starter-page-templates/ made between when this is merged and when #49805 is merged. And also to test is, I think it's easiest to actually git cherrypick f545cab3225281c3c33574743e947c4df4dae203 the commit from #49805 and then yarn dev --sync

@andrewserong
Copy link
Member

Neat idea! @roo2 just a heads-up I've merged in #49695 which hides the Featured category from the page layout picker in page-template-modal/index.js so that change will need to be merged in to packages/page-template-modal/src/components/page-template-modal.js before this lands 🙂

It's just updating:

if ( ! ( key in templateGroups ) ) {

To become:

// Temporarily skip the 'featured' category so that we can expose it at another time.
if ( key !== 'featured' && ! ( key in templateGroups ) ) {

Copy link
Member

@p-jackson p-jackson left a 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.

@roo2
Copy link
Contributor Author

roo2 commented Feb 9, 2021

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

Copy link
Member

@noahtallen noahtallen left a 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.

@ramonjd
Copy link
Member

ramonjd commented Feb 9, 2021

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

@noahtallen
Copy link
Member

Totally! I like "page pattern" way better than "page layout" myself

@roo2
Copy link
Contributor Author

roo2 commented Feb 10, 2021

@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

@roo2 roo2 requested a review from p-jackson February 10, 2021 03:45
@roo2 roo2 force-pushed the update/move-layout-picker-to-package branch from a527f2f to d5d7b8b Compare February 15, 2021 03:01

module.exports = () => {
return getBaseWebpackConfig( {
WP: true,
Copy link
Contributor Author

@roo2 roo2 Feb 15, 2021

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

@roo2 roo2 requested a review from p-jackson February 15, 2021 03:06
@roo2
Copy link
Contributor Author

roo2 commented Feb 15, 2021

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

@roo2
Copy link
Contributor Author

roo2 commented Feb 15, 2021

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

@roo2
Copy link
Contributor Author

roo2 commented Feb 15, 2021

@p-jackson OK, I think I've worked out what was going on, I did need the custom webpack.config.js just because the component uses custom @wordpress components so WP needs to be enabled in the build 👍.

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",
Copy link
Contributor

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",
Copy link
Contributor

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

Copy link
Contributor Author

@roo2 roo2 Feb 15, 2021

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

Copy link
Contributor Author

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

Copy link
Contributor

@scinos scinos left a 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

@roo2
Copy link
Contributor Author

roo2 commented Feb 15, 2021

thanks for the feedback & discussion @scinos I've updated to use transpile && copy-assets and updated the version nubers to match.

@roo2 roo2 requested a review from scinos February 15, 2021 05:36
Copy link
Member

@p-jackson p-jackson left a 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.
Copy link
Contributor

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. :)

@roo2
Copy link
Contributor Author

roo2 commented Feb 15, 2021

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

@roo2 roo2 merged commit 892a94a into trunk Feb 15, 2021
@roo2 roo2 deleted the update/move-layout-picker-to-package branch February 15, 2021 21:57
@matticbot matticbot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Feb 15, 2021
@scinos
Copy link
Contributor

scinos commented Feb 16, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants