That's still a rather easy solution compared to quite a number of frameworks.
When your component mounts into the DOM, you then wire in whatever DOM-manipulating library you're using to the local DOM element(s). To prevent React from interfering, you use shouldComponentUpdate to trap and handle any data updates and return false (so no re-render). In the componentWillUnmount stage, you unwire whatever you're using.
Two and a half out of three of those are things you'd need to be doing anyway. The only major change is returning false to prevent re-rendering.
Yeah I know that but I had that experiment where I wanted to combine both worlds. I wanted to use the react-rendering and the DOM-manipulation of the lib.
Imagen multiple React-Components nested into eachother and one 3rd-Party lib that potentially manipulates any of the DOM.
I see what you're saying, but even CRUD apps that are rendered server-side can't usually deal with the idea that you'll modify any number of templates. That is asking for major breakages on pretty much any non-trivial website. Even without React there's a need to isolate your side effects to something manageable.
1
u/theQuandary Aug 28 '15
That's still a rather easy solution compared to quite a number of frameworks.
When your component mounts into the DOM, you then wire in whatever DOM-manipulating library you're using to the local DOM element(s). To prevent React from interfering, you use shouldComponentUpdate to trap and handle any data updates and return false (so no re-render). In the componentWillUnmount stage, you unwire whatever you're using.
Two and a half out of three of those are things you'd need to be doing anyway. The only major change is returning false to prevent re-rendering.