-
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
Refactor style engine border styles #43594
Conversation
In the last couple commits I refactored a few of the other types to follow TS best practices |
Size Change: -1.08 kB (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
|
||
function createBorderGenerateFunction( path: string[] ): GenerateFunction { | ||
return ( style, options ) => | ||
generateRule( style, options, path, camelCase( path.join( ' ' ) ) ); |
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'd say we don't need an external library here.
There's already a util called upperFirst
. See the unit test.
So, until we need extra functionality, maybe we could do the following:
const path = [ 'some', 'path', 'to', 'somewhere' ];
console.log( path.map( ( value, index) => index !== 0 ? upperFirst( value ) : value ).join( '' ) );
// -> somePathToSomewhere
Or we could roll our own camelCase
using upperFirst()
:
const path = [ 'some', 'path', 'to', 'somewhere' ];
function camelCase( [ firstItem, ...rest ] ) {
return firstItem.toLowerCase() + rest.map( upperFirst ).join( '' );
}
console.log( camelCase( path ) );
// -> somePathToSomewhere
What do you reckon?
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 was using the lodash version of camelCase first which didn't require adding a dependency, but apparently that is being phased out elsewhere in Gutenberg in favor of change-case.
But adding our own function is easy enough and it can be trimmed a bit more to our use-case, so that's fixed in 990f0a1.
Thanks for throwing this up @ajlende 👍 I've run out of time to give it a proper test this week. I don't think we need to rush things before 6.1, given that things are working, but the optimizations look good. 🍺 I was wondering if there were any opportunities to unit test the new functions (?) I'll try to take it for a spin over the weekend or next week. |
The only thing that I would be concerned about is that the type definition for
There were already tests written for border, and the refactor produces exactly the same output as before. gutenberg/packages/style-engine/src/test/index.js Lines 99 to 148 in 990f0a1
I pushed a change adding doc comments explaining them which should help if something isn't clear. |
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.
Thanks for the work here. Smoked tested in the editor. Tests pass. LGTM 🍺
Hey folks! Came across this PR via #44406, which was marked for backporting into Core. I have a question related to this comment:
So it looks like |
Hmm, you're right. How are those being built? When I run
Is it important that backwards compatibility be maintained between WordPress versions for the types? I was assuming yes when I brought that up, but I may have been overthinking things and it may not be that much of a problem if folks are using types from the npm version. |
It looks like style-engine wasn't included in the top-level references so the only way they would be built is if you were running |
I did some refactoring to the border styles as I was trying to make sense of it.
I was able to reduce the signature of the generate function to just style and options like it was before to avoid some confusion that I had in #43526 (comment).
I did make some breaking changes with the type signature, but with the style engine not officially in core WordPress yet, I'm hoping that will still be okay.