Closed rangerscience closed 1 month ago
The changes enhance the react_component
and react_component_hash
methods in the ReactOnRails::Helper
module to accept block parameters, allowing for the inclusion of child HTML elements. The internal logic for rendering remains largely unchanged, but the handling of props
has been improved. Documentation updates clarify the new functionality and provide guidance on using render-functions and security considerations with dangerouslySetInnerHtml
.
Files | Change Summary |
---|---|
lib/react_on_rails/helper.rb | The react_component and react_component_hash methods now accept a block for child elements, initializing options[:props] with an empty hash if not provided. |
Documentation | Updated to include new functionality for passing blocks to react_component , clarifying render-functions, and addressing security concerns with dangerouslySetInnerHtml . |
In the garden of code where rabbits play,
New features bloom, brightening the day.
With blocks of joy, we nestle and weave,
React components dance, oh, how they believe!
Hopping through changes, we cheer and we sing,
For every new line, a fresh spring! π°β¨
@rangerscience Why not just pass the HTML as a prop and let the react component handle the HTML?
@rangerscience Why not just pass the HTML as a prop and let the react component handle the HTML?
Sure! So, then, if you want to have a React component that can take children when used from both Rails and other React components -
# Rails
<%= react_component "MyComponent" do %>
<%= render "events/form", event: Event.new %>
<% end %>
// React
const ParentComponent = () => {
return <div>
<MyComponent>
<div>Children!</div>
</MyComponent>
</div>
}
You'd need to do:
const MyComponent= () => {
return (
<div>
{ props.children }
{ props.children_html && <div dangerouslySetInnerHtml={{__html: props.children_html}} /> }
</div>
)
}
By having React on Rails turn the passed HTML into a React element, the React components don't have to "know" whether they're being invoked by the Rails layer or by the React layer - they get to act just like regular React components.
Given an easy work around, why expand the API?
Given an easy work around, why expand the API?
Sure! IMHO, developer happiness, least-surprise, and laziness. You can workaround both changes:
<%= react_component "MyComponent", props: { children_html: render_to_string("events/form") } %>
const MyComponent = () => <div>{ props.children_html && <div dangerouslySetInnerHtml={{__html: props.children_html}} /> } />
but this makes the developer's intention less clear (all we're doing is passing child elements, nothing more), requires boilerplate, and breaks expectations (causing surprise) - Rails templates can take blocks (presuming the template has a yield
); React components can take children
(presuming they put { children }
somewhere). Without these changes, neither is true for React on Rails components.
This API expansion allows both the Rails and React side of things to work as intuitively expected and in-line with the rest of their ecosystems. It's also a pretty minimal set of changes - four lines of code or so, depending on how you count? - so the maintenance cost should be minimal as well.
Those are some arguments for why this API expansion is worthwhile. If the debate is actually about the generalized debate over whether or not APIs should be expanded when workarounds are available, that's a different discussion that I'd be happy to have :)
Closing for now as this is easily done via the current API. @rangerscience could you provide a doc PR instead?
No worries, I'll just keep my fork up and running :) I've got some other changes I want to look at, so if I write up docs it'll be there (and after that), and at that point I'll welcome and help out if y'all want to open a PR from me to you.
I would recommend adding a bit to the docs pointing to this PR, if you want a quick and easy way to get someone this info - or, otherwise make sure the GH PR search pulls this up with search terms you'd expect someone to use.
I'm not sure if pointing the docs to the implementation of an added API that was not added will help.
Thanks in advance for docs on how to cleanly accomplish the goal with the existing API.
Summary
Allows you to do: (rails template)
(react component)
Note that this uses React's
dangerouslySetInnerHtml
, which... maybe isn't a good idea, but might be fine, since the HTML being set is coming in from the Rails template engine.You could just include the changes to the Ruby code so that the block gets rendered, and that gets passed in a a nice prop (like
children_html
) but then the React components would have to care about whether theirchildren
are coming in from more React code, or from the Rails side of things.Pull Request checklist
Remove this line after checking all the items here. If the item is not applicable to the PR, both check it out and wrap it by
~
.Add the CHANGELOG entry at the top of the file.
Other Information
As per the contribution guidelines, I'm supposed to run
rake examples:gen_all
, but that task doesn't existThis change isβ
Summary by CodeRabbit
New Features
react_component
andreact_component_hash
methods to accept child HTML elements via block parameters.ReactOnRails
to clarify new functionality and usage of render-functions.Bug Fixes