
Show HN: React-data sheet, Excel-like spreadsheet component - nadimisl
https://nadbm.github.io/react-datasheet/
======
csours
Anytime I see something that looks like Excel on the web, I cringe.

Unless you are Microsoft or Google and you are putting spreadsheets on a
website (SoW), you are almost certainly doing something wrong.

\---

 _Case 1:_ A co-worker (or yourself) previously wrote an excel-based app and
now it's time to put it on the web for wider distribution. You implement the
app with a custom gridview/spreadsheet.

 _Error in Case 1:_ The UI was copied, but what is almost always needed is an
input wizard with validations and workflow along with a reporting backend.

\---

 _Case 2:_ You have a database that you need to share in a human readable
format.

 _Error in Case 2:_ Implement export functionality instead, you will never be
able to implement all the features of Excel, and at some point someone will
need that feature.

\---

 _Case 3:_ You have a very small and well defined case that actually calls for
SoW!

 _Error in Case 3:_ Your very small SoW app will grow and grow and strangle
you.

\---

 _Case 4:_ You want to challenge the stranglehold of Google Sheets and MS
Office 365.

 _Error in Case 4:_ There is no error here, only madness.

~~~
david927
_Error in Case 4: There is no error here, only madness._

Then give me madness. The problem is that spreadsheets are one of the most
natural interfaces for data that we humans have, and even with Microsoft and
Google's efforts included, current spreadsheets on a website (SoW) suck.

So let's say the y-axis is importance of function and the x-axis is compelling
implementation --> voila! Right there, plotted on the graph you can see that
this is something that needs to be worked on.

I understand your reasoning: you've created a spreadsheet-styled labeled grid
in no time and you're pumping your fist, only to find out later that it this
is way less than 1% of the effort you will eventually have to dole out to make
a basic, respectable spreadsheet. The landscape is littered with 1% efforts
that look good until you start working with it.

My point, though, is that this area is too important to not try harder, to not
see more true attempts.

~~~
csours
> spreadsheets are one of the most natural interfaces for data that we humans
> have

Spreadsheets are natural for data, but not for humans. Spreadsheets are
excellent for prototyping and data munging; and spreadsheet prototype apps are
even fine for personal or small team use.

When you get medium team size or multiple small teams that spreadsheets break
down.

Part of that breakdown is in distribution - which SoW solves.

But another part of that breakdown is in not understanding the implicit rules
of the spreadsheet app - another team or person will put some garbage in a
cell and break the 'app'.

~~~
repsilat
Spreadsheets are the most intuitive programming environment known to man.
Every time you reach for Excel to mung your data, that's opening a repl. The
only problem is that Google and Microsoft don't care enough to make them
powerful enough to do general purpose computation with, fast enough to build
large systems with, versionable enough to enable large teams to use them.

~~~
csours
> Spreadsheets are the most intuitive programming environment known to man.
> Every time you reach for Excel to mung your data, that's opening a repl.

I absolutely agree - REPLs are excellent for prototyping and exploring data
and ideas, and spreadsheets are excellent in that role.

Allow me to ask you this then: when was the last time you shipped prototype
code? Unless you live dangerously, you don't ship prototype code!

> The only problem is that Google and Microsoft don't care enough to make them
> powerful enough to do general purpose computation with, fast enough to build
> large systems with, versionable enough to enable large teams to use them.

I would counter that a more important problem is "productionalizing"
spreadsheets - all of the fiddly things you do to ensure inputs are in the
right format, etc, etc, along with testing, securing, and deploying code.

~~~
csharpminor
You might check out Airtable. They do a good job of this.

------
misiti3780
I am working with two separate clients that need excel spreadsheet
functionality in a browser. I evaluated all of the existing open source
projects (this wasnt available at the time) and ended up going with fix-data-
table-2 (fork of facebooks fix-data-table).

fix-data-table is performant and easily extendable. I was able to create an
editable grid similar to googlesheets in a months worth of work. working on
open sourcing it soon.

~~~
tlrobinson
React Virtualized is also great:
[http://www.reactvirtualized.com](http://www.reactvirtualized.com)

We (Metabase) switched from FixedDataTable to React Virtualized and are
happier with it. The only major issue with it is doesn't have fixed
columns/rows built in, but it's pretty easy to compose a couple Grids with
ScrollSync to get that behavior ([https://bvaughn.github.io/react-
virtualized/#/components/Scr...](https://bvaughn.github.io/react-
virtualized/#/components/ScrollSync))

FixedDataTable has performance issues with a larger number of columns because
it doesn't "virtualize" columns ([https://github.com/facebook/fixed-data-
table/issues/49](https://github.com/facebook/fixed-data-table/issues/49)). The
DOM it generates is also _much_ heavier (several elements for every cell vs. 1
with React Virtualized)

~~~
kamranasif
Maintainer of FDT2 here.

One of the reasons we decided to maintain this library is that it does
virtualize both columns and rows. We use it at Schrodinger for our enterprise
platform and have demo'd support of billions of rows. This is possible because
we don't use a wrapper DOM element to handle scrolling. Right now we are
migrating all the state to Redux for better maintainability and performance
and hope to make extending and optimizing the library more user friendly.

misiti3780 would you be interested in collaborating with us to help us capture
your improvements as well?

~~~
TheAceOfHearts
I've gotta admit I'm weary of the usefulness of a table with billions of rows.
Doesn't that just drown the user with noise? Have you explored alternative
means of presenting the data? Billions of anything sounds like too much
information for any human to make sense of and process. Could you explain a
bit about your use-case?

~~~
kamranasif
Our application is similar to excel/google spreadsheets. We don't expect the
user to scroll through all that data, but we give tools to do sorting,
filtering, plotting, etc. over that data.

------
acemarke
As a general pointer, there's a good categorized list of React components at
[https://github.com/brillout/awesome-react-
components](https://github.com/brillout/awesome-react-components) , including
a number of other table and grid components. Also,
[https://js.coach](https://js.coach) is a useful searchable auto-generated
catalog of React-related components and libraries.

For anyone interested in learning React, I keep a big list of links to high-
quality tutorials and articles on React, Redux, and related topics, at
[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

------
sandGorgon
If you can productize this, then you can potentially build a business around
this.

The most feature filled spreadsheet component today is Handsontable. My
company pays for the enterprise version of it...And we wish there was
something better.

~~~
degenerate
Link for others:
[https://handsontable.com/examples.html](https://handsontable.com/examples.html)

It's too expensive IMO. But if you are not using it commercially, it's on
Github.

~~~
sandGorgon
no - i dont believe its too expensive. the devs are fairly responsive.

The thing is, it carries too much baggage. It took them many months to even
put it on npm. Adding features takes a lot of effort.

Its 149$ for a year - its not at all bad and I love supporting them.

But there's space to innovate - look at Airtable. I would love to have a
component that looks like Airtable frontend.

------
uptown
This looks really great, and I've got an immediate use for something like
this. I've been using ag-grid for presentation of grid-based data, but this
looks ideal for more-interactive views. I look forward to putting it through
its paces.

Somewhat off-topic, but for those working in React, have you built large
systems using Redux? I'm fairly early in what is likely to ultimately be a
large-ish application, and while I've got Redux working, I feel working with
it is definitely adding cognitive load to each feature I implement. Just
wondering whether it's worth the effort and would appreciate feedback from
those who may have more experience weighing the pros and cons of using Redux
with their application.

~~~
lpa22
I have made several relatively large systems using Redux, and it has become a
necessity in order to handle complexity of new features. Overcoming the
initial cognitive load takes a week or two, but as your system grows, your
productivity and code organization is greatly improved. I also recommend
Immutable for handling the state object and reselect for computing your
container state properties. Those technologies together are a pleasure to
develop with.

~~~
rattray
How does [https://github.com/kolodny/immutability-
helper](https://github.com/kolodny/immutability-helper) compare to Immutable
in your experience? The latter seems potentially more performant and lighter-
weight; curious what its disadvantages might be (the syntax?)

~~~
acemarke
I personally recommend against using Immutable.js, for a number of reasons
(which I wrote as a Reddit comment a while ago [0] ). There's some additional
info on Immutable.js-related perf in my links list [1]

FYI, there's also a bunch of other immutable update utility libs besides
immutability-helper. I have a list of them in my Redux addons catalog [2].

[0]
[https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra...](https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3)

[1] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/react-performance.md#immutable-data)

[2] [https://github.com/markerikson/redux-ecosystem-
links/blob/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/immutable-data.md#immutable-update-utilities)

~~~
rattray
Interesting, thanks for sharing. I took a look at your list of links recently,
actually – it was helpful.

I'm considering syntax-level support for `immutability-helper`, which seems
like the best all-around solution aside from its syntax. This is for a JS
Dialect I'm building called LightScript[0].

Would look something like:

    
    
        store.people[0].friends[0].name~~set("Alice")
    

which would compile to:

    
    
        update(store, { 
          people: { 
            [0]: {
              friends: {
                [0]: {
                  name: { $set: "Alice" }
                }
              }
            }
          }
        })
    

Would love thoughts/feedback (here or on the project Gitter[1])

[0] [http://lightscript.org](http://lightscript.org) [1]
[https://gitter.im/lightscript/Lobby](https://gitter.im/lightscript/Lobby)

~~~
helb
One thing i like about immutability-helper is their mongo-style syntax. Yeah,
MongoDB might kinda suck for multiple reasons, but the query syntax is quite
nice IMO.

------
chrishere
Chris Spilka, CEO at Handsontable here.

It's great to see that Nadim started to work on this spreadsheet for React.
It's for sure an ambitious project and will require a lot of community support
and love;) We at Handsontable benefit from the open source since 2012 and most
of ~3400 closed issues to date were reported by users who actually care about
our product and/or make a good use of it.

Here are some thoughts which anyone who attempt to create an online
spreadsheet from scratch should take into account:

\- Separate data logic from the view. Sounds like a cliché but actually it
will save you plenty of time when you start adding more and more features to
the pile. \- Get to know how people want to use your app. Focus on their
workflow not on your (false) assumptions. \- Don't mix up features typical for
grids with those present in spreadsheets. Focus on what's important, not on
Excel's blows and whistles. Grouping is OK. Parent-child structure not
necessarily. \- Don't underestimate the effort connected with building such
component. Ask the community for help. Give them a great product in return. \-
At some point your "data engine" will work just like a small, specialised
database (CRUD + search/filter/sort). \- Think of how you will scale your
solution both horizontally (new technologies) and vertically (new features).
Our customers have completely remote requirements in terms of using
Handsontable with specific databases, back-ends, JS/CSS frameworks, devices
(not to mention different formats of numbers, languages etc.)

Offtopic: In the contemporary history we have seen a lot of attempts to make
an ultimate online spreadsheet. Most of those projects are now long gone (see
[https://www.lifewire.com/best-free-online-
spreadsheets-34862...](https://www.lifewire.com/best-free-online-
spreadsheets-3486263)). That was before Google acquired 2Web Technologies and
created its own, free solution upon it. The trend is to create spreadsheet-
based projects for certain use cases just like Quip, Smartsheet, Airtable and
more.

Anyway, fingers crossed for your project. I will be happy to share with you
our best practices and thoughts from our work with Handsontable (write @ chris
[at] handsoncode.net).

Cheers, Chris

------
euroclydon
Looks beautiful!!

But, I can just imagine running this one by the patent attorneys as an open
source library to include in our product.

~~~
hive_mind
Why the downvotes? This person is describing a real problem with dealing with
staff patent attorneys. This is real life.

~~~
clishem
If you think it's a constructive comment I'll be writing a bot that scans
pages posts on HN, looks on the page for a GitHub link and complains about the
license used. Doesn't matter if it's GPL, MIT, Apache, I'll just write some
generic comment complaining about each license.

~~~
zenlikethat
Since the license of this library is MIT and the poster mentions patent
attorneys I'd guess they aren't worried about licensing.

They're worried about getting sued by Microsoft, Google, etc. for patent
infringement.

~~~
mason55
Host on Azure and use Microsofts patents against the when they sue you

------
georgewfraser
I have spent way too much time building grid components at my company, and
I've found that if you have (1) a lot of data, (2) a dense grid, and (3) a
grid that occupies most of the screen, THEN the only way to get 30+fps is to
use canvas and do all the layout and drawing logic yourself.

~~~
toomim
Or you can do what google sheets does: only draw N cells at any time, and just
change their contents depending on where you are scrolled to.

~~~
georgewfraser
Google sheets uses canvas. The strategy you describe is orthoganal to canvas
versus DOM.

~~~
ic4l
I had to verify this... I cant believe it, they doing all the rendering logic
for all the cells in canvas. They are not rendering simple cells either,
sheets has may features :O.

Testing would be the easy part, in some cases it would be easier than DOM
because you can do image diffs... The harder part is BUILDING IT.

~~~
chrishere
They applied some kind of mixed model in which the entire effort connected
with rendering the body of the grid (cells) is being drawn in canvas and the
rest of it, including headers, selection and editors, are rendered in a
regular way. There is no doubt that Google Sheets keeps almost all of its
logic on the back-end side.

------
osullivj
Very slick looking! Currently I'm using Angular 1.x with editablegrid to
enable browser edits on server hosted spreadsheets [1]. The UX quality of this
makes me think I should go for a rewrite in React.

[1] spreadserve.com

------
hultner
Any data on how this performs on large datasets? I've previously found that
most web based data grids get extremely slow on larger data sets in BI
applications (100k+ rows)

~~~
nadimisl
Definitely not meant for large datasets. I've tried it with about 100rows and
pagination. I would work with react-virtualized for datasets that large

~~~
shaneos
If that is the case, then this would have avoided the real problem that needs
solving here. Throwing together some rendering and keyboard handling is not
game changing. Getting good performance is the hard problem that needs
solving.

Perhaps a future version will focus on making sure it scales?

~~~
nadimisl
I might look into it in future revisions as large datasets wasn't part of my
initial requirement (having a simple grid component that can handle formulas
and copy/pasting).

The best option I had when building this was Handsontable. But that doesn't
play nicely with react's virtual dom and immutable data.

------
captainmuon
Nice! Looks really polished!

One thing I'm wondering about... if this is React based, do you reassign and
recalculate the whole grid upon every change? Because the grid is probably a
component, and has the table as props. I could imagine that is inefficient...
Not to even speak of then _rendering_ the whole component and sending it
through DOM reconciliation every time a key is pressed.

Well, OTOH I guess it doesn't matter for small tables. The demo feels really
snappy!

~~~
ChicagoBoy11
Wouldn't it just re-render the cells that changed?

~~~
netzone
Yup, checking the source there's a cell component in addition to the sheet
component, so it would just rerender that cell.

------
audiotalo
Nice!

Lately I have been looking into javascript grid components and have not found
a good solution.

What would be a good javascript grid component that satisfies the following:
1\. Integrates easily with Vue 2\. Has sorting 3\. Has grouping 4\. Has inline
editing (formulas are not required)?

OTOH I would be happy with a software that is basically a web frontend for
Postgres that can be customised in a way that a client can only see and edit
specific fields based on assigned rights.

~~~
rch
> Integrates easily with Vue

IMO grids (and trees, etc.) only work well if they are framework-specific.

Here's a table that could evolve into an editable grid:

[http://element.eleme.io/#/en-
US/component/table](http://element.eleme.io/#/en-US/component/table)

~~~
dman
That looks interesting

------
matthuggins
Looks nice, but the keyboard doesn't come up on mobile (Android), so all the
demos are unfortunately read-only.

~~~
helb
[https://github.com/nadbm/react-
datasheet/issues/5](https://github.com/nadbm/react-datasheet/issues/5)
(basically "Touch/Mobile Support?" –– "Not at the moment.")

------
ckluis
Paid library: [https://cxjs.io/](https://cxjs.io/)

------
fiatjaf
This covers 80% of Excel uses, but the rest 20% would take 1000% of the time
to implement.

~~~
clishem
Just some basic functionality that is used when making nearly all
spreadsheets: dynamically resizing tables, formating cells, setting cell types
(currency, floating point, integer, boolean), conditional formatting, cell
ranges, SUM, COUNT, IF, AVG, extending cell contents by dragging.

This project is a proof-of-concept. Nothing more than that.

------
swah
Math.js seems to evaluate using floats, but on your demo the results were
always rounded.

------
frik
What do you use for simple HTML tables that need some sorting and paging
functionality? There are various old JQuery libs around.

Can someone suggest something simple for React and/or vanilla Javascript?
(would be interested in both)

------
gressquel
the design looks really great, wish it was non-react, anything.

