-
Notifications
You must be signed in to change notification settings - Fork 4.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
[Create Block] Introduce the transformer property. #55423
Conversation
Co-authored-by: JuanMa <juanma.garrido@gmail.com>
Size Change: +55 B (0%) Total Size: 1.66 MB
ℹ️ View Unchanged
|
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 a very interesting idea. The biggest challenge is going to be documenting all the possible input that gets passed to the transformer
and ensuring it doesn't change over time so custom templates using this new API continue working correctly. The list of properties is very long, and it probably largely overlaps with the list of documented defaultValues
available for configuring templates. I'm not sure how both should co-exist together. Maybe, the transformer
should only return new and modified values?
customPackageJSON, | ||
customBlockJSON, | ||
example, | ||
} ); | ||
|
||
const { slug: transformedSlug, namespace: transformedNamespace } = |
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.
What's the reason for moving sanitization after transformation?
It only exists to enforce lower casing for the slug and the namespace, which is the requirement for the plugin name and the block name. If it would get back to the previous place in the code, we could avoid this hard to read destructuring.
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.
slug
is used later on for messaging and to generate various variations for the view
. So we needed to have any transforms applied before it's use. I agree it's not that easily read so I'll refactor.
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.
Would it work as expected if the sanitized version gets passed to the transformer? I don't think it matters.
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 would but there was no guarantee that the slug coming back from the transformer would be formatted correctly. That's the reason we transform first and then sanitize the results after.
This will be a challenge to document but as far as the values changing, I don't think we've ever removed one have we?
Having the transformer affect all values is very beneficial when trying to modify input or template defaults as well for example, if we wanted to take the slug and append a value to it: transformer: ( view ) => {
const hex = getRandomHexCode();
return {
...view,
slug: `${ view.slug }-${ hex }`,
};
}, |
I don't think we fully removed any options but we renamed some and added mapping for backward compatibility.
Both approaches would cover it. It all really depends how it’s used in templates. If folks mutat the input value or use |
… the pluginTemplate.
…on. They create the view based on the transformed values and access the view.slug for the CLI output.
@gziolo I've just pushed some changes that sanitizes the |
What?
This PR introduces the concept of a transformer property to create-block and closes #55421
Why?
This provide almost complete control over how a custom template can create plugins/blocks and allows the tool to focus on scaffolding rather than providing a huge amount of options. This offloads customization to the template.
How?
Creating a default
transformer
property that returns the data sent to it that can be overridden in a custom template.Testing Instructions
packages/create-block
es5
template inlib/templates.js
after theslug
propertynode ./index transformer-test --template es5
transformer-test-random-string
and anywhere the slug is used in the files has-random-string
added to it.Code to add: