-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Block API: Normalize block type function argument #11490
Changes from all commits
f2ecb33
969b727
d8dff1a
633597c
da7d649
92968f5
c169793
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -13,7 +13,7 @@ import { Component, isValidElement } from '@wordpress/element'; | |
/** | ||
* Internal dependencies | ||
*/ | ||
import { getDefaultBlockName } from './registration'; | ||
import { getBlockType, getDefaultBlockName } from './registration'; | ||
import { createBlock } from './factory'; | ||
|
||
/** | ||
|
@@ -104,3 +104,20 @@ export function normalizeIconObject( icon ) { | |
|
||
return icon; | ||
} | ||
|
||
/** | ||
* Normalizes block type passed as param. When string is passed then | ||
* it converts it to the matching block type object. | ||
* It passes the original object otherwise. | ||
* | ||
* @param {string|Object} blockTypeOrName Block type or name. | ||
* | ||
* @return {?Object} Block type. | ||
*/ | ||
export function normalizeBlockType( blockTypeOrName ) { | ||
if ( isString( blockTypeOrName ) ) { | ||
return getBlockType( blockTypeOrName ); | ||
} | ||
|
||
return blockTypeOrName; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A general question (not a blocker!) about our public APIs: Should we be validating their inputs more strictly and e.g. throwing an error if a number or boolean is passed here? My fear is that we may lose some flexibility to change APIs in the future if there are popular plugins out there that are using our APIs incorrectly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
As bad as it sounds, wouldn't it be a breaking change? :) In overall, this is something we should pay more attention to in the 2nd phase of the project. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My 2¢ : While laudable, as a general pattern it's hard to anticipate all nonsense inputs, and in setting expectations of tolerance while being unable to deliver (or deliver consistently), we're doing more a disservice than we're helping. |
||
} |
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 could be
partial( getBlockTransforms, direction )
. I dunno that I'd care to change it though (givenpartial
's questionable future)