-
Notifications
You must be signed in to change notification settings - Fork 79
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: Enhancing the node object itself before rendering a react component #38
Comments
Your best bet is to write a PR with a test for the scenario you're trying to solve, and preferably a corresponding implementation. |
You can get the same result by enhancing the node and then passing to the default render. You can modify anything including the node 'name' to swap say
|
@nickpalmer Do you think we can close this? |
I think this is still a reasonable feature suggestion in that it would give you a pre-process pass in the pipeline, which would be a nice enhancement to the single pass processing now. I would personally think of it as a pre-process step instead of "enhance", but that is just verbiage. I would label it as a 'feature-request' and 'needs-help' and leave it open if I were managing the project, but up to you. Alternatively I would update the documentation to discuss being able to insert a 'pre-process' transformation step in any processNode handler to address the use case and then close it. Basically this request wants processDefaultNode to be enhanced with a single line and a trivial function, so I think it is a small PR overall and a nice addition to the API but can be accomplished with the default mechanism at the expense of adding one line to EVERY processNode step in the users pipeline. An implementation is almost trivial. Without looking at the existing code:
|
I would like to have your input if this feature would be a sensible addition to the library.
You can definitely do this with the current implementation it is just not as straight forward.
Problem:
I have multiple ProcessInstructions which rely on shared code.
e.g. rewriting classes, custom handling for on-handlers, custom handling of root/leaf nodes,...
Suggested change:
The text was updated successfully, but these errors were encountered: