feat(pte): expose data-attributes on PTE Text + Object blocks

[robinpyon]

Description

This tiny PR adds data attributes to PTE text + object blocks, as well as their children which have styles applied in JS (via innerPaddingProps)

These have been added in order for Create to be able to safely target and override styles applied on these elements without resorting to sketchy CSS selectors.

There's definitely a greater question of how we could look to render <PortableTextInput> in a style-agnostic fashion in future. For now, this is very much a short term solve.

What to review

Nothing – this doesn't impact the studio...

Questions

.. but does lead to some interesting questions!

• When it comes to exposing arbitrary (non-test) data-attributes, is there a convention we should use to denote certain attributes as protected and in use externally?
  • E.g. I could easily see a future where someone searches for instances of these data attrs, finds none within the studio and then marks them for deletion.
  • If there isn't an existing convention, is it worth just attaching inline comments to these?
• As above, how customisable should PTE and all rendered output be? Perhaps a convention could be made where if we are applying styles-in-js, that we provide a data-attr / escape hatch for users to override these externally.
  Nothing that needs to be actioned any time soon, but perhaps worth formalising eventually (especially as we start to see more PTE usage within the studio outside of document forms)

Testing

N/A

Notes for release

N/A

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 14, 2024 8:30am
test-next-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 14, 2024 8:30am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 14, 2024 8:30am

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		May 14, 2024 8:30am

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated May 14, 2024 8:35 AM (UTC)

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	35s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	6s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	31s	11	7	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	14s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	36s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 3s	15	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	1m 5s	18	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	7s	3	9	0
formBuilder/inputs/PortableText/RangeDecoration.spec.tsx	✅ Passed (Inspect)	20s	9	0	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	14s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	21s	9	0	0

[RitaDias]

Hi 👋
Thanks for doing this! ✨

Questions

.. but does lead to some interesting questions!

• When it comes to exposing arbitrary (non-test) data-attributes, is there a convention we should use to denote certain attributes as protected and in use externally?

  • E.g. I could easily see a future where someone searches for instances of these data attrs, finds none within the studio and then marks them for deletion.
  • If there isn't an existing convention, is it worth just attaching inline comments to these?

• As above, how customisable should PTE and all rendered output be? Perhaps a convention could be made where if we are applying styles-in-js, that we provide a data-attr / escape hatch for users to override these externally.
  Nothing that needs to be actioned any time soon, but perhaps worth formalising eventually (especially as we start to see more PTE usage within the studio outside of document forms)

I am ok with approving this though your questions are valid. I am not sure what is the best forum for this 🤔 maybe this is something that should be brought up with you joining the weekly sync or maybe I can bring it up? I'm not sure! @jtpetty would that be the right course of action?

[robinpyon]

Thanks @RitaDias – just added inline comments until we have more guidance here

[RitaDias]

👍