Awesome job so far! This is obviously a monumental undertaking, especially since the quality of spreadsheet software seems mostly correlated with volume of features. This project looks like a great start, with an extensible architecture that will allow the project to eventually attain that "volume of features." I think my favorite line of code is this one, from package.json:<p>> "dependencies": {}<p>:)
This is amazing and fast. I'm complaining about it actually being easily broken only because I really wished this worked well, so I could build on it. It crashed for me on literally the very first thing I tried. I opened up the demo page, typed in 4 numbers in a column (in positions a5,a6,a7,a8), then typed "=sum(a5:a8)" in position a9, hit enter, and the demo crashed (with canvas all messed up). There's a traceback in the console log that starts "Uncaught TypeError: Cannot read property 'render' of undefined at cell.js:146". I'm using Chrome 71. I refreshed and tried the same test and it crashed again. There is a test suite (<a href="https://github.com/myliang/x-spreadsheet/tree/master/test" rel="nofollow">https://github.com/myliang/x-spreadsheet/tree/master/test</a>) but the files have mostly not been touched in four months. In any case, awesome work - please make it even better!
AFAIK (and in evidence in this case) you can't use the normal "find in page" (control-f) when using canvas. Consistency in functions like find is one of the greatest things about the browser, this approach removes it. Probably (!) an implementation will add its own find, which may be better or worse, but as browsers are best thought of as universal information vehicles, it won't automatically fit into accessibility and extension schemes.
I think a description of why canvas was used would be nice in the README. My (probably naive) view is that browsers are pretty good at table-ish layouts so it’d be great to know why canvas was chosen.
This looks really good - the speed of rendering of the default sheet was surprising and pleasant.<p>Is there a reason you switched from the earlier version in TypeScript[1] to this version in JavaScript?<p>[1] <a href="https://github.com/myliang/xspreadsheet" rel="nofollow">https://github.com/myliang/xspreadsheet</a>
The speed of the rendering is amazing compared especially to e.g. google sheets. I just informally timed both and gsheets was rendered and editable in 4 seconds whereas this took 0.2 seconds.<p>However nearly every native UI interaction seems kinda broken. Even entering a value on Firefox doesn't work well. The first letter typed is entered into the cell but then every subsequent letter triggers firefox's fine-in-page (which also doesn't work as others have pointed out). Similarly copy/paste doesn't work, and the context menu (right-click) closes immediately. Maybe it works better in Chrome.<p>I wonder if there's a case to be made for a hybrid rendering/ui approach here. Rendering could be handled by canvas but native elements swapped in when actual text-editing is invoked?<p>Cool little demo in any case. I liked some of the simple but effective spreadsheet evaluation code.
Nice! Would be interested in how this compares to e.g. handsontable[1]. What do you think of audreyt's ethercalc[2] myliang?<p>[1] <a href="https://github.com/handsontable/handsontable" rel="nofollow">https://github.com/handsontable/handsontable</a><p>[2] <a href="https://github.com/audreyt/ethercalc" rel="nofollow">https://github.com/audreyt/ethercalc</a>
This strongly goes against the best practices for Canvas:<p><a href="https://www.w3.org/TR/2dcontext/#best-practices" rel="nofollow">https://www.w3.org/TR/2dcontext/#best-practices</a>
It's neat and fast. I do think that you should consider implementing a few more common excel shortcuts, to make it really seamless to an advanced excel user. For instance:<p>- CTRL ARROWS: to move on the grid to the next populated cell<p>- F2: edit the first cell of the selected range<p>- CTR ENTER: applies the content of the first cell of the selected range to the whole range (after you pressed F2 to edit it)<p>- when edit mode, pressing down arrow should leave edit mode and move to the cell below<p>- CTR *: select area<p>- SHIFT SPACE / CTR SPACE: to select a row / column
I've theorized for a while about what it would look like to try and build a generic, app-focused layout engine on Canvas. The DOM gives you lots of things for free and has a long history of backward-compatibility, but both of those things come with huge costs in terms of performance and (to a degree) complexity. The fact that the DOM a) is stateful and b) was originally designed for documents, not apps, causes lots of challenges when what you want to build are apps. The entire reason React exists is to try and force the stateful DOM back into a functional paradigm.<p>I'd be very curious to learn how generic this project's layout system is.
Here's a canvas datagrid that I've come across in case anyone is interested in the genre:<p><a href="https://tonygermaneri.github.io/canvas-datagrid/" rel="nofollow">https://tonygermaneri.github.io/canvas-datagrid/</a>
This is amazing! I'm doing a deep dive into the code now to see how the extensibility is done.<p>Some folks here might be interested in Stencila Sheets too (<a href="https://stenci.la/blog/2017-08-features-stencila-sheets/" rel="nofollow">https://stenci.la/blog/2017-08-features-stencila-sheets/</a>, <a href="https://stenci.la/blog/introducing-sheets/" rel="nofollow">https://stenci.la/blog/introducing-sheets/</a>), <a href="https://github.com/stencila/stencila/tree/develop/src/sheet" rel="nofollow">https://github.com/stencila/stencila/tree/develop/src/sheet</a>. It's a web-based spreadsheets where cells can execute other programming languages, such as R or Python.<p>Disclaimer: I know the authors. Even so, it's very interesting tech.
This is really interesting!
I've hoped of a scenegraph based web in the past, all rendered in a canvas (indexing can be done by serving a simplified html representation by checking the user agent).
I think the most challenging part is text rendering, but some people have done some work in this area (<a href="https://github.com/astiopin/webgl_fonts" rel="nofollow">https://github.com/astiopin/webgl_fonts</a>).
Also, we may need some sort of API to trigger keyboard showing on mobile device.
Anyway, congratulations!
Nice work! The UI is really good. In my one of the projects, I was looking for excel kind of functionality - and would like to give it a try. But the biggest value IMO excel offers is ability to define formulas. Is there any plans of adding that functionality?
Looks very nice. Couple of nitpicks:
1. Tooltips go into a flicker loop when you hover over the tooltip arrow ( the triangle hanging off of the tooltip box ).
2. Dropdowns should close when you click a second time on the dropdown toggle.
Reminds me a bit of <a href="https://github.com/SheetJS/js-xlsx" rel="nofollow">https://github.com/SheetJS/js-xlsx</a>
I really like this and I can see the potential, but I certainly miss being able to type directly into the cell as opposed to double-clicking on it first. F2 should also enable editing and toggle between Edit and Enter modes.<p>It's hard to spend more than a few seconds on the demo when my very first interaction with it hits a major roadblock like that.
If you're looking for a simple, light and highly customizable Spreadsheet for the web checkout React Spreadsheet (<a href="https://www.npmjs.com/package/react-spreadsheet" rel="nofollow">https://www.npmjs.com/package/react-spreadsheet</a>).
scrolling is weird. looks like the canvas is bigger than the window. So when scrolling both the native document/window scrolling is happing and the custom build scrolling of the canvas itself.
Let's render iframes in spreadsheet cells, and only display a selected element of the page in the iframe. We'll build interfaces that help us deal with information accross webpages and websites in no time!
Well, <canvas> is not the best tool for doing such things.<p><canvas> by its definition is essentially an <img> with its content (pixmap) modifiable from script side.<p>Better solution would be for browser to support immediate mode drawing. Like in my sciter (<a href="https://sciter.com" rel="nofollow">https://sciter.com</a>) where you can define immediate mode painting methods (Element.paintBackground|Content|Foreground|Outline):<p><pre><code> var elGrid = …
elGrid.paintBackground = function(gfx) {
for(var r in ROWS )
gfx.hline(0,r * cellh, width);
for(var c in COLS )
gfx.vline(c * cellw, 0, height);
}
</code></pre>
That paintBackground callback is invoked as a part of WM_PAINT window handler and with the same Graphics that window uses for rendering the DOM - no intermediate bitmaps.<p>Such model requires slightly different Graphics architecture than what is used by browsers. At least Path, Brush and TextLayout classes need to be added in order all that to work effectively.<p>Or to redefine all that on top of WebGL but that will be weird - browsers already have all 2D primitives (Direct2D, Skia, Cairo) implemented natively.