zambezi / grid Goto Github PK

Not able to build .Invalid name @zambezi/grid

Please give detailed build steps.

Also is it possible to use this grid as a react component in reactjs project (being complied using webpack rather than grunt)?

The current grid-sheet component has been pulled into d3-utils

We should use the external component instead of supporting two versions of the same functionality.

When working with large datasets, it would be more performant and convenient if grid.datum() could also accept an object, not just an array. This would allow for updating of specific datapoints in specific rows without having to loop through the array to find the correct row (even Array.find and Array.filter are just looping behind the scenes).

So in addition to this usage:

grid.datum([
  { id: 'row1', name: 'First row', foo: 'bar' },
  // ... more rows here
  { id: 'row1000', name: 'One-thousandth row', foo: 'bar' }
]);

... we could also do:

grid.datum({
  'row1': { name: 'First row', foo: 'bar' },
  // ... more rows here
  'row1000': { name: 'One-thousandth row',, foo: 'bar' }
});

That way, rather than having to loop through to find the row we want to update, we could directly address it.

// assuming we cached our data in a variable named 'data'
data['row799'].foo = 'baz';
grid.datum(data);

It seem that even though we tried to keep the selectors "light" on the vanilla grid -- the grid is still hard to style and the stuff that we added so that the examples wouldn't look too sterile and the grid would look good "out of the box" still pop from under the real styles that apps layer on top.

Also, it looks as if those styles were created by a developer. Perhaps they were? :^/

It'd be good if the grid without styles functioned fine but didn't look like anything.

--

Also, styling row and cell divisions is unnecessarily hard because we use both on the vanilla stuff.
Might be a good occasion to see how this could be made easier?

Expected Behavior

I've been asked offline a few times already how best to set classes to cells in specific columns.
The answer "create a column component just for that" doesn't go down that well.

So the request has been to support a className optional property on column configuration.
When present, the grid will all that class (or string of classes (a la D3)) to all the cells for that column.

This issue is to link and keep track of the little (or medium) changes we've had to add to the grid to be able to run it on legacy browsers. Even though the general policy is to leave the shimming at the app level, we've needed to leak some of that to the grid-level code.

At some point in the future 🌴 🌞 , we'll remove this and close this issue.

Let's inaugurate with #29

... little and big things diverge.
From the lodash guy,

Underscore has inconsistent support for arrays, strings, objects, and arguments objects. In newer browsers, Underscore methods ignore holes in arrays, "Objects" methods iterate arguments objects, strings are treated as array-like, and methods correctly iterate functions (ignoring their "prototype" property) and objects (iterating shadowed properties like "toString" and "valueOf"), while in older browsers they will not. Also, Underscore methods like _.clone preserve holes in arrays, while others like _.flatten don't. on stack overflow

I, today, bumped into a problem with memoize where if you use object keys underscore gets confused but not lodash. I imagine an [object Object] string under the hood.

Expected Behavior

It should work -- one should be able to move columns around in IE same as in other browsers.

Current Behavior

It blows up on a dataTransfer.setData call.

Steps to Reproduce (for bugs)

1. Open on IE
2. Try drag a column around another column.
3. Boom.

Context

We use the native D&D API. Fools! Maybe we should rely on the d3-drag behaviour

Environment

• Version used: IE11 and IE10
• Operating System and version (desktop or mobile): Desktop windows.