Implement association as it's own thing

[sandstrom]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe

Right now, association is internally implemented as a field, with a magic :assocation option.

Describe the feature you'd like to see implemented

I'd implement association as a proper class internally, similar to Field.

    def self.association(method, options = {}, &block)
      validate_blueprint!(options[:blueprint], method)

      make_association(
        method,
        options.merge(
          extractor: options.fetch(:extractor) { AssociationExtractor.new }
        ),
        &block
      )
    end

Describe alternatives you've considered

No response

Additional context

No response

[sandstrom]

Happy to discuss this in more detail, and elaborate more.

[sandstrom]

Friendly ping @lessthanjacob @njbbaer @ritikesh

If you think this is a reasonable suggestion, let me know! If so, I'd propose these steps:

• I'll flesh out the proposed change in some more detail (written, in this issue)
• You get another chance to provide more feedback, and if you're happy we'll open a PR

For reference, there are also a few other issues that I've opened, where I'd also be happy to get your input.

Full list

• Move global configuration #403
• Extractor configurability #404
• Separate internal options from external ones #405
• Deprecate DateTimeFormatter #406
• Implement association as it's own thing #407

[sandstrom]

Friendly ping @lessthanjacob @njbbaer @ritikesh

Happy to hear your thoughts on this!

[ritikesh]

What would the responsibilities be of this Association class outside of how it's being handled within the ViewCollection/View contexts today?

[sandstrom]

It would be a sibling class next to Field. It would work just the same as the Field class does today.

Mostly just seemed like a design that's easier to comprehend, because right now an association is a field with the "magic" option called :association with value true.

That said, I don't feel strongly about this.

An alternative would be to turn it into a property on the field (similar to what's proposed for the other magic options in #405).

[ritikesh]

They do behave similarly. It's just a readability thing with no major functional differences barring associations having their own blueprinter/view based rendering.

An alternative would be to turn it into a property on the field (similar to what's proposed for the other magic options in #405).

At this point, I'm not strongly for/against this one either. But the trend seems to be in the direction of major rewrites and as long as there's no/little impact to the consumers, this should still be ok.

@jmeridth / @njbbaer - any thoughts from your side?

[ritikesh]

in fact, many fields have additional options too - like date_time formatter (which we're planning to get rid off too in favour of extractors). If we're able to achieve consistency in terms of the options that required for defining a field and an association with them being unique to their own types, then I think this might make more sense.