Social Links Block: Icon Storage/Extension Architecture #19041
Description
Per discussion on #18651, the current approach to storing Icons for the Social Links block has quite a bit of duplication of SVGs and associated label data between the JavaScript and PHP file, nor is there a great way to add or override logos (#17277).
We definitely need a way for logos to be added or overridden, and ideally an approach to storing the data in a way both JavaScript/PHP can share, without adding performance burden/blocking requests to site visitors.
For Extension
For extending, ideally we could use a single PHP-based apply_filters() to allow developers to inject, remove or override icons from the list. By using the PHP filter, we could make a single extension point as opposed to having to filter both PHP and JS hooks.
For Icon/Data Storage
There's been some discussion about using SVGR, but taking that approach would create invalid imports for the npm packages and without some laborious/extremely-clever build changes.
Some previously discussed ideas on #18651...
- Leave implementation as-is, add filter hooks in JS & PHP for extension and enhance with clearer inline documentation that any changes must happen to both objects -- still duplicated but extensible and clearer.
- Add a socialData.json file with icons base64 encoded and filter hooks in JS & PHP to allow extension -- adds filesystem read in PHP and base64 strings would be about 1/3 larger.
- Use a socialData.json file to inject the objects into JS & PHP during webpack build, base64 decode icons and add filter hooks -- somewhat obfuscates what's happening and some complexity, but reduces client burden.
- Separate icons into a SVG sprite approach or one-off SVG files, use a socialData.json to point to the proper icon and add filter hooks -- makes a larger payload to transmit to client/increases client requests, but makes using a data file easier.
Describe the solution you'd like
From the approaches I mentioned above, I think the lowest lift approach is simply to add some better inline documentation 😇. This isn't data likely to change with enough frequency to demand a significantly more complex architecture, unless it isn't a huge time investment. Any other ideas of course welcome.
As much as it'd be great not to have a contribution/maintenance burden with the duplication between PHP/JS files, I'd rather the burden be on developers than adding filesystem reads or additional requests for every visitor.
Activity