Introduce allow-list and disallow-list for blocks #3471
Labels
Comments
Love it |
(Stupid) Questions
|
|
Thanks @ttahmouch for asking these questions, here are the answers:
That's a good question and to be honest, I don't have a clear answer, from my POV, the offered blocks could be restricted by multiple variables but for the purpose of this task, I think it's out of the scope since we'll only provide the mechanism to restrict them and not the logic to determine the offered blocks.
It will depend on the case, but in any case, this will be handled by the client that embeds the Gutenberg editor, not the editor per se. Following with my previous answer, the logic for determining the available blocks is out of the scope. |
ttahmouch
pushed a commit
to ttahmouch/gutenberg-mobile
that referenced
this issue
Aug 5, 2021
This is meant to be treated as a request for comments. I haven't spent a lot of time trying to document everything yet. I did spend some time writing type declarations in JSDoc until my comments ended up becoming larger than the actual implementation itself to which I started to question the value at that point. I can include them if it makes sense to do so. The general idea behind this work is that there is a desire to allow the Gutenberg Block Editor to restrict the block types it offers in various contexts it is presented in to the customer. The changes found here should, in theory, only impact the blocks presented in the block picker, and not affect the blocks displayed within the editor if someone were to manually modify the markup. The "requirements" that I thought seemed reasonable to me would be: + If you pass in neither an allow list nor a disallow list, then proceed by using all core blocks. + If you pass in an allow list, and not a disallow list, then proceed by only including what is in the allow list from the entire set of core blocks. + If you pass in a disallow list, and not an allow list, then proceed by including the entire set of core blocks sans the blocks in the disallow list. + If you pass in both an allow and disallow list, then proceed by removing blocks named in the disallow list first and then only keeping the blocks named in the allow list from the resulting set of the disallow list. However, this use case isn't realistic in my opinion. The consumer should only provide an allow or disallow list whichever is more convenient for the context. An allow list is preferred when the amount of blocks we'd like to present to the customer is small. The disallow list is preferred when the amount of blocks we'd like to present is large. + If you pass in an allow list that does not include `core/paragraph`, as that appears to be the minimum needed block, then ensure it's included in the allow list. + If you pass in a disallow list that includes `core/paragraph`, then ensure it is removed from the disallow list. I made an assumption that `core/paragraph` was a require block at minimum because when the disallow list didn't allow it to be registered, the application would crash at runtime. So I made a "needed blocks" list to make vital blocks be ignored from the allow or disallow lists. I can add tests that reflect the requirements defined above. I did look for existing tests for this module and wasn't able to find them, but I may just not be understanding the general testing strategy. + `packages/block-library/src/common.js` - I added a new `common` module to be shared between the entry point module for `web` and for `native`. Otherwise, I would likely have to add a duplicate implementation of the newly introduced `registerCoreBlocksByName` function, and that causes IDE warnings about redundancy. + `packages/block-library/src/index.js` - I exposed an entry point to register a subset of the complete collection of Gutenberg Editor Core Blocks called `registerCoreBlocksByName`. It is intended to allow registration of a subset of blocks by their `name` defined in their respective `block.json` declarations. I gave some thought into whether or not more than the `name` field would be convenient if we'd like to overwrite other fields from the block declarations when registering, but I kept it simple for the sake of getting the general idea of the implementation across. That can always be a minor enhancement. + `packages/block-library/src/index.native.js` - I organized the general set of core blocks to be returned from a `__experimentalGetCoreBlocks` to keep it homogenous with the `web` entry point especially since `__experimentalGetCoreBlocks` and `registerCoreBlocks` are transitive dependencies of the newly added `registerCoreBlocksByName` function. I also exposed an entry point to register a subset of the complete collection of Gutenberg Editor Core Blocks called `registerCoreBlocksByName` to keep it homogenous with the `web` implementation explained above. + `packages/react-native-editor/src/index.js` - I updated the entry point of the `react-native-editor` package to accept two new props passed in from the native bridge within the WordPress Android or iOS apps called `acceptBlocks` and `rejectBlocks` to be treated as an "allow" and "disallow" list. The naming was difficult so I can rename it if something else may make more sense from the perspective of the consuming application. These two new props are passed to the new registration entry point, i.e., `registerCoreBlocksByName`. [3471](wordpress-mobile#3471)
2 tasks
ttahmouch
pushed a commit
to ttahmouch/gutenberg
that referenced
this issue
Aug 5, 2021
This is meant to be treated as a request for comments. I haven't spent a lot of time trying to document everything yet. I did spend some time writing type declarations in JSDoc until my comments ended up becoming larger than the actual implementation itself to which I started to question the value at that point. I can include them if it makes sense to do so. The general idea behind this work is that there is a desire to allow the Gutenberg Block Editor to restrict the block types it offers in various contexts it is presented in to the customer. The changes found here should, in theory, only impact the blocks presented in the block picker, and not affect the blocks displayed within the editor if someone were to manually modify the markup. The "requirements" that I thought seemed reasonable to me would be: + If you pass in neither an allow list nor a disallow list, then proceed by using all core blocks. + If you pass in an allow list, and not a disallow list, then proceed by only including what is in the allow list from the entire set of core blocks. + If you pass in a disallow list, and not an allow list, then proceed by including the entire set of core blocks sans the blocks in the disallow list. + If you pass in both an allow and disallow list, then proceed by removing blocks named in the disallow list first and then only keeping the blocks named in the allow list from the resulting set of the disallow list. However, this use case isn't realistic in my opinion. The consumer should only provide an allow or disallow list whichever is more convenient for the context. An allow list is preferred when the amount of blocks we'd like to present to the customer is small. The disallow list is preferred when the amount of blocks we'd like to present is large. + If you pass in an allow list that does not include `core/paragraph`, as that appears to be the minimum needed block, then ensure it's included in the allow list. + If you pass in a disallow list that includes `core/paragraph`, then ensure it is removed from the disallow list. I made an assumption that `core/paragraph` was a require block at minimum because when the disallow list didn't allow it to be registered, the application would crash at runtime. So I made a "needed blocks" list to make vital blocks be ignored from the allow or disallow lists. I can add tests that reflect the requirements defined above. I did look for existing tests for this module and wasn't able to find them, but I may just not be understanding the general testing strategy. + `packages/block-library/src/common.js` - I added a new `common` module to be shared between the entry point module for `web` and for `native`. Otherwise, I would likely have to add a duplicate implementation of the newly introduced `registerCoreBlocksByName` function, and that causes IDE warnings about redundancy. + `packages/block-library/src/index.js` - I exposed an entry point to register a subset of the complete collection of Gutenberg Editor Core Blocks called `registerCoreBlocksByName`. It is intended to allow registration of a subset of blocks by their `name` defined in their respective `block.json` declarations. I gave some thought into whether or not more than the `name` field would be convenient if we'd like to overwrite other fields from the block declarations when registering, but I kept it simple for the sake of getting the general idea of the implementation across. That can always be a minor enhancement. + `packages/block-library/src/index.native.js` - I organized the general set of core blocks to be returned from a `__experimentalGetCoreBlocks` to keep it homogenous with the `web` entry point especially since `__experimentalGetCoreBlocks` and `registerCoreBlocks` are transitive dependencies of the newly added `registerCoreBlocksByName` function. I also exposed an entry point to register a subset of the complete collection of Gutenberg Editor Core Blocks called `registerCoreBlocksByName` to keep it homogenous with the `web` implementation explained above. + `packages/react-native-editor/src/index.js` - I updated the entry point of the `react-native-editor` package to accept two new props passed in from the native bridge within the WordPress Android or iOS apps called `acceptBlocks` and `rejectBlocks` to be treated as an "allow" and "disallow" list. The naming was difficult so I can rename it if something else may make more sense from the perspective of the consuming application. These two new props are passed to the new registration entry point, i.e., `registerCoreBlocksByName`. [3471](wordpress-mobile/gutenberg-mobile#3471)
This was referenced Aug 5, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The block editor will be used in various contexts, some of which (example: in the comments box in the WordPress apps) will need to restrict the block types offered.
Describe the solution you'd like
Let's introduce some form of allow-list for the list of blocks the editor should offer, and a disallow-list for the blocks that need to be unavailable.
For the time being, I'm thinking that those list should relate to the block picker, while the editor could still support any block in terms of rendering if found in the markup.
The text was updated successfully, but these errors were encountered: