[wp-trac] [WordPress Trac] #60575: Refactor: `data_wp_context` function does not follow WP standards.
WordPress Trac
noreply at wordpress.org
Sun Feb 25 21:50:46 UTC 2024
#60575: Refactor: `data_wp_context` function does not follow WP standards.
--------------------------------------+---------------------
Reporter: cbravobernal | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.5
Component: Editor | Version: trunk
Severity: normal | Resolution:
Keywords: needs-patch dev-feedback | Focuses:
--------------------------------------+---------------------
Comment (by swissspidy):
I'm sure you understand that there can be typos in some quick example
code. That doesn't really make a case against it.
> It's our responsibility to maximize the chances that developers will use
this helper.
So why only a helper for `data-wp-context` and not for others?
Consistency is also part of developer experience. That includes consistent
names and behaviors.
Just because `data_wp_context` reads the same as `data-wp-context` doesn't
make it a good function name. So a function with a prefix that's
consistent with other `wp_interactivity_api` functions makes more sense.
And functions that return a complete `attribute="value"` pair are not
common either. So is something like `data-wp-context=' .
wp_interactivity_encode_context(...) . '` really that inconvenient?
If someone uses the wrong quotes and their code breaks, they'll realize
quickly, no?
Someone can do `data-wp-context='{ "someValue": "<?php echo $some_value;
?>" }'` even if there is a nice `data_wp_context` filter. People will
always find a way.
Echoing by default doesn't really make sense to me as a) you can easily
echo a return value but not the other way around, and b) the return use
case is more common, as existing examples show.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/60575#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list