[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%)	⬆️
src/plugins/bootstrap.js	94.11% <85.71%> (-5.89%)	⬇️

---

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.

[dlederle]

👍for the idea. I'll defer to someone who knows more about CK internals to say if this is a good implementation for it.

[dlederle]

✂️

[cwmanning]

for sure! left this here just for demonstration purposes.

[nhunzaker]

This looks good to me. We should add documentation for it.

What about calling this blockOptions? Additionally, we could expose the ability to add a static to each component to provide defaults, like:

class YouTubeBlock extends React.Component {
  static options = {
    name: "User"
  }
}

let editor = new ColonelKurtz({
  // ...
  blockTypeOptions: {
    youtube: { name: 'Chris' }
  }
})

We'd also pass the value as options to the block.

[cwmanning]

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

[nhunzaker]

I'm worried this will cause bugs where an option field could clear important block properties. What if this were passed as options={options}?

[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.