Limitations

[Olical]

I feel like people are expecting this to work out of the box with every stateful, event or timer based D3 concept / plugin, that's just not going to happen. If your D3 component is stateless, it will work beautifully. If it involves a little state that you can move into the React state system it'll also work beautifully.

If you're trying to use a plugin or something that holds internal state and references to DOM nodes...

This is intended to clarify what you should and shouldn't do with react-faux-dom. React doesn't work with mutations like the old dark days where we simply thrashed the DOM with jQuery, Mootools, D3 or whatever else you used back then.

We should build pure stateless components, this isn't supposed to make those old stateful ones work with React out of the box, it's just here to adapt things like D3 to the render function oriented architecture of React.

In theory this will close #29, #28, #21, #20, #14 and #4. All of those are things you could probably get working by playing about with your state management, they are not concerns of react-faux-dom. In my opinion.

If there's missing methods to search or modify elements, sure, let's add those. But we shouldn't be hacking around just to appease some internal D3 mechanic that happens to rely on the fact that it can usually mutate the DOM however it wants.

I hope this clears some things up and doesn't upset / anger anyone! I'm just trying to set expectations as early as possible.

Thoughts?

[thinktainer]

One thing I had real trouble with figuring out, was how to get an initial measurement for a width for my dom element. This has nothing to do with this library, but might be a useful tidbit for the documentation. I solved it by using the parent's componentDidMount() with a ref to the container node , and then triggered another render via this.setState(). I couldn't find a more elegant way to solve it, and would be thankful for any better suggestions. I hope this information may help people moving their state management out.

[Olical]

That's a pretty neat solution actually. It's the only way to do it I'd
imagine, this is what I'm trying to get across though. D3 is designed to
mutate an existing DOM structure, React is designed to reconcile DOM based
on a fresh tree of data upon each render. They work fundamentally
differently, this helps bridge the gap, but it won't make every single D3
feature work out of the box. It just seems like people are expecting it to
support everything seamlessly, in which case you may as well just use the
original style of embedding D3 etc. This is a middle ground.

Thanks for the comment though, that's a good thing to document really. If
you wanted to add it to the documentation or write it up somewhere and add
it to the readme feel free. No problem if not.
On 11 Nov 2015 22:47, "Martin Schinz" notifications@github.com wrote:

One thing I had real trouble with figuring out, was how to get an initial
measurement for a width for my dom element. This has nothing to do with
this library, but might be a useful tidbit for the documentation. I solved
it by using the parent's componentDidMount() with a ref to the container
node , and then triggered another render via this.setState(). I couldn't
find a more elegant way to solve it, but this may help people moving their
state management out.

—
Reply to this email directly or view it on GitHub
#30 (comment).