Uncaught TypeError in development build

[RusinovAnton]

Hi, I'm using:

"react": "^15.3.0",
"react-chartjs-2": "^1.2.4",
"webpack": "^1.13.1"

and when I try use chart with my wepack dev config like this:

import React from 'react';
import { connect } from 'react-redux';
import { Line } from 'react-chartjs-2';
...
render() {
  return (
      <div>
        { data ? <Line data={this.props.data} options={LINE_CHART_OPTIONS} /> : <Loader/> }
      </div>
  );
}

I get this error everytime

core.controller.js:496 Uncaught TypeError: Can't add property _meta, object is not extensible

But things work just fine when I build app with my production config, where webpack.UglifyJsPlugin added:

var uglifyPlugin =  new webpack.optimize.UglifyJsPlugin({
  compress: {
    sequences: true,
    dead_code: true,
    conditionals: true,
    booleans: true,
    unused: true,
    if_return: true,
    join_vars: true,
    drop_console: true
  },
  mangle: {
    except: ['$super', '$', 'exports', 'require']
  },
  output: {
    comments: false
  }
});

Please let me know if any additional info needed.

[RusinovAnton]

Ok, so I figured out that when I have an empty object in LINE_CHART_OPTIONS only then this error occurs.

[gor181]

Hey @RusinovAnton ,

Thanks for reporting, checking it out

[gor181]

Hey @RusinovAnton ,

Does the same issue appears when you use chart.js directly and passing {} to options?

[RusinovAnton]

@gor181, so at this point I figure out that problem is that I used seamless-immutable to wrap up my data that I pass into component.
In my case I can avoid using it at all so my problem is solved. But I think it would be great to fix this issue if its possible because using immutable data with react-redux is pretty common nowadays.
Sorry for any inconvenience with misleading info.
Thanks for your time and great library at all.

[gor181]

Hey @RusinovAnton ,

I agree that immutable data is really common, however I think that the data should be normalized prior passed to react-chartjs-2 and chart.js?

[RusinovAnton]

@gor181, absolutely. This is not in scope of this librarys' tasks to normalize incoming data. So I suppose we close this issue

[gor181]

Awesome, thanks anyway, this will be useful for anyone using the same setup as you. 👍