[wp-trac] [WordPress Trac] #59168: Block API: Unnecessary JSON decoding in block parser
WordPress Trac
noreply at wordpress.org
Fri Sep 15 20:38:39 UTC 2023
#59168: Block API: Unnecessary JSON decoding in block parser
--------------------------+--------------------------
Reporter: dlh | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.4
Component: Editor | Version: 5.0
Severity: normal | Resolution:
Keywords: has-patch | Focuses: performance
--------------------------+--------------------------
Comment (by dmsnell):
Thanks @spacedmonkey - by the way, if I'm unresponsive on an issue I
totally understand moving forward, so thanks for helping out on this.
> the performance problem
What performance problem are we talking about?
> I figured the ship had sailed.
@dlh same thought. I think there's a chance this only ever exposed itself
in the tests themselves, as everything else was happy with the loose
types.
> I'm happy to try to update the spec parser, but I'm not familiar with
it. Can you provide a little more guidance about what needs to be updated?
The spec parser (in the `block-serialization-spec-parser/grammar.pegjs`
file) leans on `peg_empty_attrs()` to provide this same value. We can
probably just remove that function and replace all calls to it with
`array()`.
> Removing the use of $empty_attrs seems a little more questionable to me.
It's a public property on a non-final class, and the block_parser_class
filter makes it possible to use an extended version of that class that
depends on the property.
It's probably fine. I doubt anything is relying on it: no public plugins
are [https://wpdirectory.net/search/01HAD8VT8HMVTBF2W4V2KTSRXD plugin
search for "empty_attrs"]
> Arguably, both removing the use of the property within the class and
removing the property itself are backwards-incompatible changes.
This is true, and again, probably fine. We can deprecate it if we really
want to. That would involve changing the internal code while leaving the
attribute in place, adding a deprecation notice in the docblock comment.
> the property still provides the code a bit of a semantic boost.
🤷♂️ this seems arguable to me at best. it was added originally to
address a quirk, and `array()` is common enough that it would be
surprising if it confused people that it's supposed to represent anything
other than an empty array.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59168#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list