[WIP] Add `blockTypesData` for additional props.

[cwmanning]

Specify (optional) blockType-specific data to pass as props on render.

Motivation

Imagine a component that selects from a list:

{
  id: 'animals',
  label: 'Animals',
  component: Animals
}

You use 'animals' in many places. But then a new component request comes in: it should be similar to 'animals', but filter results to show only warm-blooded animals.

Now you could create a brand new blockType, and that might be appropriate in certain situations. But in many cases, it would be simpler to reuse component logic with props.

Proposal

Use a new bootstrap options key, blockTypesData, as a map of blockType.id keys. The value for each key is an object, which becomes a part of the BlockType as data and spread as props for the component.

I'm open to approaching this in other ways. This is a first pass that I hope helps communicate the end goal.

[codecov-io]

Codecov Report

Merging #141 into master will decrease coverage by 0.16%. The diff coverage is 88.88%.

@@            Coverage Diff             @@
##           master     #141      +/-   ##
==========================================
- Coverage   93.49%   93.33%   -0.17%     
==========================================
  Files          33       33              
  Lines         246      255       +9     
  Branches       28       30       +2     
==========================================
+ Hits          230      238       +8     
- Misses         14       15       +1     
  Partials        2        2

Impacted Files	Coverage Δ
src/components/Block.js	96.15% <100%> (+0.32%)	:arrow_up:
src/plugins/bootstrap.js	94.11% <85.71%> (-5.89%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 0aa4658...6230591. Read the comment docs.

[cwmanning]

Thanks, @nhunzaker. And good suggestion on the name blockOptions! Planning to come back with some changes (along with coverage and docs) this week.

[solomonhawk]

Is there a reason for placing this config as an option in the call to instantiate CK? As an alternative, each item in the blockTypes array could contain a special key (e.g. blockOptions).

Both routes seem reasonable to me but specifying options for a particular block type within the block type definition kind of makes more sense to me.

./loosely-held-opinion

[solomonhawk]

A few additional thoughts based on a conversation with @cwmanning:

1. This feature generally unlocks the idea of "Parameterized Block Types", allowing a developer to re-use more code in the case where there are 2 or more block types that are similar but whose differences can be abstracted by a prop being passed in.

2. It makes sense to have some kind of options key in the block types definition.

3. There should also be the possibility to override that with a value passed in via an html attribute (from the backend).

I'm thinking it would be useful to have a few layers of configuration with the values specified directly on the input taking precedence.