Difference from Data Field?

Created on 15 November 2023, about 1 year ago
Updated 7 December 2023, 12 months ago

Problem/Motivation

I am currently investigating options to implement the functionality provided by the Custom Field module in a new project. I also came across the Data Field module. I am wondering about the differences between the two modules. As far as I can see, the data structure (and probably performance, which is an important issue for me?) of both approaches is similar, but I might be missing something. Data Field also has the entity reference function implemented, which is also one of the important projects of this module. Thanks for any info.

💬 Support request
Status

Closed: works as designed

Version

2.0

Component

Documentation

Created by

🇮🇪Ireland marksmith

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @marksmith
  • 🇺🇸United States apmsooner

    Hey Mark, I think they are similar in alot of regards but here are a few considerations:

    • Entity reference support - there are considerable factors in entity reference that I don't believe their implementation accounts for which is currently holding me back from supporting it in custom_field module. The biggest issue for me with this is the risk of recursive rendering (in the entity formatter) which could effectively crash your site. I won't fully support this until that is solved. Decoupled sites also need to account for computed properties to support the includes for these references in jsonapi. Entity reference support is just REALLY complex and can really be risky if not carefully developed.
    • Link + Linkit support - Datafield to my knowledge doesn't provide link/linkit widget support to the extent that custom_field does.
    • Unit testing + configuration schema - Datafield doesn't provide any config schema which will break unit tests and not fully provide multilingual support. Unit testing provides higher probability that the module is stable to use.
    • Flexbox form display - I think custom_field provides a very flexible way to build complex form layouts.
    • Extensibility - One of the biggest challenges in composed field modules like this is the potential lockin of field model once data exists. We've created a service (documented here: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... ) that supports adding/removing columns to existing fields while preserving your data. This service does alot under the hood in a very systematic way to ensure your site remains functional while providing extensibility to your field.
    • Documentation - We provide extensive documentation IMO over and above most other contrib modules.
    • Multi-value field support - I can't speak for datafield but we've verified it works i custom_field, provided instruction to patch core to enhance and have unit tests to support our case.

    I think there are some other differences in types of field support, widgets, formatters, the UX for settings, etc... up for consideration as well but currently what we're providing I think solves most use cases and have a good amount of testing in place to ensure the module is stable to use. New features are always welcome and up for consideration here if you see something that would be useful that is currently missing. Hope that helps!

  • 🇮🇪Ireland marksmith

    Thanks for the prompt and detailed reply! After a closer look at how the two modules work, I do indeed appreciate the attention Custom Field gives to testing, detailed documentation, and also the probable use case where an existing data structure needs to be extended at some point. I do find, however, that implementing some support for entity reference would greatly enhance the usability of this module. Doesn't Drupal's built in recursive rendering protection provide sufficient assurance for what you are fearing of?

  • 🇺🇸United States apmsooner

    No, we have a challenge with this that has to be solved within the module. You can try datafield and see if it works okay for you but I don't feel comfortable yet merging in the work i've done so far https://www.drupal.org/project/custom_field/issues/3390339 Entity reference field type, widgets & formatters Active to fully support entity reference. Trust me... I'd love to have it too but it needs to be done right. To test if datafield works, i'd say setup a reference on one entity to another entity and vice versa so the 2 reference eachother and set the formatter to render the entity. If it works for you, feel free to go with datafield but I don't currently yet have a solution in our module to prevent recursive issue from happening. I've put it on hold for now until i have more time to revisit.

  • 🇮🇪Ireland marksmith

    Okay, just for the record, in case others arrive at this page with similar questions related to the two modules.

    I checked the entity reference problem you discuss above on DataField with the following setup (that you recommended on the page linked in your comment above):
    1. I set content entity A(rticle) to reference content entity B(asic page) and entity B reference entity A.
    2. The references are working as expected if on the manage display setting the formatter type is selected as "Label" on both entity types.
    3. This setup does not appear to work if the formatter type of the entity reference field is changed to "Rendered entity" on one or both content types. (Both modules are new to me and I am not competent enough to say whether this is related to the recursive rendering issue discussed above [no error log messages]. At any rate, if I reset the formatter type to "Label" on one of the entities [!], the content displays are working again [one rendering the label, and the other one rendering the entity]).

    Thanks again!

  • Status changed to Closed: works as designed 12 months ago
Production build 0.71.5 2024