search

altair-viz / jupyterlab_voyager

JupyterLab extension visualize data with Voyager
BSD 3-Clause "New" or "Revised" License
298 stars 35 forks source link

Cannot open a CSV from "Open with ..." menu #68

Open suvayu opened 5 years ago

suvayu commented 5 years ago

When I open a CSV from the "Open with ..." menu, I get the error String(...).match(...) is null in a popup from Firefox, with a "OK" button. Clicking the button opens voyager, but none of the CSV columns are detected, and I can't visualise anything.
jupyterlab-voyager-bug

playermanny2 commented 5 years ago

@suvayu

Can you post more information about your issue, as there's some known potential issues with some .csv files, but most of the .csvs i have been trying do open properly

Firstly, can you try to open up the data.csv in test/data included within this repository

1.Steps to reproduce(including the dateset you're trying) 2.Any relevant logs from jupyterlab 3.Any relevant logs from JavaScript console

suvayu commented 5 years ago

@playermanny2 I digged a bit deeper, it turns out this error happens when there is an empty column name in the csv. In my case I had exported the csv from pandas with DataFrame.to_csv(..). By default (if you specify only the file name and nothing else, then header=True, index=True, index_label=None), the column name for index is empty. When I manually edit and add the index column name, the csv opens without issues.

Since this is rather common, maybe Voyager should assume a place holder like: column_n, if the column name is empty?

playermanny2 commented 5 years ago

@suvayu

Thanks for digging into this deeper --will have to take a look at this a bit deeper to see if this is a problem with voyager itself not being able to handle empty column names or our extension.

The fallback seems like it could be a viable route

playermanny2 commented 5 years ago

@suvayu per a quick test on http://vega.github.io/voyager/

This is the behavior directly from Voyager. I'm not sure if they chose not to create fallbacks for a valid reason -- usually it's best practice to not manipulate data received in anyway.

@saulshanabrook what do you think about adding in a fallback for handling empty columns in data?