Ensure Content Block views are always loaded

[jesstelford]

Previous behaviour was to rely on manually importing a block for it to
be included (eg; unordered-list imports the list-item block). While
this is currently always the case, it doesn't necessarily have to be.

One example might be a 3rd party block which wants to create
heading+subheading pair, and set a dependency on the heading block
without ever importing it (instead; referencing it by its type name from
within the 3rd party block).

By surfacing the type on the server / during webpack build we're able to
do a couple more checks such as for duplicates and also replace the
sparse config array with a keyed object.

Finally, we can pull up the default paragraph block into the pre-build
step and remove that logic from the client code, making it a bit
cleaner.

[jesstelford]

Ensuring all the dependency's views are included in this list so they're always bundled even if they're not imported by another block.

[jesstelford]

I started out with all this in the index.js, but broke them out into individual files like this once I realised I need the paragraph.js for setting the default in Implementation.js.

I don't mind them being split out into separate files like this; it's reminiscent of the field types themselves. OTOH; I'm not against moving them back into index.js, it just means we'll end up with duplicate definitions for paragraph.js which is a bit icky. (same goes for the dependencies)

[jesstelford]

Making sure that every block type is bundled, even the dependencies, in case they're not imported directly.

[jesstelford]

Dependencies are already flattened pre-build in Implemenation.js, so there's nothing to do here.

[JedWatson]

@jesstelford looking good!

One thing that occurred to me; if the blocks are all loaded, always, is it worth having separate entrypoints for them? or could a higher level index just export { all, block, types }

I do like the individual files for block types (esp. that they are following patterns established by field types) but couldn't tell how having separate entrypoints interacts with your point about having extracted them all from the index and the reduced duplication.

Feel free to act / not act on this feedback, as-is looks good ✅

@mitchellhamilton this might be something to consider for #993, if that could work for block types as well as field types?

[jesstelford]

if the blocks are all loaded, always, is it worth having separate entrypoints for them?

All the blocks for that field are loaded.

For example;

Keystone.createList('User', {
  fields: {
    bio: {
      type: Content,
      blocks: [
        Content.blocks.link
      ]
    }
  }
});

Would load the link and the default paragraph blocks when landing on the Field view for the User list (ie; editing or adding a User).

Keystone.createList('Post', {
  fields: {
    bio: {
      type: Content,
      blocks: [
        Content.blocks.header,
        Content.blocks.unorderedList,
      ]
    }
  }
});

Would load the unorderedList, its dependency of listItem, and the default paragraph blocks when landing on the Field view for the Post list (ie; editing or adding a Post).

This way it only loads exactly what is required per field 👍

how having separate entrypoints interacts with your point about having extracted them all from the index and the reduced duplication.

The main one was the paragraph type; it's a dependency for a couple of the others and is referenced in the default list. Once I deduplicated that by putting it in its own file, I figured why not do it for the rest too.

[jesstelford]

Looks like I broke the tests - will fix them up then merge.

[emmatown]

@mitchellhamilton this might be something to consider for #993, if that could work for block types as well as field types?

It'll 100% work for block types.