Decide how to use namespaces in the store

[luisherranz]

I have been talking to @SantosGuillamot and we thought that just using the namespace after state, actions, effects, etc, should be enough to avoid collisions.

The namespace should be the same as the one used in the blocks, defined in the documentation as:

The name for a block is a unique string that identifies a block. Names have to be structured as namespace/block-name, where namespace is the name of your plugin or theme.

Within the namespace, developers can do whatever they want. If they define values in the root, they will be as global values to their namespace, and if they have several blocks with properties that may conflict, they can also use the names of each block to further subdivide the state.

The definition of a single store would look like this:

store({
  state: {
    myPlugin: {
      // Inside state.myPlugin, the creator of my-plugin can organize whatever they want.
      value: 123,
      someBlock: {
        value: 456,
      },
      otherBlock: {
        value: 789,
      },
    },
  },
  actions: {
    myPlugin: {
      // Inside actions.myPlugin, the creator of my-plugin can organize whatever they want.
    }
  }
});

And a complete store would look like this:

{
  state: {
    woo: {
      value: 123,
      cart: {
        // ...
      },
      filters: {
        // ...
      },
    },
    myPlugin: {
      value: 123,
      someBlock: {
        value: 456,
      },
      otherBlock: {
        value: 789,
      },
    },
  },
  actions: {
    woo: {
      // ...
    },
    myPlugin: {
      // ...
    },
  },
};

Thoughts?

cc: @WordPress/frontend-dx

[luisherranz]

We also need to decide if the standard inside the store will be camel case or snake case:

store( [
  "state" => [
    "myPlugin" => [
      // ...
    ],
    "my_plugin" => [
      // ...
    ]
  ]
] );

store({
  state: {
    myPlugin: {
      // ...
    },
    my_plugin: {
      // ...
    },
  },
});

[DAreRodz]

I would choose camelCase 🐫 . Most of the time, developers will interact with the store inside actions, derived state, etc., and, as those should be written in JS ―where the camel case convention is more widespread― I think it's the one that would make more sense.

Also, although snake case is more common in PHP, in this situation, we're talking about array props ―which are strings―, not variable or function names. And there is a precedent in Gutenberg; for example, properties defined in block.json are in camel case, and when you want to use them inside a render_callback or render.php, you do, e.g., $attributes['textAlign'].

This is just my personal opinion, though. I want to read others as well. 😄

[SantosGuillamot]

I'd like to resume this conversation. It seems there are two main questions here:

• Is namespaces enough/the right way to avoid collisions?
• Should we use camel case or snake case? Keep in mind that parts of the store will be defined in PHP and other ones in JS, but they have to match.

[luisherranz]

Sure. No one has objected, so let's go with camel case (I agree with David's arguments) and a single namespace for the proposal 🙂

[SantosGuillamot]

Closing the issue with the decision made. We can always reconsider it and reopen the issue if needed.