Magento 2: Clear Direction on Controller Result Factories

Question

In a controller's execute method, has there been any clear guidance from the Magento core team if client developers should

1. Be using the individual PageFactory, JsonFactory, RawFactory, etc objects

2. Or using the more generic Magento\Framework\Controller\ResultFactory object along with the ResultFactory::_TYPE constants

when they want to instantiate an object to return?

If you're not familiar with the issues/confusion around this, I'm talking about the things in the following post. It's not clear if, going forward, Magento's supporting all these methods, or if there's a particular style/technique they prefer (and will support) going forward.

Answer 1

Both methods will be supported in foreseeable future.

Generic factory was introduced first. It's easy to work with it especially when your action controller might return different result types depending on request data.

Specific factory types were introduced to solve problems with type safety and auto-complete. It's less convenient to work with specific factories (1 constructor dependency per return type), so generic factory was kept as an alternative.

Idea to add specific factory methods to generic factory for each result type is being discussed now. It will solve both problems: convenience and type-safety.

Answer 2

I always favor the specific individual factories, because of the following benefits:

• They give proper method auto-completion on the created result object without a PHPDoc type hint (once the factory has been generated). A PHPDoc type hint can be used to work around that, but many comments become lies over time when the implementation changes, but the comments are not updated.
• The result types that the action controller might return are clear to see by looking at the constructor parameters.
• Less coupling to implementation details of the generic ResultFactory (e.g. the type code constants).
• Less coupling with the parent Action class by relying on protected properties, so one less potential breaking point during upgrades.
• Easier to write readable tests (no willReturnMap() for a mockResultFactory is required).