Support definition of public frontend attributes and only serialize those

[luisherranz]

Use a new attribute property to whitelist the attributes that are sent to the client:

{
  "attributes": {
    "message": {
      "type": "string",
      "source": "text",
      "selector": ".title",
      "frontend": true
    }
  }
}

We can use getBlockType (from the "core/blocks" store) in the save component wrapper to access the block.json and filter the data-gutenberg-attributes.

There are two things we should make decisions:

• Name: it could be view, frontend, or something else. I guess we need to decide the final name we are going to propose and be consistent.
• Opt-in or opt-out: whether this would be true or false by default. If it's opt-out, the block should opt-in to attribute serialization in some other way to avoid security issues.

[fabiankaegy]

I'm curious about the rationale for this mechanism? I'm having a hard time coming up with many examples of attributes that should not be exposed to the frontend 🤔

There have also been discussions about this in Gutenberg WordPress/gutenberg#29693

In the end something like an internal or private flag would be the better API. Would love to hear use cases for truly private attributes though. Things like API Keys etc would never be stored in attributes because that would mean the user would need to provide it with every single block instance instead of some global data store.

[michalczaplinski]

Name

I think that the name frontend is better than view. As far as I can tell, it's also the generally accepted term for what we're referring to here. But that's probably one of those things that we should decide by asking a few more people.

Opt-in or opt-out

I don't have a very informed opinion here. It seems that it should be opt-in because of the potential for security issues if someone an accidentally exposes a sensitive attribute.

[fabiankaegy]

It seems that it should be opt-in because of the potential for security issues if someone accidentally exposes a sensitive attribute.

whilst I get that we should always be very cautious about these things I don't think you can treat attributes as they exist in Core right now as sensitive information. Except for maybe cases where you use Dynamic Blocks that use PHP rendering to intercept the rendering all the attributes will be exposed on the frontend anyways 🤔

And having this be opt-in only would result in a lot of not really needed boilerplate that I don't think serves anyone.

My vote would be for this to be opt-out. But of course, I'm also happy to be wrong here :) Just want to share my perspective :)

[luisherranz]

I'm with Fabian in this one. Secret attributes will be a rare thing. But whatever we decide here is not very relevant as the real conversation will happen once/if we present this in a Gutenberg issue/PR.

Whether it is opt-in or opt-out, the implementation would be similar. So let's add the opt-in here, which is more explicit.

[luisherranz]

let's add the opt-in here, which is more explicit

Oh, @michalczaplinski already did in #15. That's fantastic 😄