[2.0.0-alpha2] Formatters: technical feedbacks from alpha1

hook_field_formatter_info_alter

Can you tell in a comment the reason why you are altering your own plugins in .module:

function ui_patterns_field_formatters_field_formatter_info_alter(array &$info) {
  /** @var \Drupal\Core\Field\FieldTypePluginManagerInterface $field_type_manager */
  $field_type_manager = \Drupal::service('plugin.manager.field.field_type');
  $field_types = array_keys($field_type_manager->getDefinitions());
  $info['ui_patterns_all']['field_types'] = $field_types;
  $info['ui_patterns_each']['field_types'] = $field_types;
}
 

It is because it is impossible to assign a field formatter to every field types using the plugins annotations, but not everybody know that.

Why do we need so much cache invalidation?

3 times in .module:

\Drupal::service('plugin.manager.ui_patterns_source') ->clearCachedDefinitions();

2 times in UiPatternsFieldFormattersEntitySchemaSubscriber

$this->uiPatternsSourcePluginManager->clearCachedDefinitions();

Maybe there is something wrong about cache definition somewhere.

Mapping is done on field types instead of field property types

FieldPropertiesSourcePropDeriver::getPropTypeToFieldTypeMap() has a $prop_mapping variable with field types as values:

    $prop_mapping = [
      'string' => [
        'changed',
        'created',

This is not the mechanism described by the specifications.

Using field types instead of field property types, we are forced to maintain an always evolving list of field types, from core, contrib & custom.
We are pulling the data from field properties to component props anyway, so why not mapping field property types to prop types?

Remove PHPMD Naming annotations

Example:

 * @SuppressWarnings(PHPMD.CamelCaseParameterName)
 * @SuppressWarnings(PHPMD.CamelCaseVariableName)
 * @SuppressWarnings(PHPMD.LongClassName)
 * @SuppressWarnings(PHPMD.LongVariable)

Because we are not running this test which is incompatible with Drupal standard. We are only running codesize, unusedcode & design.

So much plugins :)

I know you warn us about this implementation decision in January, but I am still uncomfortable with deriving source plugins, one source for each property of each field of each content of each bundles of each content entitty types of the website. Even if we never use 99% of them.