Include fraction decimal in JSONAPI

An example of the JSONAPI response for a farmOS quantity entity with a fraction field named "value":

"type":"quantity--standard",
"id":"90b8c2b6-f664-43ad-8781-fa2a7eb68cc2",
"links":{
   "self":{
      "href":"http://localhost/api/quantity/standard/90b8c2b6-f664-43ad-8781-fa2a7eb68cc2"
   }
},
"attributes":{
   "drupal_internal__id":1089,
   "drupal_internal__revision_id":1093,
   "revision_created":"2021-10-12T20:44:21+00:00",
   "revision_log_message":null,
   "measure":null,
   "value":{
      "numerator":123,
      "denominator":1,
      "value":"123.000000000"
   },
   "label":null,
   "created":"2021-10-12T20:44:07+00:00",
   "changed":"2021-10-12T20:44:07+00:00",
   "inventory_adjustment":null
},
"relationships":{
   ....

This kinda makes we wonder if this property should be named decimal instead. I think that might make more sense to the JSONAPI consumer that is unfamiliar with Drupal, but make less sense in the context of Drupal entity API and common conventions.

I think these titles change when the issue fork branch is changed from the default name?

It actually might be *good* to avoid value so that folks who *are* used to Drupal conventions are forced to understand that this is *not* a normal value field.

Ohh interesting. I was starting go back on this, but this is a good point. +1

If we do change to decimal, does that affect #3243488: Allow fraction field item value to be set from a decimal value at all?

Not that I can think of, other than changing some strings from value to decimal. Shall we give it a go?

I think we should add some tests for this, though - even though it's so simple. It feels like the type of thing that could accidentally regress in the future if someone removes that line without understanding why it's there.

That's fine. It should be simple to add a test ensuring the field is not internal. Considering that we want tests in this other issue, that would actually be a good reason to start a new kernel test. Might as well start simple and merge this, then we can tackle the other issue. I'll work on tests tomorrow.

It actually might be *good* to avoid value so that folks who *are* used to Drupal conventions are forced to understand that this is *not* a normal value field.

I made this change but noticed that the fraction formatter was actually using the value property itself. I changed the formatter to use decimal instead, but it just feels like this could be a bit of a BC.

I tacked on one last commit that adds back the value property but keeps it internal so that it is still excluded from the API. Maybe we could make the value property trigger a deprecation warning by creating a dedicated FarmDecimalPropertyDeprecated class? Not sure how concerned we are about this. It doesn't look like farmOS 2.x uses the value property right now, but I know we aren't the only users of Fraction!

I think we should add some tests for this, though - even though it's so simple.

This was actually pretty easy! I was able to re-use an existing kernel test class - generalized it from testing only "generate sample values" to testing the FractionItem more generally. Added some simple assertions in a new testFieldProperties() function.

On a new note... I'm a little curious why the fraction value/decimal property always uses a precision of 9? https://git.drupalcode.org/project/fraction/-/blob/2.x/src/FractionDecim...

Any reason this can't just be auto? I might be missing something! I see the comment about ensuring validation, but don't understand. Maybe the validation function could explicitly convert to decimal with a precision of 9? More context in this comment from @pcambra: https://www.drupal.org/project/fraction/issues/3095746#comment-13450953

Woohoo, thanks @m.stenta! It seems that issue is fixed now? Can we close this issue?