Provide a hook for custom ActiveModel types

[rzane]

Motivation

We use ActiveModel::Attributes extensively. In many cases, we're passing complex values to these models, such as a User. It wouldn't be practical in our situation to define an ActiveModel::Type class for each and every possible value that gets passed into a model.

Any of the following solutions would solve my issue:

1. Explicitly tell Tapioca the type of a given attribute.
2. Explicitly tell Tapioca to skip type generation for a given attribute, which would allow me to write my own compiler for these specific attributes.
3. Allow compilers to override the types defined by other compilers (similar to Add explicit ability to choose order of Tapioca compiler execution #1965).

Implementation

This PR allows instances of ActiveModel::Type::Value to define an optional method #__tapioca_type. It returns a type.

For example, you could use this hook to implement an interface like this:

class GenericType < ActiveModel::Type::Value
  def initialize(type)
    @type = type
  end

  def __tapioca_type = @type
end

class User
end

class Foo
  include ActiveModel::Attributes

  attribute :user, GenericType.new(User)
end

Tests

Tests are included.

[paracycle]

It wouldn't be practical in our situation to define an ActiveModel::Type class for each and every possible value that gets passed into a model.

You can define a "generic" ActiveModel::Type subclass and use it to supply such a hook, provided we add support for it in Tapioca.

For example:

class GenericType < ActiveModel::Type::Value
  def initialize(type)
    @type = type
  end

  def __sorbet_type = @type
end

class User
end

class Foo
  include ActiveModel::Attributes

  attribute :foo, GenericType.new(User)
end

p Foo.attribute_types.first.last.__sorbet_type # => User

[rzane]

Thanks for the suggestion @paracycle. I'll update this PR to work that way.

[rzane]

PR updated. Thank you for the suggestion. I think this is a much better solution.

[amomchilov]

Hey @rzane, we like this change and want to merge it in. We just got a bit of internal feedback, that this method is really more for Tapioca, and not Sorbet itself.

__type_for_tapioca and __tapica_type was suggested, which would make that more clear, and better help readers understand where to look for callers of this (seemingly unused) method.

Would you mind renaming the method to one of those?

[rzane]

Thanks @amomchilov, updated 👍

[rzane]

I just want to call out that there might be an existing convention for this sort of thing:

tapioca/lib/tapioca/dsl/compilers/json_api_client_resource.rb

Lines 149 to 150 in cb40b4d

	sorbet_type = if type.respond_to?(:sorbet_type)
	type.sorbet_type

The type isn't used by Sorbet directly, but it does have to be a type that is compatible with Sorbet and will eventually be consumed by Sorbet after generating DSL files.

[rzane]

@amomchilov are there any remaining blockers here?

[amomchilov]

Nope, looks good! Thanks for the changes.

I'm deprecating #sorbet_type and renaming it to match, in #2125.