Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC]: Make AbstractHelper internal and Guarantee a renderer for existing implementors #120

Open
gsteel opened this issue Jan 14, 2022 · 0 comments
Labels
Milestone

Comments

@gsteel
Copy link
Member

gsteel commented Jan 14, 2022

RFC

Q A
Proposed Version(s) 3.0.0
BC Break? Yes

Goal

To further improve SA and minimise the number of checks for "Do I have a renderer yet", either make the renderer a constructor dependency for HelperPluginManager (And provide a factory) or throw an exception on retrieval if null, effectively making the signature for HelperPluginManager::getRenderer(): RendererInterface and the signature for AbstractHelper::getView(): RendererInterface (i.e. enforce a return type) … It would also be a good idea to update the signature for HelperInterface::getView()!

Background

This was recently surfaced in slack because until recently, the documented return type for AbstractHelper::getView() was changed from RendererInterface to RendererInterface|null (The latter being what it actually is). Consumers extending AbstractHelper now have errors in their SA tools.

Guaranteeing a renderer for both of these will likely solve a large number of possible type errors and make the public api of the package easier to work with.

Considerations

There will be a number of laminas packages affected by this change that will require work to upgrade to 3 - at least i18n, flash-messenger, form and likely more.

The signature changes will potentially affect any consumer that has extended AbstractHelper - the impact is unlikely to cause to many problems unless they have re-implemented the getView() method which is unlikely

Proposal(s)

  • Change the docs for "Advanced Helper Usage" so that the examples of creating and registering helpers do not extend AbstractHelper providing examples of a simple invokable as well as a helper having constructor dependencies along with an example factory with instructions on registering plugins.
  • Change the return types for methods retrieving the underlying view renderer and make them exceptional
  • Update all callers of these methods, fix broken tests and introduce new tests to cover the changed behaviour
  • Mark AbstractHelper as @\internal to discourage extending it outside of the package
@gsteel gsteel added the RFC label Jan 14, 2022
@gsteel gsteel added this to the 3.0.0 milestone Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant