@wordpress/blocks/build-module/api/index.mjs.map

Block API for WordPress.

{
  "version": 3,
  "sources": ["../../src/api/index.js"],
  "sourcesContent": ["/**\n * Internal dependencies\n */\nimport { lock } from '../lock-unlock';\nimport { isContentBlock } from './utils';\n\n// The blocktype is the most important concept within the block API. It defines\n// all aspects of the block configuration and its interfaces, including `edit`\n// and `save`. The transforms specification allows converting one blocktype to\n// another through formulas defined by either the source or the destination.\n// Switching a blocktype is to be considered a one-way operation implying a\n// transformation in the opposite way has to be handled explicitly.\nexport {\n\tcreateBlock,\n\tcreateBlocksFromInnerBlocksTemplate,\n\tcloneBlock,\n\t__experimentalCloneSanitizedBlock,\n\tgetPossibleBlockTransformations,\n\tswitchToBlockType,\n\tgetBlockTransforms,\n\tfindTransform,\n\tgetBlockFromExample,\n} from './factory';\n\n// The block tree is composed of a collection of block nodes. Blocks contained\n// within other blocks are called inner blocks. An important design\n// consideration is that inner blocks are -- conceptually -- not part of the\n// territory established by the parent block that contains them.\n//\n// This has multiple practical implications: when parsing, we can safely dispose\n// of any block boundary found within a block from the innerHTML property when\n// transferring to state. Not doing so would have a compounding effect on memory\n// and uncertainty over the source of truth. This can be illustrated in how,\n// given a tree of `n` nested blocks, the entry node would have to contain the\n// actual content of each block while each subsequent block node in the state\n// tree would replicate the entire chain `n-1`, meaning the extreme end node\n// would have been replicated `n` times as the tree is traversed and would\n// generate uncertainty as to which one is to hold the current value of the\n// block. For composition, it also means inner blocks can effectively be child\n// components whose mechanisms can be shielded from the `edit` implementation\n// and just passed along.\nexport { default as parse } from './parser';\nexport { serializeRawBlock } from './parser/serialize-raw-block';\nexport {\n\tgetBlockAttributes,\n\tparseWithAttributeSchema,\n} from './parser/get-block-attributes';\n\n// While block transformations account for a specific surface of the API, there\n// are also raw transformations which handle arbitrary sources not made out of\n// blocks but producing block basaed on various heuristics. This includes\n// pasting rich text or HTML data.\nexport {\n\tpasteHandler,\n\trawHandler,\n\tdeprecatedGetPhrasingContentSchema as getPhrasingContentSchema,\n} from './raw-handling';\n\n// The process of serialization aims to deflate the internal memory of the block\n// editor and its state representation back into an HTML valid string. This\n// process restores the document integrity and inserts invisible delimiters\n// around each block with HTML comment boundaries which can contain any extra\n// attributes needed to operate with the block later on.\nexport {\n\tdefault as serialize,\n\tgetBlockInnerHTML as getBlockContent,\n\tgetBlockDefaultClassName,\n\tgetBlockMenuDefaultClassName,\n\tgetSaveElement,\n\tgetSaveContent,\n\tgetBlockProps as __unstableGetBlockProps,\n\tgetInnerBlocksProps as __unstableGetInnerBlocksProps,\n\t__unstableSerializeAndClean,\n} from './serializer';\n\n// Validation is the process of comparing a block source with its output before\n// there is any user input or interaction with a block. When this operation\n// fails -- for whatever reason -- the block is to be considered invalid. As\n// part of validating a block the system will attempt to run the source against\n// any provided deprecation definitions.\n//\n// Worth emphasizing that validation is not a case of whether the markup is\n// merely HTML spec-compliant but about how the editor knows to create such\n// markup and that its inability to create an identical result can be a strong\n// indicator of potential data loss (the invalidation is then a protective\n// measure).\n//\n// The invalidation process can also be deconstructed in phases: 1) validate the\n// block exists; 2) validate the source matches the output; 3) validate the\n// source matches deprecated outputs; 4) work through the significance of\n// differences. These are stacked in a way that favors performance and optimizes\n// for the majority of cases. That is to say, the evaluation logic can become\n// more sophisticated the further down it goes in the process as the cost is\n// accounted for. The first logic checks have to be extremely efficient since\n// they will be run for all valid and invalid blocks alike. However, once a\n// block is detected as invalid -- failing the three first steps -- it is\n// adequate to spend more time determining validity before throwing a conflict.\nexport { isValidBlockContent, validateBlock } from './validation';\nexport { getCategories, setCategories, updateCategory } from './categories';\n\n// Blocks are inherently indifferent about where the data they operate with ends\n// up being saved. For example, all blocks can have a static and dynamic aspect\n// to them depending on the needs. The static nature of a block is the `save()`\n// definition that is meant to be serialized into HTML and which can be left\n// void. Any block can also register a `render_callback` on the server, which\n// makes its output dynamic either in part or in its totality.\n//\n// Child blocks are defined as a relationship that builds on top of the inner\n// blocks mechanism. A child block is a block node of a particular type that can\n// only exist within the inner block boundaries of a specific parent type. This\n// allows block authors to compose specific blocks that are not meant to be used\n// outside of a specified parent block context. Thus, child blocks extend the\n// concept of inner blocks to support a more direct relationship between sets of\n// blocks. The addition of parent\u2013child would be a subset of the inner block\n// functionality under the premise that certain blocks only make sense as\n// children of another block.\nexport {\n\tregisterBlockType,\n\tregisterBlockCollection,\n\tunregisterBlockType,\n\tsetFreeformContentHandlerName,\n\tgetFreeformContentHandlerName,\n\tsetUnregisteredTypeHandlerName,\n\tgetUnregisteredTypeHandlerName,\n\tsetDefaultBlockName,\n\tgetDefaultBlockName,\n\tsetGroupingBlockName,\n\tgetGroupingBlockName,\n\tgetBlockType,\n\tgetBlockTypes,\n\tgetBlockSupport,\n\thasBlockSupport,\n\tgetBlockVariations,\n\tisReusableBlock,\n\tisTemplatePart,\n\tgetChildBlockNames,\n\thasChildBlocks,\n\thasChildBlocksWithInserterSupport,\n\tunstable__bootstrapServerSideBlockDefinitions, // eslint-disable-line camelcase\n\tregisterBlockStyle,\n\tunregisterBlockStyle,\n\tregisterBlockVariation,\n\tunregisterBlockVariation,\n\tregisterBlockBindingsSource,\n\tunregisterBlockBindingsSource,\n\tgetBlockBindingsSource,\n\tgetBlockBindingsSources,\n} from './registration';\nexport {\n\tisUnmodifiedBlock,\n\tisUnmodifiedDefaultBlock,\n\tnormalizeIconObject,\n\tisValidIcon,\n\tgetBlockLabel as __experimentalGetBlockLabel,\n\tgetAccessibleBlockLabel as __experimentalGetAccessibleBlockLabel,\n\t__experimentalSanitizeBlockAttributes,\n\tgetBlockAttributesNamesByRole,\n\t__experimentalGetBlockAttributesNamesByRole,\n} from './utils';\n\n// Templates are, in a general sense, a basic collection of block nodes with any\n// given set of predefined attributes that are supplied as the initial state of\n// an inner blocks group. These nodes can, in turn, contain any number of nested\n// blocks within their definition. Templates allow both to specify a default\n// state for an editor session or a default set of blocks for any inner block\n// implementation within a specific block.\nexport {\n\tdoBlocksMatchTemplate,\n\tsynchronizeBlocksWithTemplate,\n} from './templates';\nexport { default as children } from './children';\nexport { default as node } from './node';\nexport {\n\t__EXPERIMENTAL_STYLE_PROPERTY,\n\t__EXPERIMENTAL_ELEMENTS,\n\t__EXPERIMENTAL_PATHS_WITH_OVERRIDE,\n} from './constants';\n\n// Allows blocks to declare private keys (fields form)\n// that we can use to generate UI controls for them via DataForm.\nconst fieldsKey = Symbol( 'fields' );\nconst formKey = Symbol( 'form' );\n\nimport { parseRawBlock as _parseRawBlock } from './parser';\n\nexport const privateApis = {};\nlock( privateApis, {\n\tisContentBlock,\n\tfieldsKey,\n\tformKey,\n\tparseRawBlock: _parseRawBlock,\n} );\n"],
  "mappings": ";AAGA,SAAS,YAAY;AACrB,SAAS,sBAAsB;AAQ/B;AAAA,EACC;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,OACM;AAmBP,SAAoB,WAAXA,gBAAwB;AACjC,SAAS,yBAAyB;AAClC;AAAA,EACC;AAAA,EACA;AAAA,OACM;AAMP;AAAA,EACC;AAAA,EACA;AAAA,EACsC;AAAA,OAChC;AAOP;AAAA,EACY,WAAXA;AAAA,EACqB;AAAA,EACrB;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACiB;AAAA,EACM;AAAA,EACvB;AAAA,OACM;AAwBP,SAAS,qBAAqB,qBAAqB;AACnD,SAAS,eAAe,eAAe,sBAAsB;AAkB7D;AAAA,EACC;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,OACM;AACP;AAAA,EACC;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACiB;AAAA,EACU;AAAA,EAC3B;AAAA,EACA;AAAA,EACA;AAAA,OACM;AAQP;AAAA,EACC;AAAA,EACA;AAAA,OACM;AACP,SAAoB,WAAXA,gBAA2B;AACpC,SAAoB,WAAXA,gBAAuB;AAChC;AAAA,EACC;AAAA,EACA;AAAA,EACA;AAAA,OACM;AAOP,SAAS,iBAAiB,sBAAsB;AAHhD,IAAM,YAAY,uBAAQ,QAAS;AACnC,IAAM,UAAU,uBAAQ,MAAO;AAIxB,IAAM,cAAc,CAAC;AAC5B,KAAM,aAAa;AAAA,EAClB;AAAA,EACA;AAAA,EACA;AAAA,EACA,eAAe;AAChB,CAAE;",
  "names": ["default"]
}