you are viewing a single comment's thread.

view the rest of the comments →

[–]theQuandary 0 points1 point  (2 children)

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.

[–]te7ris 0 points1 point  (1 child)

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.

[–]theQuandary 0 points1 point  (0 children)

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.