CSV editor

[timwis]

Adds a spreadsheet editor for CSV files using handsontable and PapaParse.

It's fully functional but I'd still call it a work in progress as I hope to solicit your feedback before recommending a merge. The following items remain:

• CommonJS dependency (Requiring handsontable is tricky because it's written in ES2015. Right now it's pulling in the built, minified file)
• Get clarity: I wasn't sure the best way to pull in handsontable's CSS - it seems like the only CSS in prose is in styles.css - are there no CSS dependencies?
• It should work for TSV files too (PapaParse supports it)
• Auto-height (I don't like that it has a fixed height of 600px, but in order to get smooth overflow scrolling, handsontable needs a default height. We can compute this based on available vertical real estate, I imagine.)
• Undo/redo support
• Add/Delete row/column support
• Column resize support
• Compare mobile support to standard prose mobile support and ensure it aligns
• Bug: Unsaved changes don't show up as 'dirty' when you return to the file
• Add ability to switch to plain file editor
• Get travis to pass
• Add unit tests

I welcome your thoughts and feedback!

EDIT: Looks like legacy node builds in travis are failing because handsontable is installed via github (Unsupported URL Type: github:handsontable/handsontable). I'm sure there's an easy fix.

[phillipadsmith]

Hey there @timwis --

I'm just shaking off a holiday haze.

At first glance, this looks like an impressive potential addition to Prose.

And yet, there are probably a couple of issues that need attention before it can be considered:

1. Are you going to address the issue in package.json that's causing the test failure?
2. Are you thinking about adding some tests for these features?

I'll aim to get this installed locally and have a closer look this week, unless @dereklieu beats me to it (though, I'm guessing he's shorter on time than I am).

Phillip.

[timwis]

Thanks @phillipadsmith! I'm definitely up for both those items along with the other points I made above. I just wanted to get your high-level feedback before diving any deeper to make sure I'm approaching it the right way and that this would be a valued feature.

[timwis]

FYI, travis passing and TSV support added. Still a few other items above, but progress :)

[timwis]

At this point I'd like to get your thoughts on using handsontable from a CDN rather than compiling it into the prose.js build. It's pretty difficult to get it to build properly since it's written in ES2015 with their own compiler. They offer a compiled-to-ES5 version that can work standalone, but browserify tries to replace all the require()s with its own require logic, and I believe that's what's throwing errors.

[dereklieu]

@timwis that would be easier I agree, but since this will come up as more and more libraries adopt ES2015, I would rather add something like a babel transform to package.json. Would that solve this issue?

[timwis]

@dereklieu it may...we'd have to configure babelify to only transpile this module. Though I tried exactly this with webpack a couple weeks ago and it didn't work because the handsontable team used some other, non-babel transpiler and the local dependencies weren't pulled in (I assume when they rewrote in ES2015, babel wasn't as trendy). I'll give it a shot though.

[timwis]

Also, mobile support is weak for handsontable -- it seems like it works but gets cut off after a certain number of rows. Is that a deal breaker?

[dereklieu]

Thanks for flagging mobile support. I'm a bit conflicted here between maintaining mobile support for the default Safari that comes on lots of iOS devices. Not sure from their docs what Android support looks like.

Thinking about user expectations, I would see this as an extension of core functionality, so if we left that functionality intact while providing simple fallback for unsupported devices, I think I'd be ok with that.

I was hoping to find some info on the handsontable repo about when they might support commonjs requires, but then I ran into your ticket. From your experience, is it reasonable to expect their maintainers to act on that ticket? It seems they have a lot of open pull requests.

If it's between transpiling only one file and just including another <script> tag, I think the latter is less crufty (and we're already using browserify-shim).

[timwis]

@dereklieu I noticed all the PRs today too..it doesn't look like they're very active in getting back to folks. It looks like they have a big release coming out on January 11th though: Handsontable pro (per the top bar of their website). Not sure what that will mean for the free version, hopefully good things. Honestly though the main reason I've been using it is that it's so feature rich, only does the one thing (UI) and does it really well, and it appears to have been recently rewritten considering it's in ES2015.

EDIT: Also, when you get a chance, let me know what you think about the styles. (1) should I put my few custom css in any particular place in styles.css? (2) are CSS dependencies concatenated anywhere or is my <link> tag in index.html okay?

EDIT2: Added tests and now realizing that I can't test anything involving Handsontable from node because we're pulling that in via CDN in index.html! (as a result, tests fail, but once the dependency is resolved they should pass and suffice)

EDIT3: I've got it bundling handsontable without parsing it, so I think we're in business. No need for the CDN. Which makes my question above regarding the CSS more relevant.

[timwis]

Okay guys, just got unit tests working. As I mentioned in the edits above, doing so involved figuring out how to bundle in Handsontable.js (instead of via <script> tag/CDN). Let me know your thoughts on the questions above when you get a chance.

Update: Added ability to toggle back to the markdown editor, which persists between sessions via cookie

[dereklieu]

Hey @timwis sorry for the delay, I'm hoping to have some more time to look at this over the coming days. As far as the CSS goes, you're right in that the repo contains only a parsed file. I'm not sure where the development assets are, but I think it would make sense to include a CSS task in the gulpfile to pull in 3rd-party styles, something akin to a vendor.css.

Can you tell me more about the auto-height issue you mention above?

[edit] to say thanks for figuring out the include and tests - this is coming along really nicely.

[timwis]

Hi @dereklieu, thanks for the reply. Happy to add a gulp task for vendor.css. Is there any other vendor CSS used in the project that's currently in styles.css that should be pulled out while I'm at it?

Regarding the automatic height issue, basically handsontable needs a height style to initialize in this particular way (with horizontal scrolling enabled, which is a key feature for CSV files with a lot of columns). It's currently set to 600px I believe, which looks fine on...well, my laptop. If there are more rows than fit, the handsontable <div> will also scroll vertically, so I think ideally we'd compute the available vertical screen real estate and set the height to that, unless there's a way to do it with position: absolute.

[timwis]

Hey guys, the editor now sets its height based on the available vertical space. There's technically a little extra height but it's still based on the window size and should feel natural from a usability perspective. Any thoughts on merging this?

[dereklieu]

@timwis 👍 sorry for my lateness here. I still haven't had a lot of time to really sit down and review this in full yet, but I'm snowed in all weekend so expect to have time. You'll hear back from me soon.

[timwis]

woohoo! no worries, looking forward to it

[dereklieu]

@timwis code looks great. Thanks for including tests.

One concern I have is that someone might edit a csv with jekyll metadata editing enabled for that directory or globally. Even if you didn't touch the metadata editor, it would still insert default values on save and break that csv for probably every other spreadsheet program.

One option might be to disable the metadata editor if file.useCSVEditor === true. This feels safe to me, as I don't see why anyone would need jekyll metadata for csv files.

From my perspective, that's the only thing we'd need to merge this.

[timwis]

@dereklieu Good catch. I'm on it! Don't go anywhere :P

[timwis]

Having a tough time replicating the issue. I'll keep at it.

[dereklieu]

@timwis if you head to http://localhost:3000/#dereklieu/starter/edit/prose-testing/csv/iowa.csv (while serving from localhost:3000), you can see it. Just make a change to the file and try saving.

[timwis]

Thanks @dereklieu - I was able to reproduce it. I agree with the approach you suggested and have implemented it on this PR.

[dereklieu]

Confirmed, thanks @timwis!

[timwis]

Woohoo! Is there a different process for pushing it live?

[dereklieu]

Yes, deploying to gh-pages. Have a few things to finish here and will get to that early this afternoon.

[dereklieu]

@timwis deployed.

[timwis]

That's great news. Thanks @dereklieu!

[patcon]

Hey @timwis 👋 Long time no see!

Quick question: How did you get the table header rendering properly in your original screenshot?

I notice that it's not even working for your demo repo that you screenshotted from, but thought I'd ask anyhow :)
https://prose.io/#timwis/csv-test/edit/master/sample.csv

[timwis]

Hi @patcon! Sorry for my delay, and nice to hear from you. To be honest, this was so long ago that I don't remember, but according to handsontable's docs, it looks like you can enable that by passing an array to colHeaders in file.js instead of its current value, true. I would have expected an option where you could treat the first row as the column headers, but I don't see it in their docs.

I probably didn't enable that by default because not all CSVs have headers as the first row, and it would be broken in those cases, but not broken in the reverse. I reckon a metadata setting could be a nice way around it.