Is it necessary to provide a React version for this library?

[BigFatDog]

Hello guys, I'm wondering if it is necessary to build a React version of this library.

Currently I'm using this library in React apps with React hooks. I feel it would be better if there were a React version, but only slightly better because I cannot see too much improvements there. I haven't found reason that firmly demands a React version so far.

What do you think? Yours Yun Xing

[joshhjacobson]

Hi there,

I've never used React so I don't have much of an opinion on this. However, it would be nice if this library were easily compatible with the Angular-Slickgrid library -- it would be a powerful combination! I don't know the details of how React and Angular play together, but that may be worth taking into consideration.

Best, Josh

[jvmanke]

Hey @BigFatDog maybe not build a separate library but maybe add some examples using it with react? I personally am strugling to get it working properly. Do you have a snippet I could look?

[mateusrcm]

Yes, Please @BigFatDog

[jonasarielberner]

@BigFatDog I am having trouble to work with parcoords-es in React! Please Help!

[gabriel-zanghelini]

@BigFatDog Yes, it will be useful for me!

[BigFatDog]

Would you please post your error messages here so that I can give it a try?

I just tested parcoords-es in a react app and it works. Environment and sample code are listed below: dependencies:

"react": "16.8.4",
"parcoord-es": "^2.2.10",

devDependencies:

    "@babel/cli": "7.2.3",
    "@babel/core": "7.3.4",
    "@babel/node": "^7.2.2",
    "webpack": "^4.29.6",

Sample code:

import React, { useEffect, useRef } from 'react';
import Parcoords from 'parcoord-es';
import 'parcoord-es/dist/parcoords.css';

const test = props => {
    const chartRef = useRef(null);
    useEffect(() => {
      if (chartRef !== null) {
       // use default config;
       const chart = Parcoords()('#chart-id')
        .data([
          [0,-0,0,0,0,1],
          [1,-1,1,2,1,1],
          [2,-2,4,4,0.5,1],
          [3,-3,9,6,0.33,1],
          [4,-4,16,8,0.25,1]
        ])
        .render()
        .createAxes();
      }
    }, [chartRef]);

    return(
<div ref={chartRef} id={'chart-id'} style={{width: 600, height: 600}} className={'parcoords'}/>
);
}

[jvmanke]

I was actually not getting an error message, just the graph looked squished as if the height was 0. Your example made me realise I have to set the width/height on the container and it works, I had created a useD3 hook that abstracted that from me and I didn't realize.

Also, I think you should select by the ref you created right? Otherwise it is kinda unnecessary, however it is the recommended way to access the DOM within react.

Something like:

Parcoords()(chartRef.current)

Also I realize that the css is tied to the class parcoords, in my opinion the selector should be the only connection explicitly made to the component/element, maybe the class could be added to the container by default, maybe have an option to override it.

That would make the selection the definite connection to the chart and avoid having a 'magic' class name that has to be included in the component.

Thanks for the response, and a fully fledged component API still very welcome BTW!

EDIT: Forgot to mention, I would love to help you with the React version, I don't yet have enough familiarity with the library to exactly say which should be the features or props relevant to such component but if you have any ideas I can try to put something together

[BigFatDog]

Something like: Parcoords()(chartRef.current)

Yes. I just tested. I used id because I was not totally sure if the current parcoords would work with chartRef.current. Should try ref way first.

That would make the selection the definite connection to the chart and avoid having a 'magic' class name that has to be included in the component.

I get your point. I need to have a closer look to make sure if it is possible to do this without providing a whole new react version of parccords-es

Thanks for the response, and a fully fledged component API still very welcome BTW!

It is about development time and library's quality: 1) A react version may need many iterations before it has the same quality as the current version does. 2) I know it is always good to have react version of a library when you work with React, but I do need a decisive point that strongly indicates the react version of parcoords-es is essential. That's the main reason why I open this issue: my own knowledge is limited, others may get a key point that I have left behind.

EDIT: Forgot to mention, I would love to help you with the React version

Appreciate that! Honestly I tend to keep this library as it is so far. However, I'm open to small improvements that can help parcoords-es work with react better without changing its behaviors in other environments.

BTW, if I work on a data visualization library with React (irrelevant to parcoords-es), I'd rather create a whole new one.

[BigFatDog]

Hey @BigFatDog maybe not build a separate library but maybe add some examples using it with react? I personally am strugling to get it working properly. Do you have a snippet I could look?

This is practical. I'll do this.

[jvmanke]

Appreciate that! Honestly I tend to keep this library as it is so far. However, I'm open to small improvements that can help parcoords-es work with react better without changing its behaviors in other environments.

BTW, if I work on a data visualization library with React (irrelevant to parcoords-es), I'd rather create a whole new one.

Oh yeah, I wouldn't think mixing a react version within this repo would be the way to go, more like a separate lib that is a wrapper to this one serving as a abstraction to the whole d3 backend, which many people (including myself) that work with React are not familiar with.