Some additional packages are required to get react-dash working, need to add them as dev-dependencies.
Need to run: Yarn add fixed-data-table-2 react-nvd3 react-responsive-accordion react-select csv-es6-data-backend --save-dev

This ticket is for tracking the React-dash bugs that are currently prevent a react-dash release:

Bugs:

1. React v.16 bug: React dash errors out because deprecated proptypes has been removed also React.createClass. #69
2. The csv-es6-data-backend seems not to get fully installed with npm install, Had to copy an older version to get all the necessary files. Need to check its package.json for possible missing dependencies. (https://github.com/NuCivic/csv-es6-data-backend ).
3. Some additional packages are required to get react-dash working, need to add them as dev-dependencies. #70
4. React & React-dom versions should be pinned to 15.6.2: Ticket: #69
5. Fixed-data-table has been deprecated, should we be using fixed-data-table-2?

Hi, I get this error when doing an npm install. I have react and react-dom installed, but I got this with version 15.

 argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install"
npm ERR! node v4.4.3
npm ERR! npm  v2.15.1
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants react-dom@>=0.14.0 <0.15.0 || ^0.14.0-beta3
npm ERR! peerinvalid Peer [email protected] wants react-dom@^0.14.7
npm ERR! peerinvalid Peer [email protected] wants react-dom@>=0.14.0
npm ERR! peerinvalid Peer [email protected] wants react-dom@^0.14 || ^15.0.0-rc || ^15.0```
npm ERR! Please include the following file with any support request:
npm ERR!     c:\projects\uiot-react\react-dashboard\npm-debug.log

I tried reverting react and react-dom to the 0.14.x versions but another set of dependencies failed.

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants react@>=0.13.0 <0.15.0 || ^0.14.0-beta3
npm ERR! peerinvalid Peer [email protected] wants react@^0.14.7
npm ERR! peerinvalid Peer [email protected] wants react@>=0.14.0
npm ERR! peerinvalid Peer [email protected] wants react@^0.14 || ^15.0.0-rc || ^15.0
npm ERR! peerinvalid Peer [email protected] wants react@^15.0.2
npm ERR! peerinvalid Peer [email protected] wants react@^0.14.8

Any suggestions?
Many thanks, James

This is ambitious but we should consider doing a future version in elm or another strongly typed functional language with javascript interop

This warning: warning.js:35 Warning: AutosizeInput: isMounted is deprecated. is caused by using a deprecated pattern, isMounted, instead of ComponentDidMount & ComponentWillUnmount.
Reference: https://facebook.github.io/react/blog/2015/12/16/ismounted-antipattern.html

This is mainly used in npm packages which are external libraries being used with React-dash.
Mainly the fixed-data-table , react-input-autosize & react-select packages in the node_modules dir. For these, we should probably file issues in their respective repos.

We are also using isMounted in a react-dash npm package, also in the node_modules folder. Looking at the files I think we may need to restructure the component to use the lifecycle methods (ComponentDidMount) etc. in order to fix this.

description

• d3 formatters are very useful data https://github.com/d3/d3-format
• some nvd3 charts need d3 formatters, for example - in order to format pie chart tooltips we need the following (for example):
  settings.valueFormat: d3.format(".0")
• formatter functions should not be included in the settings object which should remain declarative so that it is portable as a JSON object

acceptance criteria

• components can read d3 format strings and turn them into functions for any prop or sub prop (prop.subprop)
• d3 is available in datahandlers
• tests that pass:
  • Chart.props.settings.labelValue = d3Formatter : {formatString: ".0"}
  • dataHandlers.testFormatter = function (...args) { // return array of d3 formatted values }

The StateHandlers don't receive the dashboardData or appliedFilters because the arguments are not set correctly in BaseComponent.

https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh

If the user receives data from an API that contains a hits property, this will fail.

  applyDataHandlers(data = [], handlers) {
    let _handlers = handlers || this.state.filterHandlers || this.props.dataHandlers;
    let _data = data.hits || data;   // <--- fails

e.g. If the user data/API result is shaped like { foo: 1, bar: 2, hits: 'baz' } then the component will only receive baz and the rest will be lost.

CC: @alexrollin
HI,

Facing error while doing npm install after cloning it.

Based on a client request. Do we need to enable CORS support in addition to JSONP?
Wikipedia results suggest that JSONP is older and more susceptible to XSS attacks (if the source site is compromised) and some other security concerns.
https://en.wikipedia.org/wiki/JSONP
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

http://uber.github.io/react-map-gl/#/

This appears to be a useful framework for exploring maps and GIS-related integrations into React.

We should evaluate potential integration with the ReactDash

Needs more info.

The example, http://dev-ucr-dashboard.getnucivic.com/dashboard/12, is not currently working and you get a 530 error when you go to the example website.

Needs more info.

In your sample dashboard, the Unique Visitors metric component causes four fetch() requests on loading. (instead of just one as I would expect)

This is possibly caused by calling getData() within the render method.
https://github.com/NuCivic/react-dashboard/blob/bffd601faa6d1a6325da88ac114ecd500bc4ffad/src/components/Metric.js#L32

Steps to repeat:

1. Install fresh copy of dashboard
2. Remove all components except the Unique Visitors metric from settings.js and MyCustomLayout.js
3. Check Devtools console on page load. Screenshot below.

Needs more details: To be filled out from JIRA.

Description

We should define a schema which is attached to the dataset metadata and sent by the Datastore API with each API call.
It should look something like this:

{
  // ... existing metadata
  resources: [
    {
      name: 'countyData',
      uuid: '1bc-123',
      fields: [
      	{
      		name: 'countyId',
      		pk: true,
      		type: 'uuid'
      	},
      	{
      		name: 'population',
      		type: 'longInt'
      	},
      ]
    },
    {
      name: 'physicianData',
      uuid: '1bc-123',
      fields: [
      	{
      		name: 'physId',
      		pk: true,
      		type: 'uuid'
      	},
      	{
      		name: 'specialty',
      		type: 'int',
      		fk: true
      	},
      	{
      		name: 'WL1 County',
      		type: 'int',
      		fk: true
      	},      	
      	{
      		name: 'County1',
      		type: 'int',
      	},
      	{
      		name: 'race',
      		type: 'enum',
      		enum: ['White', 'African American', 'Native American', //...]
      	},
      	{
      		name: 'notes',
      		type: 'string'
      	}
    }  
  ]
}

On the client side, we will have access to this, and can start to use our type-safety to perform data operations from generic datahandlers - rather than writing custom code

for instance, if our schema defines a field: accpeptsMedicare type: bool we could provide a datahandler definition pieChartFromBoolField: {fieldName: 'acceptsMedicare'} which returns the chart.

This concept could / should be extended to provide a well-documented DSL that is tightly coupled to the datastore api.

An imaginary dsl could look like:

pieChartSeriesFromBool
pieChartSeriesFromEnum
pieChartSeriesFromRange
barChartSeriesFromBool
barChartSeriesFromEnum

etc.

*note - these are direct mappings from known API return values (along with metadata such as type) and known data formats for chart components

Further analysis will be required to capture the useful set of generic dataHandlers

Notes

• We try to use an existing type system, maybe mysql datatypes https://dev.mysql.com/doc/refman/5.7/en/data-types.html
• This should be incorporated as an optional extension to the existing dataset metadata

Description

See current example site:
https://nucivic.github.io/react-dash/

And take a look at code here:
https://github.com/NuCivic/react-dash/blob/gh-pages/src/components/BaseComponent.js#L36-L47

BaseComponent calculates widths based on DOM element, but on page load / component didMount it is calculating the width before the bootstrap classes are applied.

I think this is primarily affecting components that are generated by svg - charts and maps
They grab the component width and use it to calculate paths, but the widths they are using are full width - not the width based on the column classes. After resize the component widths adjust properly.

This leads to mis-rendering of charts and graphs when they are represented in columns.

Steps to reproduce

Take a look at the current example site - gh-pages branch:
This is as close as I could get it.
It loads incorrectly (using incorrect widths)
On resize (manually resize browser window) it re-renders using the correct widths

Probably should start here:

Acceptance critera

Create a row of two component with cardClasses: ['col-md-6'] type multiBarChart - height and width should render relative to columnar width and not overflow columns

Follow steps listed in the docs https://react-dashboard.readthedocs.io/en/latest/development/workflows/publish.html

Blockers:

• Needs to be done by someone with access to the npm registry.

Details here: https://nodesecurity.io/check/react-dash

Evaluate integration of https://github.com/reactjs/react-tabs or an equivalent library into React Dash.

Proof of concept would support building tabbed panes. e.g. https://reactcommunity.org/react-tabs/example/

It would be great if the tabs could be either horizontal or vertical

Introduction

Objectives

To aid in choosing a data table library which
could be used with react dash. Up until now we have have been using *Fixed data
table*. The problem we have accounted has been related to it's lack of
responsive theming capabilities, as described on the Fixed data table 2 github
page: "FixedDataTable does not provide a layout reflow mechanism or calculate
content layout information such as width and height of the cell contents. The
developer has to provide the layout information to the table instead."

It would have been nice to have found more react libraries to compare, and it
might be the case that I have missed some out. The other two libraries are
jQuery and will need a bit of extra work to integrate them into React.

What is a data table?

Data tables present tabular data. Data tables should contain table header cells that identify the content of their respective row and/or columns. Tables with proper table headers provide additional information and navigation for screen reader users.

Criteria used for choosing a library

Accessibility

Optimally, we would be 508 compliant:
https://webaim.org/standards/508/checklist#standardn

Table headers

Table headers describe the content of their respective row or column. They can be identified by screen readers when data cells are encountered.

Aria describe by

This is a pointer to a DOM element that describes the table.

• Examples and more information

  https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute
  https://www.w3.org/WAI/tutorials/tables/caption-summary/

Scope

https://webaim.org/techniques/tables/data#scope

Responsiveness

The library should include responsive components that will work well at
different resolutions, including print.

JSON consumption

The library that we choose will need to be able to work within different APIs
to consume JSON data.

Handling of large data sets

This could mean using lazy loading of data and/or AJAX to make make requests to
the server for new data sets to present.

Internationalization

This is the capacity to internationalize the interface.

DataTables evaluation

Based on use of the WAVE web accessibility tool.

Accessibility

https://datatables.net/new/1.9
DataTables tables are now fully accessible and controllable by keyboard navigation and suitable markup and WAI-ARIA attributes are used for screenreaders. This works "out of the box" with no configuration required. To try it out, load any 1.9 example and press the tab key to navigate through the table controls. Note that this accessibility work as required updating the pagination elements. Please see the upgrade notes for further information.
Though scope is not included out of the box it does look like it should be
possible to add it, at least in the case of a simple table structure. See this page. Making the data table 508 compliant

Documentation

https://datatables.net/manual/ajax

Internationalization

Via plugin
https://datatables.net/plug-ins/i18n/

Conclusion

Project seems the most robust of the three.

Table saw evaluation

Demo URL

http://filamentgroup.github.io/tablesaw/demo/stack.html

Accessibility

Has scope, but it is not applied to the the td cell, so would not pass 508 in
it's current state.

Responsive

Is capable of hiding selected columns for narrower screens.

Documentation

https://www.filamentgroup.com/lab/tablesaw.html
https://github.com/filamentgroup/tablesaw#getting-started

Conclusion

Might need a little work for 508 passing. Table Saw uses progressive
enhancement. So, the table data needs to be written to to HTML. This is good in
the sense of not requiring JavaScript in all use cases, but would probably mean
separate page requests for retrieving large data sets.

React virtualized evaluation

React virtualized

Responsiveness

Does not seem to be fully responsive in the demo.

JSON consumption

Large data set handling AJAX

Excellent documentation

Internationalization

Conclusion

Data Tables stands out as the most complete of these three libraries. React Saw
seems solid in the sense that it builds on an actual HTML table (progressive
enhancement), though I don't see how it would handle large datasets without
separate page requests which could reduce the user experience.

Needs info:

When I run either the dashboard with npm start or the boilerplate dashboard with npm run dev_standalone I fail to get any data in the table component. The fetch appears to work and the console doesn't show any relevant errors.
Is there a running demo somewhere?
I'm running node 6.2 and react 15.

This will allow us to encapsulate dashboard-specific logic and will allow library users to more easily incorporate their own react components

-- Needs more Info
I think this is already being done where the Dashboard component is being used as a hoc in dkan_dash? https://github.com/NuCivic/dkan_dash/blob/master/js/src/dkan_dash.js

Resource: https://reactjs.org/docs/higher-order-components.html

The http://dev-ucr-dashboard.getnucivic.com/dashboard/12 site gives a Can't find variable: fetch error in macOS Safari.
You can use whatwg-fetch instead, if you want to make it work: https://www.npmjs.com/package/whatwg-fetch

Tests are in the tests folder. Needs a number of new tests and also need to confirm that the current tests run. Some current tests also need to be improved. We have a few testing steps like expect("needs work").toBe("needs work"); that need to be filled out to test for actual components.

Details needed:

Pin the package.json for React & React-Dom to 15.6.2, to avoid new builds getting setup with v16.
Story: #68

Needs more info. Do we need the styles/colors/fonts to be editable? Or add color scheme switching ability?

The boilerplate setup instructions has compile errors. The installation process does not get completed.
Repo: https://github.com/NuCivic/react-dash-boilerplate

There are a couple of reasons for this.

1. React has trademark rights to React. This rides off of Facebook's trademark, which is awkward for us. We would potentially need to change the name of this product.

2. I don't think we need to be beholden to using the React framework. What if we want to use Elm or Vue in a future version? The current name would then be off based.

3. Our vision of React Dash is to use this as a dashboard technology for any Open Data system. A better name might be something closer tied to the purpose, like "Open Data Dash". This would be better contextually, and not tied to a technological framework.

The csv-es6-data-backend seems not to get fully installed with npm install, Had to copy an older version to get all the necessary files. Need to check its package.json for possible missing dependencies. (https://github.com/NuCivic/csv-es6-data-backend ).