Let me address the elephant in the room. You are a Rails engineer looking at React and somewhere in the back of your mind is the question: "Is this replacing me?" No. But ignoring it will replace you. Rails and React solve different problems. Rails renders HTML on the server. React builds interactive interfaces on the client. The industry wants both, often in the same application, and the person who understands both sides of that boundary is genuinely rare and genuinely valuable.
React's mental model will fight your MVC instincts. There is no controller dispatching to a view. There are components -- functions that take data in and return UI out. State lives inside components, not in a database-backed model. The flow is unidirectional: data flows down, events flow up. This is fundamentally different from Rails' request-response cycle, and trying to force MVC thinking onto React will make you miserable.
The moment it clicks is when you stop thinking about pages and start thinking about composition. A Rails view is a template that renders a page. A React component is a building block that composes with other building blocks. Your sidebar is a component. Your button is a component. Your entire page is a component made of components. This is closer to Ruby's module composition than to ERB templates.
Kent Dodds' Epic React is worth the money. I say this without reservation. The exercises are what make it stick -- not the videos, not the docs, but the act of building things, breaking them, and rebuilding them. This is the same way you learned Rails: by building apps, not by reading the guides.
Hooks will confuse you for about two weeks. useState is fine. useEffect will make you angry. The dependency array is a footgun that has bitten every React developer alive. Push through it. Once you internalize the mental model -- effects synchronize your component with external systems -- the confusion lifts.
Do not learn class components in depth. They are legacy. Hooks won. Spend your time on the modern API.