Improve standard part class resolution

[dry-rb]

Improve standard part class resolution

[GustavoCaso]

@timriley All of this ideas sounds great addition for the library.

Some of them a little magic ✨ but never the less really useful for the end user, having to write less code 😄

so there's no need to explicitly specify classes with as: options everywhere

If a value responds to #pager and #to_a, then it's a paginated collection, so the value itself should be wrapped in a PaginatedResults view part, and its children wrapped in parts according to the usual rules

I think that is great.

Maybe we can work this issue by splitting the different addition, so the end PR is not that big.
wtdt?

[timriley]

@GustavoCaso BTW, I don't think this thing is something dry-view should provide out-of-the-box:

If a value responds to #pager and #to_a, then it's a paginated collection, so the value itself should be wrapped in a PaginatedResults view part, and its children wrapped in parts according to the usual rules

What I do think we should do is make it easier for an app or framework to add this kind of behaviour without necessarily having to replace the whole default decorator.

[jodosha]

I agree, this would be a great addition. 👍

[timriley]

I want to update this issue with my current thinking.

• Resolving part classes from a specified namespace (e.g. MyApp::View::Parts)
• Allowing as: to be a symbol to indicate an alternative name to use for the part class resolution noted above

For these I think we should add a part_namespace setting and have dry-view by default look for part classes defined in that namespace matching the exposure's name (or as: :some_other_name option).

For inspiration on how this could/should work, we can look at how rom-rb's auto-struct feature works with its struct_namespace (though I'm not convinced over whether we should try and generate classes if they're missing within the namespace, or just fall back to the standard Dry::View::Part class).

• Running user-supplied arbitrary code to make additional assessments of a value before determining its part class

One option for this would be to pass the view controller pass itself to the decorator, which could then as part of its work look for and optionally call a #resolve_part_class method on the view controller. This would give view controller classes an opportunity to customise part decoration without having to replace the decorator object wholesale. Might be a reasonable approach?

We might want to think about whether this coupling between the view controller and the decorator is OK, but I think given the very specific job of the decorator, and how it's already in service to the view controllers (and nothing else), I think this should be fine.

If we did this, actually, we could actually greatly deemphasise the need for providing a custom decorator at all. Which I think is a good outcome. We'd leave it in there for advanced usage or very specific kinds of integrations, but for 99% of users, the idea of a "decorator" would actually go away.

• Allowing the above steps to be re-run for constituent members of a collection or aggregate value

I think we best support this by continuing to support exposure options like as: {:collection_part_name => :member_part_name}.

We probably want to find some way to provide the :collection_part_name only though... as: {:collection_part_name => nil}? That feels a bit gross though. as: [:collection_part_name]? That would be misinterpreted as being a way to provide the name for the member parts though...

Perhaps we actually move away from that hash-based value syntax to arrays only, so:

• Single-item array – as: [:collection_part_name] – specify collection part name only
• Two-item array – as: [:collection_part_name, :member_part_name] – specify both part names, collection first, then member.

This leaves the plain as: :member_part_name as it is currently, for providing the member part name only (leaving the collection to be kept as a plain array).

I don't mind this! Using the arrays to hold the options feels kind of good because it's a reminder that we're providing options for array values.

Another alternative could be to just add another option, so e.g. as: :member_part_name, collection_as: :collection_part_name.