I have a table component, and each cell have to have a parsys (to allow authors to drop text, images, etc). That parsys must have a bespoke text component (in-house) within it as default.
In Sightly I've tried the following without results:
<sly data-sly-resource="${'table-col-header-{0}' @ format=[column], resourceType='/libs/wcm/foundation/components/parsys'}">
<sly data-sly-resource="${'table-col-header-text-{0}' @ format=[column], resourceType='/apps/componentlibrary/components/content/text'"/>
</sly>
Depending the actual limits in terms of rows/columns I would either opt for the cq:template node approach or an extension of the parsys which would include functionality to include pre-defined components. The OOTB parsys only includes what's pre-defined by templates (either page templates or component specific templates)
The cq:template node approach consists out of adding a node under the component definition which contains the structure it should have. This would allow you to predefine a text component (or other stuff) for each cell. But this would require finite limits on your rows and columns. If a component is added through the sidekick (and I believe the touchUI as well - but not 100% sure) it copies the whole structure of this node onto you're component location. Which in your case would mean that every single row/column would be copied and would result more nodes in the repo than you actually need (most of the time). This approach would be fine as long as the limits are rather low. Be aware that this approach does not work if you would include this 'table' component directly inside another component.
The second approach requires you to extend the parsys component to make it 'smarter' and provide 'default' items. This is more flexible, but also subjects to dealing with changes/enhancements that Adobe makes to that component.