-
Notifications
You must be signed in to change notification settings - Fork 108
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
[Feature Request] Ability to add an extension to a single Blueprint #417
Comments
Wouldn't they be able to use transformers for that? |
@ritikesh Only in certain circumstances. Transformers run after the object has been "hashified", whereas the Also, it wouldn't surprise me if we add more extension hooks in the future. Having an extension system with N hooks that can be used globally, class-wide, and in specific views strikes me as pretty powerful. They could in theory replace both transformers and extractors. |
IMO, the classes should be as simple as possible. We should consolidate all the currently available configurations and try to consolidate them to a good API. Which was the core feature of Blueprinter to begin with. Today we have a lot of default configurations, formatters along with extractors/transformers/extensions and some in-built magic with default views and fields etc. We should look at standardising some of these stuff into a more comprehensive and complete API. I had spoken about this earlier in the extensions PR as well, suggesting to remove the default formatters option in favour of the more expressive extensions. So can we also focus on this while we build around extensions? |
@ritikesh I'm sold. Maybe there should be a separate issue where we outline what we'd need to add to extensions so they could fully replace date formatters, extractors, and transformers (obligatory xkcd reference). This issue would be one of those bullet points, I suppose. Once all that's added to 1.x, we could remove date formatters, extractors, and transformers in a 2.0 release. |
Should we consider a discussion board for that to brainstorm? |
💯 Let's spin up a discussion for this! |
Link to discussion: #420 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Re-opening as this is in-progress for 2.0 (minus the "inline-block extension" bit). |
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
Extensions are only global. We have some people wanting to do something with a
pre_render
extension hook, but only in certain Blueprints. While that's technically achievable by adding the extension globally and doing a check on the passed-in Blueprint, that's pretty ugly.Describe the feature you'd like to see implemented
An
extension
orextensions
keyword in Blueprinter classes and views. I think they should be purely additive and inheritable across views. This is similar to how transformers can be used.Describe alternatives you've considered
transform
looks like a tempting option, but it's called too late. Thepre_render
hooks is ideal, except for being global.Additional context
I'm happy to work on this once we arrive at a good design. Some preliminary ideas:
The text was updated successfully, but these errors were encountered: